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.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Math Log Calculation error?

Solved!
Go to solution

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?

0 Kudos
Message 1 of 8
(3,575 Views)

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.

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 2 of 8
(3,569 Views)

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

0 Kudos
Message 3 of 8
(3,541 Views)

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.

0 Kudos
Message 4 of 8
(3,532 Views)

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

 

log.png

 

LabVIEW 2016 Windows 7 Profesional

 

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 5 of 8
(3,524 Views)

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.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 6 of 8
(3,518 Views)

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.

0 Kudos
Message 7 of 8
(3,489 Views)
Solution
Accepted by topic author vinvan

Using your values indeed shows '1' as Int Res 3. However, choosing the correct display format, you will see this:

NotEqualOne.PNG

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 8 of 8
(3,487 Views)