newRPL - build 1255 released! [updated to 1299]

[Claudio L.]

(01-09-2018 04:27 PM)BarryMead Wrote:  That explains the behavior of the square root function, but why does the XROOT function return better more accurate answers? If the square root function were implemented as a call to XROOT with the second parameter fixed at 2 it would behave as expected. I wrote my own SQRT function like this that works better than the included one.
« DUP 2 XROOT » 'SQRT' STO

I had to look at the source code to answer this one! XROOT is an overloaded operator, and therefore each object type has its own implementation. In that context, each object type tries to preserve the type of the result.
Since both arguments were integer numbers, I included a trap that if the result (after rounding to the required precision) was actually an integer, an integer object type would be created and pushed to the stack, rather than a foreign object (real). It's a tiny performance penalty in a slow function like XROOT. As a side effect, results look better when you are working with integers.

There's an inconsistency, though. If you take an exact number that's not an integer, for example 0.36 2 XROOT will still produce 0.6. (approximated). The only way to check if the result is exact is by actually performing the operation 0.6^2 to see if it exactly matches the given argument. This is getting expensive so I'm not currently doing it (just for the luxury of getting the exact bit right).
I could add the same inconsistency to the square root, and test if the result is an integer, but I'm not sure it clarifies much.
If we had a faster CPU perhaps I wouldn't care much about speed and would certainly want that dot to be perfect each time.

EDIT: I'm open to ideas to implement this bit in a better way without doing expensive operations.