quotient & remainder bug

[tbob]

CC hit the real nail on the head.  Why would you want to use Q&R with floating point numbers, it was meant to be used with integers only?  Think about it.  Just the word "Remainder" means it is an integer function.  I must confess that I never really used Q&R with floats before this thread.  So this whole arguement is now pointless.  Lets have a good laugh.

One thing for sure, I learned a lot about binary representation of floats thanx to JPD's in depth explanations.  Merci, mon cousin!!!

[JeanPierre]

I also admit that I've never used Q&R with floats; the function is too sensitive to numerical rounding... It is better to scale the inputs to integers.
However, the thread fixed my STARvation...

[Jochen]

Thanks a lot to everyone who has contributed to this thread. In the Applications Engineering department of NI we have to deal with this kind of question quite frequently and we typically give similar answers as JPD (even though not so sophisticated and detailed). I think you have covered almost all aspects of this topic now so this thread is a great source of knowledge for further reference.

Best regards,

Jochen Klier
Applications Engineering Group Leader

[Anthony_de_Vries]

Don't want to restart the whole discussion...   Just some final thoughts...

I think that one should make a distinction between the bits that a variable is composed of, and the real number that the variable is supposed to represent. The question is how do you want people to work with their routines.   Do we want the user to be bothered by the fact that the computer cannot accurately represent the number 0.2 internally? 

I don't like the idea that we should let quantization errors influence the result of the calculation.  Normally, quantization and rounding errors are automatically taken care of at the input and output.  In both input and output rounding occurs.  (Default 6 digits in Labview)   With most calculations, rounding as the final output is sufficient to make sure that you aren't bothered by the inaccurate representation of the real numbers by the computer. 

However, in routines like QR, the inaccurate number representation does influence the result.  Suddenly the least-significant bit, has become the most-significant bit....  For a faithfull representation of the numbers, the QR routine should use the same accuracy as the input and output.   The rest of the digits are only there to make it possible for the computer to calculate numbers that it can't accurately represent, without affecting the end result.

I don't agree with the idea that an alternative QR would be less accurate. Quantization and rounding errors have allready made the input inaccurate before it reaches the QR routine. Hence, also the output of ANY calculation on those numbers will be inaccurate to at least the same degree.   Obviously, a QR routine that rounds after 10 digits, is inaccurate in the following digits.   However, a QR routine that doesn't round at all, can be inaccurate in the first digit!   Because it takes inherently inaccurate last digits as significant. 

Concluding:

Purely seen as some operation on some bits, the QR routine is accurate. 
But seen as an operation on a real number (which is represented in a finite accuracy), the current QR routine is inaccurate. 

The solution...

I think there is certainly need for a more proper way to handle these situations.   The current implementations might be proper according to one point of view or some IEEE specification... but they are also nearly useless in practice.  If you instruct everyone not to use the 'equal?' function on reals, because of quantization and rounding errors, then you might wonder why you have the function at all?

Making a alternative yourself is actually surprisingly cumbersome...  I like my own appoarch a lot, simply rounding to a certain number of digits, before using the floor operation. But the only way I could do that, was by converting DBL to SGL.  That's a bit overkill...  And SGL input, there isn't such a solution. Then you would need to do tricks like multiplying etc, that we have also seen examples of...   They all seem rather elaborate....    (And slow as some mentioned)

What I would like to see in Labview is:

• QR and equality alternatives that give meaningfull result.  i.e. that apply rounding to remove the quantization and rounding errors.
• vi's for rounding of reals to a certain accuracy/digit.   That will allow users to handle these issues themselves more easily/effectively.

And then NI only has to make sure that it's clear to the user which implementation is being used, and what the effects are.  That should be simple enough.   For example, having an 'equal?' vi with a square icon, in stead of the triangular shape is probably allready a clear enough distinction.  (The rest can be in the description and help)

[Kevin_Price]

Anthony, others:

In the past where I've seen discussions about new feature requests or changed behavior requests, the NI folks tend to ask for some example "use cases."  So, what are some specific examples where Q-R behavior needs to be different?  What was the app that brought it to your attention in the first place?

What I've gathered from your posts is that you're predominantly concerned with situations where one or both of the inputs x & y come directly from user-entered values on a front panel.  And the problem you see is that the value that the user intends to enter is not exactly equal to the internal representation of the value.  I.e., a user enters "0.2" but the IEEE representation isn't exactly 0.2    (The same thing may occur for programmer-entered constant values on the block diagram, but arguably the programmer can be expected to anticipate floating point issues more than the user.)

The issue keeps coming down to: users think in base 10, floating point values are stored in base 2.  The two will only occasionally agree exactly.

I'm beginning to think that the only real solution without drawbacks (to LV programmers -- I'm sure there's plenty of drawbacks to NI) is a new numeric datatype.  Maybe something similar to a DBL, with bits laid out to represent integer values of mantissa and exponent.  The only difference is that it would use a base-10 exponent.  Support this datatype for simple numeric primitives (add,mult,log10,Q-R,...). Let the datatype be subservient so it when paired with a base-2 DBL as inputs to a numeric primitive, the base-10 datatype gets coerced -- this minimizes breakage of existing code.

I don't know the field and am too lazy/pressed for time to search now.  But I would guess there are some math library implementations out there that have already done this sort of thing?  Maybe some sort of de facto standard?

Anyway, this type of solution allows a programmer to use the new base-10 datatype for user-entered values, and to maintain base-10 through a series of (simple) calculations that will produce user-expected results.  It would require NI to develop a math library, but would not require additional icons to the numeric palette.  Existing functions would just be overloaded for the new datatype.

Ok, any comments?  What drawbacks am I missing?

-Kevin P.

[rolfk]

---

@Kevin Price wrote:

I haven't carefully thought through or experimented with the Q-R function in particular.  But as far as being able to program around the inaccuracies, wouldn't it be enough to simply compare the remainder to the dividend?  If it's "approximately equal" (based on methods more-or-less acknowledged necessary for floating point in this thread), subtract the dividend from the remainder and adjust the quotient.

Somewhat of a pain, granted, but rougly on par with the pain of handling floating-point equality, no?

---

Doing it that way would result in a Quotient of 5.000000000000000000 and a Remainder of -0.0000000000000000555111512312578270.

To me a negative remainder is actually more unintuitive than the normal behaviour.

Rolf Kalbermatter

[WNM]

---

@tbob wrote:

Why would you want to use Q&R with floating point numbers, it was meant to be used with integers only?  Think about it.  Just the word "Remainder" means it is an integer function. 

---

I must admit that after all this discussion I went through a bunch of my old code to see where I had used the Q&R function and (thankfully) I only found one place where I had used it with floats. In that one case I was separating the integer and fractional components of real numbers and the divisor (Y) value into the Q&R function was a 1.0 which should be safe from any rounding errors in any number base currently in use (at least on this planet):smileyvery-happy:

[rolfk]

---

@Anthony de Vries wrote:

I don't like the idea that we should let quantization errors influence the result of the calculation.  Normally, quantization and rounding errors are automatically taken care of at the input and output.  In both input and output rounding occurs.  (Default 6 digits in Labview)   With most calculations, rounding as the final output is sufficient to make sure that you aren't bothered by the inaccurate representation of the real numbers by the computer. 

---

LabVIEW does not do any rounding on the actual number at all anywhere! It is only the display routine in a numeric control that has by default a precision of 6 digits (and actually does some smart rounding too) but the number that flows through the wire always stays the same with the maximum precision (~16 digits for a double) for that datatype.

And if you like it or not, dealing with floating point numbers on a computer is by definition about caring about quantization errors. Your proposed workarounds all have a number of implications. Basically each and every math function that should do the quantization approximation for you would have to have an extra input where you specify as to how many digits you want the results be correct. This would not make the use of the function easier as you still would have to do the analysis as to how many digits your result should be accurate to be perceived correct by your end user.

Implementing a new data type such as BCD may be another solution but to be able to support arbitrary precision it would have to be string based and that would get SLOOOOOOOOOOOOOOOOW to calculate anything on it. Still using such a BCD datatype on anything but a decimal number would actually result in even worse precision.

Rolf Kalbermatter

Message Edited by rolfk on 02-02-2006 04:25 PM

[Marc_A]

I've been following this thread, and I just came across something that I would like to add.  Why does Q&R default to a float when you right click an input and say create -> constant?  It seems to me that they expected this to be used with floats.  I agree with the position that this is an integer function and doesn't give an accurate "representation" of what's really going on when used with floats, but maybe the inputs should default to integers to show people that aren't familiar with the underlying base-2 representation of floats that causes all of these problems.

[Kevin_Price]

To me a negative remainder is actually more unintuitive than the normal behaviour.

I can see that, though it is negative in an "almost = to 0" kind of way.  On a somewhat similar note, I toyed very briefly with Q-R yesterday and was reminded again how the behavior with negative inputs goes against my intuition.  I'm willing to blame my intution for the disagreement though!

I think I recall a long-ago app where one or both of the Q-R inputs could be negative.  And I think I ended up using a formula node or expression node or something instead of Q-R so I could get the results I actually wanted/expected.

So even with integer inputs, Q-R may hold some gotchas, at least if your intuition works like mine.

-Kevin P.