HP-35’s x^y Why?

[EdS2]

x^1/y is the yth root of x. I notice my (few) Sharps and Casios offer an xth root of y.

[rprosperi]

(11-01-2021 09:54 AM)EdS2 Wrote:  x^1/y is the yth root of x. I notice my (few) Sharps and Casios offer an xth root of y.

Of course, good point. It's typically shown the 'other' way, with the radical sign, but the swapping of the arguments made it less obvious. Curious that these models chose to print the function description this way, when nearly all other machines use the 'normal' way (though of course normal is relative).

[John Keith]

(11-01-2021 09:54 AM)EdS2 Wrote:  x^1/y is the yth root of x.

Yes, but it should still be y^(1/x).

[ijabbott]

(10-31-2021 09:39 PM)Steve Simpkin Wrote:  

(10-31-2021 08:18 PM)rprosperi Wrote:  Interesting, I don't think I've ever seen the predefined function X^(1/Y) before, never-mind have it right on the keyboard. Thx for sharing the photo.

No problem, Bob Here are some other Casio models that had that key as well.

I think the first Casio with that function was (probably) the fx-39.

[cdmackay]

As a related question, I've often wondered why, after the 28S, HP started including the arguably unnecessary n-th root key, e.g. on 32SII, 48GX, 50g, Prime, when they'd done perfectly fine without it up til then? It doesn't save keystrokes, since it's generally a shifted fn when included.

And presumably that was the reason that 1/x is often next to y^x on earlier calcs?

[Gene]

As to question two: I suspect 1/x was put next to y^x due to the root association.

First question? I have no idea.

Gene

[ijabbott]

(11-02-2021 04:22 PM)cdmackay Wrote:  As a related question, I've often wondered why, after the 28S, HP started including the arguably unnecessary n-th root key, e.g. on 32SII, 48GX, 50g, Prime, when they'd done perfectly fine without it up til then? It doesn't save keystrokes, since it's generally a shifted fn when included.

It would make sense if the n-th root key returned a real root when Y is negative and X is an odd integer. The Prime does that, but the 50g doesn't. The 32SII doesn't like fractional powers of negative numbers, but is happy to do odd integer n-th roots of negative numbers.

[robve]

(11-01-2021 09:54 AM)EdS2 Wrote:  x^1/y is the yth root of x. I notice my (few) Sharps and Casios offer an xth root of y.

I strongly suspect that a dedicated key for the y'th root of x (or the x'th root of y with Sharp) surely indicates that negative x with odd y'th roots are supported, e.g. (-27)^1/3 returns -3. This requires some careful implementation logic to determine that x is a perfect reciprocal (e.g. 0.142857142 is really close enough to 1/7, or is it?). I noticed that older and simpler scientific calculators don't support negative x, e.g. Ti-25 and Sharp EL-5100. I don't own a sufficiently large collection of calculators to test this hypothesis, so correct me if I'm wrong.

Because raising to a power ^ is right-associative in almost all programming languages and systems that support algebraic expressions, i.e. 2^3^4 is evaluated as 2^(3^4), parenthesis are not required and the internal stack stays shallow with only two values on top. The equivalent in RPN would be to enter the y'th root first before the value x. This keeps the stack shallow with two values on top. Reversing the x and y order in RPN hampers RPN calculators compared to algebraic calculators, to have to stack N levels of values for N powers: 2 ENTER 3 ENTER 4 ^ ^. That's not good with a small stack of X,Y,Z,T.

- Rob

[robve]

(11-03-2021 02:37 AM)robve Wrote:  I strongly suspect that a dedicated key for the y'th root of x (or the x'th root of y with Sharp) surely indicates that negative x with odd y'th roots are supported, e.g. (-27)^1/3 returns -3. This requires some careful implementation logic to determine that x is a perfect reciprocal (e.g. 0.142857142 is really close enough to 1/7, or is it?). I noticed that older and simpler scientific calculators don't support negative x, e.g. Ti-25 and Sharp EL-5100. I don't own a sufficiently large collection of calculators to test this hypothesis, so correct me if I'm wrong.

Let's try this out. While 1/7 equals \( 0.\overline{142857} \), entering 10 digits .1428571429 on a 10 digit calculator should fail, because internally 12 digits are significant with the last 2 rounded off and internally 1/7 has 12 digits (or more depending on the calculator):

