03-30-2022 09:53 AM
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
Solved! Go to Solution.
03-30-2022 10:03 AM
@James_W wrote:Press 'e'
Screen shows
'2.71828182845904509'
You've lost me there.
If I press 'e', nothing happens.
03-30-2022 10:39 AM - edited 03-30-2022 10:40 AM
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?
03-30-2022 12:18 PM
@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.
03-30-2022 12:24 PM
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!
03-30-2022 12:41 PM - edited 03-30-2022 12:52 PM
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?
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.
03-30-2022 12:43 PM
ok...
lets try again...
- 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
03-30-2022 12:58 PM - edited 03-30-2022 01:17 PM
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....
03-31-2022 03:24 AM
@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.
03-31-2022 08:36 AM
@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....
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