Change/add math vi's to prevent rounding errors

[GerdW]

Hi Anthony,

how to "be sure that rounding errors will never reach" your precision level? Something like:
When you do 5 math steps you get 6 digits precision, but after 10 steps only 4 digits? When you include trigonometric functions you get one digit less precision?

So many things to watch...

My advice is still the same:
Make your own vi's that exactly act as you wish. But don't blame the (limited precision) IEEE standard to act different than your results from your hand-written calc sheet...

YOU have the need for a special function, so YOU have to program it (or pay someone to program it for you).

[Kevin_Price]

---

Is LSB rounding valid when using mantissa and exponents?  What if two neighbouring numbers (in IEEE notation) have different exponents?

---

Good Q('s).  To be honest, I haven't thought *real* hard about it, nor have I researched the ins and outs of IEEE floating point representation.  Perhaps the conventions will dictate against any simple bitwise operations as a fast rounding method.

Basically, I hope the discussion helps result in the development of some utility vi's that do appropriate rounding for operations like Q-R and floating-point comparison.  I for one would expect to use them now and then.  At this stage of the game though, it's apparent I don't know enough IEEE to be much help at developing them.

Can anyone propose some ideas on how to both specify and implement rounding for SGL and DBL values?

-Kevin P.

[shoneill]

Kevin,

I really dont think it's so trivial as Anthony's making out.  There are a lot of pitfalls and things to be kept in order.

I think it's a perfect example for a home-brew toolkit to be honest.

Shane.

PS "nor have I researched the ins and outs of IEEE floating point representation" Er neither have I, but maybe my scientific background is telling me things in a subliminal way.  I think there are cases where two neighbouring numbers (candidates for rounding errors) will have different exponents, thus rendering simple bit operations very dangerous.

[Kevin_Price]

Shane,

I agree that a best-case scenario is a "home-brew toolkit" like you mentioned, but one that goes through some significant rigor and then makes its way into OpenG.

It *does* seem there will always be some corner cases that can be imagined.  That's ok with me so far, because I don't view any of these alternative "rounded" functions as replacements for the standard ones.  If the input values are of unknown origin or unknown precision, the standard functions should be preferred since they operate in a well-defined industry-accepted manner. 

However, in certain instances inputs are known to have limited meaningful precision.  *Then* a programmer could have the option of choosing one of these alternative toolbox functions.  What remains is to demonstrate that a well-implemented alternative function won't merely shift the problem and cause a *different* distinct set of common inputs to result in non-intuitive outputs.  I'm not convinced yet, but am willing to consider it may be possible.  I'm hoping it *is* possible, because I'd like to use such functions.

I guess the key test is that you don't want to observe a discontinuity in the output caused by a change in an input that's confined to bits/digits well to the right of its last significant digit.  1 good counter-example would blow the whole exercise out of the water.

-Kevin P.

[shoneill]

Kevin,

I agree there are cases where this kind of thing might annoy, but it's up to the programmer to recognise this and fix it.
I would label this kind of operation as "signal conditioning" or "Algorithm optimisation".  I don't think it beloings to basic math functions within LV.  As I think we nearly all agree.

The original post was all about the built-in functions being wrong and this not being acceptable and what not.  This was clearly somewhat overplayed.  It was the view that the IEEE way being blindly followed made us all stupid or something without taking the time to understand why things are that way.  Of course there are math libraries with arbitrary precision out there, but try getting them to run fast..... 🙂  We're limited by hardware at the end of the day really to what's reasonable to execute.

Shane.

[Anthony_de_Vries]

I really take offense at the suggestion that this is something that only concerns a handfull of people.   It doesn't!  It concerns almost everyone who uses these operators!

Sometimes, the effects are so disastrous, that it's immediately clear that you shouldn't use it.  That's the case of the floating point equality.  There thing go wrong 99% of the time. But the case is exactly the same for the other comparison operators.  Floor is affected is by exactly the same problem as equality. It just doesn't happen so often as with equality.  

Why don't we learn never to use the floor operator? Just because it gives unexpected results less often?  That doesn't sound like a valid reason, does it?

There's many ways you can solve this issue. Sure, you can say that you shouldn't extend the IEEE primitives, and that the programmer has to solve this himself. I can live with that.   But then, where is the 'round to # sign. digits' primitive that you need when you want to solve this yourself? While my vi works, it's certainly not the fasted version.   That's typical the kind of vi that you then want as a built-in primitive next to supplied IEEE primitives.

Can we agree that Labview should at the very least include the primitives that you need to solve this issue?

Message Edited by Anthony de Vries on 10-17-2007 05:56 PM

[Anthony_de_Vries]

Gerd,

how to "be sure that rounding errors will never reach" your precision level? Something like:
When you do 5 math steps you get 6 digits precision, but after 10 steps only 4 digits? When you include trigonometric functions you get one digit less precision?

True, that's an issue. However, it's not like you don't have that problem allready.     Do you write your end results in 16 sign. digits on the front panel or in files?   Or do you round them?  To which number of sign. number do you round?   Have you checked wether the rounding errors have reached that precision level? 

How is rounding before comparisons different? 

But ofcourse, that the reason why I suggested that you have the option to choose between IEEE and rounded, and to set the rounding.  Then you just need to pick a suitable default.  8 or 10 sign. digits probably suits most needs.   You need to do A LOT of calculations before you produce 6 to 8 digits of rounding errors.  

Anyway...  if you get more than that, you're only just back to the unexpected results you allready got from the IEEE primitives, which apparantly most don't feel as a problem...

[GerdW]

Hi Anthony,

I still say: it's only a a small percentage of programmers having problems with Q&R... Normally you don't need Q&R for floats.

For your question:
No, I don't write results in 16 digits precision. But there's a reason!
I do a lot of measurements. My DMMs/Sourcemeters have up to 6½ digits of precision (slow measurement) or just 4½ digits for fast measurements. I don't do a lot of calculations on these data. So saving with 7 digits is sufficient for me - and is so in most cases as you always should do some error range calculations for measurement data!

For your "option to choose between IEEE and rounded":
There shouldn't be an option to choose!!! As I said before: keep the original functions as ALL programming languages depend on the same IEEE754 standard. Let's keep calculation in LabView consistent with calculations in other languages! (Ever counted the threads where people ask: "Why do I get different results in LabView compared to MatLab?")
Make your own set of functions when you need them and use them whenever you want to!

[Anthony_de_Vries]

Indeed, there's very few meaurements that have more than 7 sign. digits of precision.  Mosts phyisical constant, like the speed of light,  gravitional constant etc, only have 8 to 9 sign. digits, because we simply couldn't measure them more accurately. 

But here's the thing...   When your measurement is only significant to max. 7 digits.... why compare values in a way that is dependend on the 15's digit?

Having an option to include the rounding is just a service to users.  It doesn't change IEEE compliance.  You could keep the default at IEEE compliance to prevent such questions.

Sure, you can ask people to do their own rounding before using the IEEE primitives.  People would then make their own set of extended primitives, like I have done with the QR, and Kevin has done for floating point equality.   Then these extended vi's sit in the user library.

Obviously, NI could also choose to include such a set of extended primitive themselves, as a service to their customers, so people wouldn't have to program it themselves. Then, these extended vi's sit in an 'advanced section' of the 'numeric' menu.   No problem with that, is there?

But then, you have a double set of comparison primitives in the menu structure.   To keep the menu structure cleaner, NI could choose to make the comparison primitives polymorphic, so you can choose between IEEE en rounded, in stead of having two seperate menu's.   It's really the same as having a seperate library, just a different way of choosing them.    

Having them polymorphic, would allow for a 'default' choice in the Laview options, where one could select that you want the rounded version default, instead of the IEEE version.  Again, that's simply making it more easy to select those vi's from the menu structures. Keep the default installation setting at IEEE, and nothing is different from before.

It's just a matter of where and how you place things in the menu, nothing more.   

[Odd_Modem]

Unfortunately, in the past I have had to write out using 15 digits. The issue is not comparison but rather saving the exact state of a system. Note that serializing to XML a cluster that contains a double using the built in LabVIEW XML  functions will only store 6 digits.
This is PI
<Cluster>
<Name></Name>
<NumElts>1</NumElts>
<DBL>
<Name></Name>
<Val>3.14159</Val>
</DBL>
</Cluster>