quotient & remainder bug

[altenbach]

Decimal digits have little meaning in binary representation and many simple decimal fraction have an infinitly repeating bit pattern in any floating point representation (SGL, DBL, EXT). IF you need to work with precise decimal digits, you need to implement a fixed point math and e.g. define 0.001 as binary "1".

QR does not seem to be very useful with fractional Y inputs anyway. It is also important that is is fast!  Have a look at the the recent prime factor challenge. If the code for the trial divisions suddenly takes three times longer because QR needs to do exception testing and rounding, I would not be very happy. 😉

[tbob]

There should be two versions of math functions.  I have stated this before.  The current version for integers and such, and another version for floating point numbers.  Then if you want to do fast things like the prime factor challenge, you can use the standard function.  If you want to be sure your program isn't introducing rounding errors because you are using DBLs, you can use the floating point functions.  C has "DIV" and "/", both do division.  "DIV" is for integers and "/" is for floats.  The floor function in C uses "/".  NI could offer us the same and everyone would be happy.  I, for one, would sacrifice a few microseconds to get rid of rounding errors.

[Ray.R]

Here is a poor attempt (just before grabbing lunch) to improve the quotient...  as long as you don't care too much about the accuracy of the remainder..  it's poor!  very poor...  shame to post it, actually...

but what the heck... here it is..

as I said, it's ok on the quotient part...  Using U32 makes it worse when the number exceeds 2^32..

(oh boy... I'm asking for trouble by posting this... ok... where's the courage... 😉

have fun tbob!!  😄

(Maganne pas trop l'cousin!!)

[JeanPierre]

The real issue here is that we're taking the floor value of the result of a floating operation that yields almost an integer. Depending of the internal implementation of the operations and even the order of these operations (which are compiler specific) the result may be Integer N±epsilon. For floating operations the difference is not significant. However, taking the floor value of such a number indeed may give N or N-1 depending of the rounding errors involved in the float computation. Great care must be taken by the programmer that such rounding errors have no consequences on the required result.

For example take the Quotient and Remainder node and compare its results to the floor(x) function in a formula node and the division node followed with a Round to -Inf node
For 1 and 0.2 Q&R computes 4 (floor(4.999999...)) and other methods give 5
For 1.2 and 0.24 three methods give 5

The difference comes from different code that execute with different math routines and rounding errors. It may even depends on how the string "1.2" is converted to a real number by the compiler e.g. if the least significant bit of the float representation is rounded up or down.

It all boils down to the programmer's need of to which accuracy is the number 4.9999999... is an integer.

You may wish for smarter function that rounds "correctly for decimal values for X digits" but nevertheless the native functions have the correct and accurate behavior.

[tbob]

Pretty close "mon cousin".  Try this slight modification to get the correct remainder.

[tbob]

Mon cousin de l'autre cote de la mer (that's JPD for you French challenged folks):

You are missing my point.   I'm not saying that the Q&R function itself is not accurate.  It is accurate.  I'm saying that it is not reliable when using floats.  As you said, great care must be taken to overcome rounding errors.  I don't have to take great care when I use C because the have a separate division function for floats ("/" vs "DIV").  Why can't NI provide functions for floats like C does?  What about the equality function?  Does anyone use this for floats?  No.  Not because it is innacurate or incorrect.  It is very accurate and very correct.  But it is useless with floats because it doesn't take rounding errors into consideration.  Q&R is also accurate and correct, but useless with floats unless you take the band aid approach and take great care, blah, blah, blah.

Let's drop the arguement of whether Q&R is correct or incorrect.  It works exactly as designed.  I think we can all agree on that.  Let's ask NI for floating point functions that account for rounding errors by calculating in a higher precision than the inputs, and rounding the output to the same precision as the input.  This will give reliable results in all cases with floating point numbers.  Q&R and Equality are two functions that need special versions for floats.

[Ray.R]

---

@tbob wrote:

Try this slight modification to get the correct remainder.

---

OOps!!!  😮

I forgot to take care of the offset that I created....  😮

Thanks le cousin  😄

I will have to play with it to see how it reacts to various shapes of numbers for both x & y, ie:  0.1, 0.0123456, 1234.5677889, 1234567.8934, 1232345, 0.000000001, etc...

😄

[Anthony_de_Vries]

Dear Jean-Pierre, 

I think you're missing the point.

You're absolutely right when you say that the programmer has to make sure that quantization and rounding errors have no consequences on the required result. 

And that's exactly where the QR function goes wrong!  

In the QR funtion, the rounding errors do influence the result.  And in a rather dramatic way: the difference between the answer 4 or 5 is quite significant.    By your own rules, that means that the QR does not have correct and accurate behavior!    

The reason for that, is that the QR function is not comparable to the normal native real operations.  To produce correct and accurate results, the QR function MUST perform some rounding internally. To which accuracy it should round, is a matter of implementation.  One could ask the user to specify the number of significant digits.  Or one could simply assume a certain number of digits based on the input. (what I did, by converting DBL to SGL)

We, as programmers, can in no way assure that the QR function gives correct and accurate results! This is something that must be taken care of inside the QR vi.

This is different from issues with the equality function. In that case, the programmer can make sure that quantization and rounding errors don't influence the end results, by first rounding the variables, and then performing the equality function.   Such a solution is not possible with the QR function.

[becktho]

Hi

But you as programmer could also ensure the accuracy when using the Q&R.

You want to calculate 1%0.2, well, we all now know the result: 4 / 0.2

Why not just wire 10%2? And the result is 5 / 0 - just have a try. Without doing any rounding or converting from me.

[DavidJCrawford]

Hi folks

I was curious how it would work out if you used a formula node to calculate IQ=floor(x/y) and R=x-y*floor(x/y). Just like what the Q&R function does.

Interestingly the answer from the formula node for IQ is 5 not 4. They should give the same answer but they don't.

Also the answer the formula node returns for R=x-y*floor(x/y) isn't right. That can be "fixed" by changing the way R is calculated in the formula node which is R2=Ra-Rb where Ra=x and Rb=x*floor(x/y).

I have attached a vi in 7.1 to demonstrate.

David