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

[wiebe@CARYA]

Should we mention the Floating Point Equal? function?

Probably not 😁.

[altenbach]

---

@James_W wrote:

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

---

Not sure why you think that this will affect your calculations since every other value relies on the same limited precision.

The DBL format is plenty for any engineering task, because every measured value is quantized to a given number of bits and I have yet to see an AD converter with 52bit resolution 😮 .that would utilize the capabilities of DBL fully. You don't need 40 extra bits to describe your instrumental limitations and thermal noise.

This leaves us with purely theoretical calculations. If these are very lengthy and rely on billions of iterations, floating point errors could accumulate over time to become noticeable, but even going to EXT will not give you much additional slack. The problem grows if numbers differ significantly in magnitude (e.g. 1e100 + "e" is still 1E100, see also machine epsilon). Linear algebra has even a condition number that lets you estimate the quality of the result.

None of this is a problem with anything that can be reasonably done with the formula express VI. 😄

Back to the "e" constant. I have yet to find a place where it is used standalone. LabVIEW has its typical uses built into other functions directly (e.g. the well known exponential function).

If your calculations go wrong, most often it can be fixed by changing algorithms, implementation, execution order, etc. The precision of "e" is NOT the culprit.

It would be interesting to see where you think that "e" is to blame. Can you show us your use case?

Things would have been so much simpler if evolution would have given us 16 fingers instead of 10. 😄

[James_W]

Maybe I'm just being OCD. If I've got n digits I want them all to be accurate. 
you've explained why they won't be and won't work, so I'll limit my program accordingly.

It's just something that bites occasionally when you haven't studies Comp Science and only did Mech Eng. - Never covered the point at which we lose resolution in the different datatypes (and it's sooo easy to find if you want it isn't it😉) 

Learning everyday. Just dealing with very high precision instruments now and when we get down to 11dp of precision with the native instruments I start to worry about the precision I'm losing through constants and calculations in the wrong datatypes. Just trying to cover myself before I get queried by users about the resolution accuracy of the values.

James

[altenbach]

Yes, it is good to think about these things.

The resolution is expressed in decimal digits, not in digits after the decimal points. 11 digits after the decimal point is no problem unless the integer part is significant. 😄

So if you are measuring femtoseconds, you are fine as long as the total duration is reasonable (i.e. <<1s) 😄 You'll run out of memory way before that anyway. 🙂

[wiebe@CARYA]

---

@altenbach wrote:

So if you are measuring femtoseconds, you are fine as long as the total duration is reasonable (i.e. <<1s) 😄 You'll run out of memory way before that anyway. 🙂

---

If dT is in femtoseconds, I agree. But you can measure femtosecond pulse widths at let's say 2 Hz for a very long time...

Esp. frequencies tend to be high in value and very accurate. E.g. GHz values with <.1 PPM accuracy. If you want to do calculations on that, you might need to split values by subtracting the 2GHz and adding the results later if needed.

[altenbach]

---

wiebe@CARYA wrote:
If dT is in femtoseconds, I agree. But you can measure femtosecond pulse widths at let's say 2 Hz for a very long time....

Having one femtosecond pulse every second is OK. Calculating things based on ratios (e.g. duty cycle) are fine, but things based on add/subtract e.g. trying to calculate the duration of the gap from the pulse with and spacing could be problematic. 😄