Sharp EL-5200:
(-128)^(1/7)=-2 is OK
(-128)^A=-2 with variable A=1/7 is OK
(-128)^(.1428571429) ERROR (as can be expected)

Sharp PC-1474 and PC-E500 and most other Sharp PC:
(-128)^(1/7)=-2 is OK
(-128)^A with variable A=1/7 ERROR because simple variables hold 10 digits in Sharp S-BASIC
(-128)^(.1428571429) ERROR (as can be expected)

HP-35s:
ALG mode: (-128)^INV(7) ERROR
RPN mode: 7 1/x 128 (-) y^x ERROR

Ti 36X:
(-128)^(1/7)=-2 is OK
(-128)^(.1428571429) ERROR (as can be expected)

Sharp EL-506A:
(-128)^(1/7)=-2 is OK
(-128)^(.1428571429) ERROR (as can be expected)

Philips SBC 158
(-128)^(1/7) ERROR also 7-th root of -128 fails
(-128)^(.1428571429) ERROR (as can be expected)

Ti-25
(-128)^(1/7) ERROR
(-128)^(.1428571429) ERROR (as can be expected)

All of these calculators have an n-th root key except the Ti-25. I consider the Philips scientific calculator a nice metallic machine from the early 80s, but not a serious calculator. It also has a quirk: digits are not shifted to the left when entered, the first digits simply stay on the left.

But why, oh why HP-35s did you fail?

- Rob

[Albert Chan]

(11-03-2021 03:46 AM)robve Wrote:  HP-35s:
ALG mode: (-128)^INV(7) ERROR
RPN mode: 7 1/x 128 (-) y^x ERROR

You are assuming the reason it fail is INV(INV(7)) does not revert back to 7 ?
My guess is it never even check that.

Negative number raised to non-integer exponent is a automatic fail.

Try (-128)^INV(3) instead, since INV(INV(3)) = 3 (binary or decimal, any precision)

[J-F Garnier]

(11-03-2021 02:37 AM)robve Wrote:  I strongly suspect that a dedicated key for the y'th root of x (or the x'th root of y with Sharp) surely indicates that negative x with odd y'th roots are supported, e.g. (-27)^1/3 returns -3.

Yeap.

(11-03-2021 03:46 AM)robve Wrote:  HP-35s:
ALG mode: (-128)^INV(7) ERROR
RPN mode: 7 1/x 128 (-) y^x ERROR

... these calculators have an n-th root key except the Ti-25.

But why, oh why HP-35s did you fail?

Here, I don't follow you. Why not using the nth-root key?
With it, the 35S doesn't fail. No need to create a new artificial weakness of this machine.

An additional benefit of the nth-root is a marginally improved accuracy.
Example on Saturn-based HP machines:
125^(1/3) = 4.9999...
but XROOT(125,3)=5 exactly.
(unless Albert finds a counter example :-)

J-F

[robve]

(11-03-2021 07:45 AM)Albert Chan Wrote:  You are assuming the reason it fail is INV(INV(7)) does not revert back to 7 ?
My guess is it never even check that.

Negative number raised to non-integer exponent is a automatic fail.

Try (-128)^INV(3) instead, since INV(INV(3)) = 3 (binary or decimal, any precision)

Yes. Implementation logic of ^ dictates to check that 1/(1/x) = x or close enough with respect to macheps. If 1/(1/x) ~= x integer then (-y)^(1/x) = -(y^(1/x)).

Yes. Obviously, for negative x and non-integer y.

Sort of. However, assuming y is limited to "easy" integer reciprocals only, then this is still an epic fail.

Another fail:

Casio fx-7000G:
(-128)^(1/7) ERROR
(-128)^(.1428571429) ERROR (as can be expected)

Of course, the Casio allows an explicit nth root operation and so does the HP 35s:
7 n-root (-128)=-2 OK

I'm not impressed by this Casio either.

