quotient & remainder bug

[JeanPierre]

I perfectly get your point dearest Anthony. You want a function that rounds values so that you get what your human, decimal wired brain expects.
We disagree when you say that Q&R is inaccurate. I say that Q&R is accurate given the accuracy of its inputs.
You say that Q&R must perfrom some rounding internally to give an accurate result but I say that rounding can only result in a less accurate function, a function that lowers the bit boudary where floor(N-epsilon) should give  N instead of N-1 then invalidating results for all numbers between N-epsilon and N. More accuracy on output can only be achieved by more accuracy on input. For example, 1%0.2 gives effectively 5 and 0 when you wire it with extended precision numbers.

Lets think binary. In double precision the number 0.2 is converted to 3FC9 9999 9999 999A . It slighty higher than 1/5 since the exact representation would require the periodic infinite  3FC9 9999 9999 9999 9999 9999.... . So the number is binary rounded to the nearest 3FC9 9999 9999 999A.  Since the number is higher than  0.2,  1/dbl(0.2) gives a number  slightly lower than  5 so floor (x) is 4. The remainder is computed to 3FC9 9999 9999 9998 which is almost 0.2. I strongly emphasis that these results are correct and accurate!
If you try the Q&R function on 3FC9 9999 9999 9999 instead of 3FC9 9999 9999 999A then you get 5 and 8.32667E-17. That is the kind of result you'd expect but this number is a less accurate approximation of 0.2.
The problem may also arise that the divider 0.2 is the result of other float operations. If it is compluted from DBL(10.2)+DBL(-10) then we have 3FC9 9999 9999 9980 which will output the expected 5 and 0 because it is less that 0.2 However, with DBL(10.3) + DBL(-10) + DBL(-0.1) that gives an even less accurate approximation of 0.2: 3FC9 9999 9999 99B3 . Should Q&R also figure that the user meant 0.2? This time the remainder is 3FC9 9999 9999 9934. Is it still equal to the divider? Where to stop the approximation?

Now what you want is a smarter (but less accurate) function that could figure out that Gee! the remainder 3FC9 9999 9999 9998 is almost equal to the divider 3FC9 9999 9999 999A surely the user prefers to have a zero remainder and floor(x/y)+1 instead of the accurate results. You have all the rights to require such a function, but it is not the Q&R burden to do that.

I have included a VI that does what you want. Did I say that it was less accurate than Q&R?

Message Edité par Jean-Pierre Drolet le 02-01-2006 02:07 PM

[Kevin_Price]

BTW, I don't think speed should ever take precedence over safeguards. The first requirement is that the function is predictable. 

FWIW, I think the crux of the difference of opinion is right here.  Other programmers would sometimes give speed precedence over safeguards.  Me for example.  Hopefully after careful consideration of the risks...

I'm glad you got this discussion about the Q-R function going.  While I don't think I've used it with floating-point inputs before, I'm also not sure how cautious I'd have been prior to this discussion.  While I've neither analyzed or tested it much, my "math intuition" keeps telling me that a rounding-based solution will still be subject to the same issues in principle, it just shifts them along several bits up from the LSB.  I'm afraid that you'd end up with a unique-and-imperfect solution that occasionally differs from the common-and-imperfect solution.  The advantage is that the new, unique solution will give expected results more often.  The disadvantage is that it can give unexpected results in ways that haven't really been characterized.

Maybe it's just my ignorance -- are there accepted, standard methods for this?  In the specific case of the Q-R function, do you round both inputs, neither input, or just one input - and which one and why?  Do your round up, down, or to nearest?  And when you're producing the outputs, aren't you still stuck with not being able to exactly represent powers-of-10 in any inherently binary format like SGL or DBL?   Somehow it starts to feel like a slippery slope -- I'm sure glad I'm not responsible for a universal implementation!

-Kevin P.

[johnsold]

Anthony,

I agree completely with Jean-Pierre.

Why don't you and tbob write a comprehensive math library using BCD math like the calculators mentioned earlier in this thread. Then you have complete control over input and output precision (and rounding, if necessary) and the algorithms employed. Post the VIs and see if anyone can find cases where they fail to work as you have defined them. If they work, those who find them useful would have a library available.

Lynn

[Ray.R]

---

@Jean-Pierre Drolet wrote:

I have included a VI that does what you want. Did I say that it was less accurate than Q&R?

