HP-35’s x^y Why?

[robve]

(11-03-2021 06:41 PM)J-F Garnier Wrote:  It seems to me that having a y^(1/x) function is much more robust.

I agree that the floating point result of 1/x is certainly not reversible for all nonzero integers x. But surely it is reversible for a certain useful range of nonzero integers x when using proper internal floating point representations that include additional correction digits for rounding to 10 digits (or whatever the calculator uses).

This can be robust by determining a valid set of integers x, for example the largest positive k such that x=[1,k] is a valid range for 1/x to be "practically" accurately reversible (at least avoid unnecessary roundoff of the correction digits) in order to perform y^(1/x) accurately. Furthermore, determining a range of integers x means that xroot can be used to produce a more accurate answer for y^(1/x). I consider this a win.

However, and I think this your concern, ultimately this means accepting that 0.333333333333 with two extra digits as internal float representation equals 1/3 but 0.3333333333 rounded, displayed or entered does not. Calculators use internal extra digits for a reason though. Trying to replicate this with C/C++, Lua and Python can be a bit misleading if the algorithm isn't replicating the correction digits roundoff rules exactly.

Either way, that is not happening in the Saturn architecture for that reason or the other reason is internal floating point roundoff in which 1/x*LOG(y) differs from LOG(y)/x. It's unnecessary to get (125)^(1/3)=4.9999..., especially for small integer values of x such as x=3. On the other hand, the decision makes sense in historical context, because additional complexity requires more ROM space.

- Rob