The lazy way to implement n-th root is to check if x is integer and calculate x n-root -y with -(x n-root y) = -(y^(1/x) = -EXP(LOG(y)/x).

The correct way for a calculator's implementation logic is to consider the fact that x n-root y = y^(1/x) = signum(y) |y|^(1/x) if x is integer. By using this identity and root-power symmetry we can also avoid taking the LOG of a negative number.

- Rob

[robve]

(11-03-2021 07:47 AM)J-F Garnier Wrote:  Example on Saturn-based HP machines:
125^(1/3) = 4.9999...
but XROOT(125,3)=5 exactly.

Wow. This is even worse, if true:

125^(1/3) = EXP(1/3*LOG(125)) and XROOT(125,3) = EXP(LOG(125)/3) yet somehow these differ on Saturn-based HP machines. Roundoff issues.

This cheap Casio gets it right:

Casio fx-115ES plus
(-128)^(1/7)=-2 OK
(-128)^(.1428571429) ERROR (as can be expected)

- Rob

EDIT: not entirely surprising for the Casio fx-115ES plus, because this model supports exact rationals i.e. 1/3 is exact and 1/(1/3)=3 exactly.

[Albert Chan]

(11-03-2021 07:47 AM)J-F Garnier Wrote:  An additional benefit of the nth-root is a marginally improved accuracy.
Example on Saturn-based HP machines:
125^(1/3) = 4.9999...
but XROOT(125,3)=5 exactly.

Does HP71B has XROOT (or equivalent ?)
I am curious of how to efficiently implement this ...

(11-03-2021 01:44 PM)robve Wrote:  Implementation logic of ^ dictates to check that 1/(1/x) = x or close enough with respect to macheps.
If 1/(1/x) ~= x integer then (-y)^(1/x) = -(y^(1/x)).

Implementation logic is whatever the designer think it should behave.

Example, HP71B does not check reciprocal = "close enough" integer.
Negative number raised to non-integer exponent is a automatic fail.

>1/(1/3)
3
>(-8)^(1/3)
ERR:Neg^Non-int

(11-03-2021 02:38 PM)robve Wrote:  This cheap Casio gets it right:

Casio fx-115ES plus
(-128)^(1/7)=-2 OK
(-128)^(.1428571429) ERROR (as can be expected)

It can also be fooled to get it wrong

(-128)^(1÷6.999) = 2.00019808 ???

[J-F Garnier]

(11-03-2021 02:38 PM)robve Wrote:  

(11-03-2021 07:47 AM)J-F Garnier Wrote:  Example on Saturn-based HP machines:
125^(1/3) = 4.9999...
but XROOT(125,3)=5 exactly.

Wow. This is even worse,

Rob, I can be interested by comparing math algorithms, but not by systematic denigrating.

Quote:... if true:

I can't imagine you believe that I wrote something without checking, or worse that I may deliberately be giving incorrect information :-(

To go back to a fair discussion, the 125^(1/3) result is right with 12-digit arguments, there is no incorrect rounding.
125 ^ 0.333333333333 = 4.99999999999195...
It is inaccurate if you think you are computing the 3rd root of 125. Thus the interest of the y^(1/x) aka XROOT function.

As for machines that are lying to artificially give nice results (1/3*3 = 1 or 0.999..99 ?, SIN(pi [rad]) = exactly 0 or a small number?), this was discussed many times, especially about the HP and TI differences. Of course, I'm speaking about numeric, not symbolic calculations.

(11-03-2021 03:21 PM)Albert Chan Wrote:  Does HP71B has XROOT (or equivalent ?)
I am curious of how to efficiently implement this ...

No, unfortunately, even in the MATH ROM.

J-F

[robve]

(11-03-2021 03:43 PM)J-F Garnier Wrote:  

(11-03-2021 02:38 PM)robve Wrote:  Wow. This is even worse,

Rob, I can be interested by comparing math algorithms, but not by systematic denigrating.

Math, logic and engineering people are not subject to critique or discussion here.

Justly criticizing a machine or a technology is not denigrating. There is no rationale to anthropomorphize objects or algorithms. There is no systematic aspect to that either. Really strange to hear accusations to intentionally repeatedly criticizing the same thing. I've never posted anything negative about the HP 35s before in my life.

I hold the (former) engineers at HP (and other brands) in high esteem for technical prowess and innovation.

It is not uncommon to find poor decisions with respect to handling roundoff in the past. It is a tradeoff. Increasing the fp accuracy by adding roundoff "correction" digits or increasing the algorithmic complexity of an arithmetic operation is not without manufacturing cost. Consider for example Sharp PC-1500 3^2 does not equal 9 exactly. At least they did not hide it. It's in the manual with an explanation. I don't care what machine or brand we're talking about.

Algorithms and implementation decisions can be poor, often in hindsight. That is why we fix em and continually innovate. If someone defends a poor implementation then that's open to debate, critique, or correction. In self-reflection, I like to hear if something is not working as documented so it can be fixed. You want to build something solid from the get-go. Unfortunately, to avoid any algorithmic mistakes requires algorithm proofs, think axiomatic or denotational semantics to provide such strong assurances. This can still go wrong if the assumptions (weakest preconditions in axiomatic semantics) are not met in practice. The Ariane 5 disaster comes to mind.

(11-03-2021 03:43 PM)J-F Garnier Wrote:  It can also be fooled to get it wrong

(-128)^(1÷6.999) = 2.00019808 ???

That's why I was thinking that there would be a calculator that returns (-128)^(.1428571429)=-2 perhaps, but did not find yet it though I'm sure there is a value close enough to 1/7 that will trip it up. (-128)^(1/6.999)=2.00019808 is a good one! I suspect that moving to smaller integer reciprocals beyond 1/7 could produce some interesting artifacts.

So no, I wouldn't use this Casio either to launch rockets See? I fixed it: this sure sounds better than "it is even worse"!

- Rob

[Albert Chan]

(11-03-2021 03:21 PM)Albert Chan Wrote:  Does HP71B has XROOT (or equivalent ?)
I am curious of how to efficiently implement this ...

First try ...

y^(1/n) = y^float(1/n) * y^ε       , where ε = 1/n - float(1/n) = (1 - n*float(1/n)) / n

Correction y^ε = exp(ε*ln(y)) ≈ 1 + ε*ln(y)

Code:

function surd(y,n)      -- nthroot of y
    local z, sgn = 1/n, 1
    if y<0 and n%2==1 then y=-y; sgn=-1 end
    local x = y^z * sgn
    z = fma(n,-z,1) * x
    return z==0 and x or x + z*log(y)/n
end

lua> surd(-8, 3)
-2
lua> surd(-8, 3.1)
-NaN

lua> surd(12345,3)
23.111618749807267
lua> 12345 ^ (1/3)
23.111618749807263

[J-F Garnier]

(11-03-2021 05:46 PM)robve Wrote:  

(11-03-2021 03:43 PM)J-F Garnier Wrote:  Rob, I can be interested by comparing math algorithms, but not by systematic denigrating.

Math, logic and engineering people are not subject to critique or discussion here.

Justly criticizing a machine or a technology is not denigrating. There is no rationale to anthropomorphize objects or algorithms. There is no systematic aspect to that either. Really strange to hear accusations to intentionally repeatedly criticizing the same thing. I've never posted anything negative about the HP 35s before in my life.

Sorry if I over-reacted (not usual for me), and the term 'denigrate' was maybe not the right one. But there was no rationale to judge the HP implementation worse (worst than Sharp?). The reason of the 125^(1/3) HP result was easy to check and quite obvious.

(11-03-2021 05:46 PM)robve Wrote:  

(11-03-2021 03:43 PM)J-F Garnier Wrote:  It can also be fooled to get it wrong
(-128)^(1÷6.999) = 2.00019808 ???

For the record, this quote is from Albert, not me.

Basically, I don't agree with you that a 'correct' y^x implementation must check that the x value is close to the reciprocal of an integer, to manage the case of odd nth-root of negative numbers. I understand that Sharp and others do it and give nice results, but it seems very artificial for me, and prone to wrong assumptions as Albert pointed out. It seems to me that having a y^(1/x) function is much more robust.

J-F

[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

[Jeff O.]

(10-30-2021 06:33 PM)Matt Agajanian Wrote:  Hi all.

Yeah, all it takes is an x<>y press before the x^y key. So what was the reasoning for the 35’s x^y instead?

Thanks

I thought that I read somewhere that this was due to the lack of a 10^x function on the 35. Having x^y instead of y^x would enable users to more easily take the antilog of a number by entering 10 and pressing x^y, i.e., no swap required. Of course this would only reduce keystrokes if the number whose antilog was desired was already in x as a result of some other calculation, i.e., if it had to be entered from scratch no keystroke savings would result. Perhaps HP studied and found that this would more often be the case. All* subsequent scientific models had a built-in 10^x function, so they could switch to the possibly more natural feeling y^x.

* - I did not check every subsequent scientific model to verify the veracity of this statement, but I believe it to be correct.