@tbob wrote:

BTW, what is NI's take on all of this?  They have been curiously silent this whole time.  Will someone from NI respond?

---

Thank you JP...  😄

You have earned multiple stars on that excellent description.. 😉   As mentionned in previous reply(ies), workarounds can be developped.  Nice fancy code-bits here & there...  As a matter of fact do we have 4 different examples in this thread alone?

BUT!!!!  As JP says..  It is less accurate than Q&R.  It seems no matter what approach we use (other than having a full calculus >> slow << solution ), we will always see sets of numbers that will challenge the accuracy of the workaround.  It can't be avoided... There is a finite limite to represent the accuracy of numbers when they are in binary..   This will also affect any calculus series formula..

We all know this limit..  it's kinda part of life..

However, there is no reason why a function could not exist (with documented reasonable limitations) that would solve simple floating point entries for Q&R...  Which is what I think tbob is referring to.  The existing Q&R is fine.  Why can it no co-exist with a Floating-Q&R ?  😉

--- oh yeah... we'll have to define "reasonable limitations"...  we'll have to start a new thread on this one.

And here's how you get Molly 's attention  😄

Hi Molly 😄

JLV

Message Edited by JoeLabView on 02-01-2006 02:33 PM

[tbob]

"Mr. Lynn":  You are trying to make this look like Anthony and tbob against the world.  Don't go there.

I also agree with JPD's accuracy explanation.  Even though it is accurate and correct, I can't trust the results.  Even though Q&R is not to blame, I still can't trust the results.  That's not good.  I don't like taking a band aid approach and doing special things to ensure that I get the correct results.  Well, sometimes I have to, but I still don't like it.  I don't have time to do research and development on a proper Q&R algorithm for floating points, and its not my place to do such a task.  This burden should fall on NI, just like any other bug, whether you call it a bug or not.  It is still a problem for the entire community and should be fixed by NI.  The proper fix is to leave the present Q&A alone and create a special library for floating point math.  Does anyone have a problem with this solution (except for NI)?

[Ray.R]

Where's Ben..???

He's kept quiet on this one..  He's the Bug Reporter..  Maybe I can place a link in the bug report thread..   Or actually, tbob, you can do that as well..

Wishlist:  http://forums.ni.com/ni/board/message?board.id=130&message.id=332

Feb Bug Entries: http://forums.ni.com/ni/board/message?board.id=BreakPoint&message.id=1698

Or for distant family, I can enter it for you 😉

[Ben]

Molly is to smart to wander into a thread like this!

I was trying to follow her example.

I am a professed math whimp so my opinion hold little water. I will share the following thoughts.

1) If the "correct" math answer can be determined by voting, I think th eUS would be producing a lot more engineers and scientist than they are now.

2) OpenG may be interested in your work-arounds.

3) I have been told that if I could "come up with an idea that would save a lot of developers time" NI is interested.

4) Blue bars rarely step into a thread that is 50 replies deep.

5) It is better to not argue with JPD. Eventually you will ask a question that only he knows the answer to.

Ben

[chilly_charly]

I guess a number of LV Enthusiasts, including Ben, are just doing like me : enjoying the show, with tenderness... ;):D

I must confess that I would never have thought to do a Q&R operation on floats. I even didn't know that the operator was returning a meaningfull result  (and it is not !!!)!

I have not opened the proposed workarounds (sorry pals but I'm too busy...), and the obvious solution that came to my mind has probably been already presented in previous replies : my first instinctive move would have been to convert first the operators into integers by multiplying both by a large enough multiple of ten.

Thanks everybody for the excitement ! That's a most interesting thread !

[Ray.R]

---

@chilly charly wrote:

my first instinctive move would have been to convert first the operators into integers by multiplying both by a large enough multiple of ten.

Yes...  it's been done.. 

Actually, the one I posted starts by entering a string which is converted to a number then multiplied the 10 to the power of significant digits. Then Q&R.  Results are rather accurate..  depending on the extent (spread) of the two numbers.. 

example x = 123456.678 & y = 12.000123456   will not give you accurate results..  😮  for obvious reasons!  😉

You're a smart frog CC!  Wishing you the best vacation, mon ami!  Quand est le depart?

R.

[Molly K]

I wouldn't say I'm too smart to jump in on this thread, but I can say that this isn't my area of expertise which is why I have been quiet.  I have notified the appropriate people though. :)