From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
04-03-2017 10:20 AM
Running a VI in LabVIEW 2015 in Windows 10 Enterprise. Takes two numbers, divides the first by the second, then multiples result by second number, then that result is divided by the first number. The result is sent to "Logarithm Base 10.vi" function, then multiplied by 20. All numbers are double precision. You would think that the result sent to the "Logarithm Base 10.vi" would be equal to 1 and the output would be equal to zero and the final result would be equal to zero. But that is not the case all the time. Converting the result sent to the vi to a single precision number does help get a zero final result, but it still sometimes does not work. Running the same test vi in LabVIEW 7.1 on a different computer running Win XP seems to work all the time. Any suggestions?
Solved! Go to Solution.
04-03-2017 10:25 AM
What do you enter as Num A and Num B?
I assume that you are running into the good old "accuracy problems" issue from floating points.
04-03-2017 10:46 AM
On Windows 7 and LabVIEW 2016 (Full Development) I always get 1.00000, 0.00000, 0.00000 displaying trailing zeros and 6 significant figures. Tried several combinations of Num A and Num B. What values give you incorrect answers?
Ken
04-03-2017 10:53 AM - edited 04-03-2017 10:57 AM
I tried a few numbers and it works correctly, but I also would expect to run into floating point limitations at one point (as has been mentioned). Some nice decimal fractions cannot be represented in binary (unless we have an infinite number of digits), so some loss can occur at any step, of course. A change in the order of operations for mathematically identical calculations often yields subtly different results.
It is also not nice to preemptively blame the log functions. It could equally well be any combination of the primitives.
You should also configure your indicators for more decimal digits to better see what's going on. 6 significant digits will round things too much.
04-03-2017 10:58 AM
I just put your calculation inside a for loop and ran it using random numbers between 0 and 100.
I ran it a few times and the answer always comes out 0.00000
LabVIEW 2016 Windows 7 Profesional
04-03-2017 11:20 AM
This is amazingly like the (very, very) old calculator bug where you could keep dividing a number by 3 and multiply the result by 3 until eventually you'd get a number that wasn't the original. I'm talking "old" like "when they first came out and all you had was the basic arithmetic functions" kind of old. 😉
I guess the reasons were similar, too.
04-04-2017 06:29 AM
The numbers that originally showed the error was --> A = 0.0001001 and B=3.2587.
I originally thought it might be a log function error because the 'Int Res #3' indicator always showed a 1.00000 and when I converted the number going into the log function to single precision, it seemed to work correctly. The error shows up when control B is much greater than control A. My use does use very small numbers for the first number.
The use of this vi was for creating a factor to be used in dB gain calculations of frequency response measurements, where the result of the first division is used as a scaling factor for the rest of the frequencies tested and the gain for the first frequency would be set to zero.
04-04-2017 06:39 AM
Using your values indeed shows '1' as Int Res 3. However, choosing the correct display format, you will see this: