LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Have I found a Bug in the Script/Formula Express VI?

Solved!
Go to solution

LabVIEW 2020 SP1

Mathematics Palette >
Scripts and Formulas >
Formula express VI

Press 'e'
Screen shows 
'2.71828182845904509'

ahhh... Numeric constant of 'e' shows the same to 20 dp in DBL format (and 30dp shows the same). so this is just the string representation of the NC.


'e' to 50 dp in numerous different places is:
2.71828182845904523536028747135266249775724709369995
2.71828182845904509

so we go wrong at the 18th decimal place - I'm assuming this is because we can't store the correct number for some reason due to the conversion?

James

CLD; LabVIEW since 8.0, Currently have LabVIEW 2015 SP1, 2018SP1 & 2020 installed
0 Kudos
Message 1 of 16
(1,687 Views)

@James_W wrote:

Press 'e'
Screen shows 
'2.71828182845904509'


You've lost me there.

 

If I press 'e', nothing happens.

0 Kudos
Message 2 of 16
(1,683 Views)

There is a button labeled "e", which returns the constant as string.

 

Formulas operate on decimal formatted strings and we have plenty of digits for a DBL (or even EXT) that are good for about 15 decimal digits each. (I would even say that we have too many digits!)

 

Many decimal fraction don't have an exact floating point representation in binary. I am sure you can do all you ever need to do without express VIs such as this. What problem are you trying to solve?

0 Kudos
Message 3 of 16
(1,660 Views)

@altenbach wrote:

There is a button labeled "e", which returns the constant as string.


Ah, completely filtered out the 'express' part... (<< There's an hidden message in here somewhere.)

 

Seems to me someone just didn't bother to type all significant decimals, assuming 18 would be enough... I guess usually it is.

0 Kudos
Message 4 of 16
(1,638 Views)
Solution
Accepted by topic author James_W

Since formula calculations are probably DBL based (and not some bignum hack), anything with more than 16 decimal digits would be plain misleading here!

 

Nobody in his right mind that wants to look up an arbitrary number of digits of a constant would fire up LabVIEW and then place and open an express VI. Just google the number!

Message 5 of 16
(1,636 Views)

Some easy reading:

 

Double-precision floating-point format 

How LabVIEW Stores Data in Memory 

 

Note that the formula express VI (after pressing "e") will return the exact binary identical value as the e constant from the numeric palette. Good enough, right?

 

 

altenbach_0-1648661994463.png

 

Also note that a light year is 9.461e15 meters and it would be irrelevant to specify if the distance to Alpha Centauri (4.37 light years) is measured from sea level or from the tip of Mount Everest. The distance variation due to earth rotation and orbit around the sun is much larger.

 

Message 6 of 16
(1,631 Views)

ok...
lets try again...

James_W_1-1648661939883.png

- This gives the same value.
My issue isn't so much the express VI, but if I'm trying to duplicate the functionality.
The LabVIEW value of 'e' seems to be wrong, which will affect calculations which use it.
or am I wrong?

ahh formula calculation and not bignum hack it is!

James

CLD; LabVIEW since 8.0, Currently have LabVIEW 2015 SP1, 2018SP1 & 2020 installed
0 Kudos
Message 7 of 16
(1,625 Views)

Ay decimal digits past 16 are random and due to the limitations of floating point representation. Formatting as a sequence of decimal digits is often lossy, except for some special values (integers, 0.5, 0.25, etc.).

 

Same goes the other way: For example 0.1 (decimal) would need an infinite number of mantissa bits to be represented correctly in floating point..

 

Try this:

What is the value of [i] when the loop stops? Hmmmmm....

 

altenbach_0-1648663456327.png

 

Message 8 of 16
(1,616 Views)
Solution
Accepted by topic author James_W

@James_W wrote:

The LabVIEW value of 'e' seems to be wrong, which will affect calculations which use it.
or am I wrong?


It's not wrong, it's the closest achievable.

 

Because of the limited resolution, e can be either slightly too low:

2.71828182845904509000000000000000000000000000000000

or slightly too high:

2.71828182845904553000000000000000000000000000000000

 

The 'too low' value is closer.

 

There just aren't enough bits in a dbl to come closer.

 

I do not know why the elementary charge is an extended..

 


@James_W wrote:

The LabVIEW value of 'e' seems to be wrong, which will affect calculations which use it.
or am I wrong?


Of course it's wrong. Of course it will affect calculations.

 

e is irrational, so there simply isn't a way to represent it with numbers. Even 50 numbers is not exact, as you'd need infinite numbers to represent e.

Message 9 of 16
(1,572 Views)

@altenbach wrote:

Ay decimal digits past 16 are random and due to the limitations of floating point representation. Formatting as a sequence of decimal digits is often lossy, except for some special values (integers, 0.5, 0.25, etc.).

 

Same goes the other way: For example 0.1 (decimal) would need an infinite number of mantissa bits to be represented correctly in floating point..

 

Try this:

What is the value of [i] when the loop stops? Hmmmmm....

 

altenbach_0-1648663456327.png

 


Oooo that's nasty. I wouldn't have guessed that behaviour. I suppose that's why we don't do eqz on a non int data type.
I really did expect that to stop. - well that's my new thing learned today. Thanks Christian!😁

James

CLD; LabVIEW since 8.0, Currently have LabVIEW 2015 SP1, 2018SP1 & 2020 installed
Message 10 of 16
(1,552 Views)