LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Saturation of Single Precision floating point accumulator

I opened a service request for this bug, also.

It seems a single precision shift register inherits its exponent from some combination of the input controls but not itself, and therefor saturates.  Originally I noticed this in LabVIEW FPGA using the Xilinx floating point coregen primitives.  It also occurs with the regular LabVIEW single precision primitives in FPGA, and ultimately in Windows as shown below.  I haven't simplified it any more, but a multiply accumulate is a pretty common function to use.Sgl_Accum.pngSgl_Accum_FP.png

 

0 Kudos
Message 1 of 6
(4,127 Views)

Not that I know the answer...

 

0.0000004 can not be represented in binary so LV uses the closest value.

 

Sinlge >>> 0.000000400000004674438968

 

Doulbe >>> 0.000000399999999999999981

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 2 of 6
(4,109 Views)

Ben, 

For sure that is understood.  It is interesting behavior.  With the release of single precision floats to LV FPGA, more issues may arise.  

Here is 2 more test cases.Sgl_Accum_FP_1.png

Sgl_Accum_FP_2.png
Edit: First image had non-matching values in controls.

0 Kudos
Message 3 of 6
(4,099 Views)

This is to be expected. A single-precision value doesn't have enough resolution to store 8.0000004 (8+0.004*0.0001), so the 0.0000004 gets cut off. Try it out - paste that value into a single-precision control, and you'll see that you lose the small fractional portion.

Message 4 of 6
(4,088 Views)

Just for a bit more proof: storing the value 8 requires an exponent of at least 3. A single-precision value has 23 bits for the number, so if we set the lowest bit to 1, it will have a value of 2^-20 (because 23-3=20), or approximately 9.537E-7. So, a single-precision number can't store any value between 8 and 8.0000009537; any value in that range gets rounded down to 8.

0 Kudos
Message 5 of 6
(4,052 Views)

There is no bug, just a limitation of floating point numbers if the mantissa does not have an infinite number of bits.

 

An illustrative example if the definition of machine epsilon, so once the ratio of increment and sum is less than epsilon, the addition will no longer increase the sum. Machine epsilon is even in the palette!

 

You code is a crude way to estimate the value of machine epsilon, nothing more.

 

 

0 Kudos
Message 6 of 6
(4,044 Views)