0
Under review

Handling huge (unsigned int32) numbers

Rick 9 years ago in IQANdesign updated by Gustav Widén (System support) 9 years ago 3

Is it possible to have a 64bit, or at least a "unsigned" property for some channels?


I ran into problems when dealing with huge integers. For example, this won't work in the QCode of an IMAC:

X := 200100 * 56200


I guess "X" is automatically a Float, so it can't store such a large number. IMAC channels can hold a large number, but also if the most significant bit is on, it will end up as a negative number.



Same issue more or less with JPIN blocks. You can workaround it by chopping it up into 2 16-bit values, and glue them together later on, but it's not very elegant of course.

No plans on introducing 64-bit integers, but support for 32-bit unsigned is in our feature backlog.

X in your example above will be of type Integer, 32-bit signed, which of course can't hold such large numbers. For that you must use Float. X will be Float if at least one of the operands is Float.

To my knowledge a (32bit) float can't reach as high as an unsigned int32 because the last bits are "wasted" on the Mantissa & Exponent, so that won't do the trick.


The problem mainly occurs when doing math with Serial numbers, J1939 DTC's or GPS coordinates. At some point, the value gets slightly inaccurate or changes completely. In some cases it can be bypassed by splitting the math into 2 lower-range values, but that's not always possible unfortunately, let alone "readable".

Under review

Yes, with the 32 bit float we use, you will be limited to 7 significant digits, so even though it can represent higher values, it cannot represent these values in an accurate way.


There is some more detail in the IQANdesign user manual:



For reading for example 32 bit GPS coordinates to IQAN with the JPIN channel, the scaling done in the JPIN works around this problem.


I agree, it would be useful to be able to have unsigned 32 bit also on calculation channels.