HP35’s x^y Why?

11012021, 09:54 AM
Post: #21




RE: HP35’s x^y Why?
x^1/y is the yth root of x. I notice my (few) Sharps and Casios offer an xth root of y.


11012021, 12:40 PM
Post: #22




RE: HP35’s x^y Why?
(11012021 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). Bob Prosperi 

11012021, 02:47 PM
(This post was last modified: 11012021 02:47 PM by John Keith.)
Post: #23




RE: HP35’s x^y Why?  
11012021, 08:40 PM
Post: #24




RE: HP35’s x^y Why?
(10312021 09:39 PM)Steve Simpkin Wrote:(10312021 08:18 PM)rprosperi Wrote: Interesting, I don't think I've ever seen the predefined function X^(1/Y) before, nevermind have it right on the keyboard. Thx for sharing the photo. I think the first Casio with that function was (probably) the fx39. — Ian Abbott 

11022021, 04:22 PM
Post: #25




RE: HP35’s x^y Why?
As a related question, I've often wondered why, after the 28S, HP started including the arguably unnecessary nth 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? Cambridge, UK 41CL/DM41X 12/15C/16C DM15/16 17B/II/II+ 28S 42S/DM42 32SII 48GX 50g 35s WP34S PrimeG2 WP43S/pilot Casio, Rockwell 18R 

11022021, 04:31 PM
Post: #26




RE: HP35’s x^y Why?
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 

11022021, 08:09 PM
Post: #27




RE: HP35’s x^y Why?
(11022021 04:22 PM)cdmackay Wrote: As a related question, I've often wondered why, after the 28S, HP started including the arguably unnecessary nth 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 nth 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 nth roots of negative numbers. — Ian Abbott 

11032021, 02:37 AM
Post: #28




RE: HP35’s x^y Why?
(11012021 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. Ti25 and Sharp EL5100. 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 rightassociative 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 "I count on old friends"  HP 71B,PrimeTi VOY200,Nspire CXII CASCasio fxCG50...Sharp PCG850,E500,2500,1500,14xx,13xx,12xx... 

11032021, 03:46 AM
Post: #29




RE: HP35’s x^y Why?
(11032021 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. Ti25 and Sharp EL5100. 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 EL5200: (128)^(1/7)=2 is OK (128)^A=2 with variable A=1/7 is OK (128)^(.1428571429) ERROR (as can be expected) Sharp PC1474 and PCE500 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 SBASIC (128)^(.1428571429) ERROR (as can be expected) HP35s: 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 EL506A: (128)^(1/7)=2 is OK (128)^(.1428571429) ERROR (as can be expected) Philips SBC 158 (128)^(1/7) ERROR also 7th root of 128 fails (128)^(.1428571429) ERROR (as can be expected) Ti25 (128)^(1/7) ERROR (128)^(.1428571429) ERROR (as can be expected) All of these calculators have an nth root key except the Ti25. 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 HP35s did you fail?  Rob "I count on old friends"  HP 71B,PrimeTi VOY200,Nspire CXII CASCasio fxCG50...Sharp PCG850,E500,2500,1500,14xx,13xx,12xx... 

11032021, 07:45 AM
Post: #30




RE: HP35’s x^y Why?
(11032021 03:46 AM)robve Wrote: HP35s: 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 noninteger exponent is a automatic fail. Try (128)^INV(3) instead, since INV(INV(3)) = 3 (binary or decimal, any precision) 

11032021, 07:47 AM
(This post was last modified: 11032021 08:01 AM by JF Garnier.)
Post: #31




RE: HP35’s x^y Why?
(11032021 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. (11032021 03:46 AM)robve Wrote: HP35s: Here, I don't follow you. Why not using the nthroot key? With it, the 35S doesn't fail. No need to create a new artificial weakness of this machine. An additional benefit of the nthroot is a marginally improved accuracy. Example on Saturnbased HP machines: 125^(1/3) = 4.9999... but XROOT(125,3)=5 exactly. (unless Albert finds a counter example :) JF 

11032021, 01:44 PM
Post: #32




RE: HP35’s x^y Why?
(11032021 07:45 AM)Albert Chan Wrote: You are assuming the reason it fail is INV(INV(7)) does not revert back to 7 ? 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 noninteger y. Sort of. However, assuming y is limited to "easy" integer reciprocals only, then this is still an epic fail. Another fail: Casio fx7000G: (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 nroot (128)=2 OK I'm not impressed by this Casio either. The lazy way to implement nth root is to check if x is integer and calculate x nroot y with (x nroot y) = (y^(1/x) = EXP(LOG(y)/x). The correct way for a calculator's implementation logic is to consider the fact that x nroot y = y^(1/x) = signum(y) y^(1/x) if x is integer. By using this identity and rootpower symmetry we can also avoid taking the LOG of a negative number.  Rob "I count on old friends"  HP 71B,PrimeTi VOY200,Nspire CXII CASCasio fxCG50...Sharp PCG850,E500,2500,1500,14xx,13xx,12xx... 

11032021, 02:38 PM
(This post was last modified: 11032021 02:51 PM by robve.)
Post: #33




RE: HP35’s x^y Why?
(11032021 07:47 AM)JF Garnier Wrote: Example on Saturnbased HP machines: 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 Saturnbased HP machines. Roundoff issues. This cheap Casio gets it right: Casio fx115ES plus (128)^(1/7)=2 OK (128)^(.1428571429) ERROR (as can be expected)  Rob EDIT: not entirely surprising for the Casio fx115ES plus, because this model supports exact rationals i.e. 1/3 is exact and 1/(1/3)=3 exactly. "I count on old friends"  HP 71B,PrimeTi VOY200,Nspire CXII CASCasio fxCG50...Sharp PCG850,E500,2500,1500,14xx,13xx,12xx... 

11032021, 03:21 PM
Post: #34




RE: HP35’s x^y Why?
(11032021 07:47 AM)JF Garnier Wrote: An additional benefit of the nthroot is a marginally improved accuracy. Does HP71B has XROOT (or equivalent ?) I am curious of how to efficiently implement this ... (11032021 01:44 PM)robve Wrote: Implementation logic of ^ dictates to check that 1/(1/x) = x or close enough with respect to macheps. Implementation logic is whatever the designer think it should behave. Example, HP71B does not check reciprocal = "close enough" integer. Negative number raised to noninteger exponent is a automatic fail. >1/(1/3) 3 >(8)^(1/3) ERR:Neg^Nonint (11032021 02:38 PM)robve Wrote: This cheap Casio gets it right: It can also be fooled to get it wrong (128)^(1÷6.999) = 2.00019808 ??? 

11032021, 03:43 PM
(This post was last modified: 11032021 04:22 PM by JF Garnier.)
Post: #35




RE: HP35’s x^y Why?
(11032021 02:38 PM)robve Wrote:(11032021 07:47 AM)JF Garnier Wrote: Example on Saturnbased HP machines: 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 12digit 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. (11032021 03:21 PM)Albert Chan Wrote: Does HP71B has XROOT (or equivalent ?) No, unfortunately, even in the MATH ROM. JF 

11032021, 05:46 PM
Post: #36




RE: HP35’s x^y Why?
(11032021 03:43 PM)JF Garnier Wrote:(11032021 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 PC1500 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 selfreflection, I like to hear if something is not working as documented so it can be fixed. You want to build something solid from the getgo. 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. (11032021 03:43 PM)JF Garnier Wrote: It can also be fooled to get it wrong 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 "I count on old friends"  HP 71B,PrimeTi VOY200,Nspire CXII CASCasio fxCG50...Sharp PCG850,E500,2500,1500,14xx,13xx,12xx... 

11032021, 06:22 PM
Post: #37




RE: HP35’s x^y Why?
(11032021 03:21 PM)Albert Chan Wrote: Does HP71B has XROOT (or equivalent ?) 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 lua> surd(8, 3) 2 lua> surd(8, 3.1) NaN lua> surd(12345,3) 23.111618749807267 lua> 12345 ^ (1/3) 23.111618749807263 

11032021, 06:41 PM
Post: #38




RE: HP35’s x^y Why?
(11032021 05:46 PM)robve Wrote:(11032021 03:43 PM)JF Garnier Wrote: Rob, I can be interested by comparing math algorithms, but not by systematic denigrating. Sorry if I overreacted (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. (11032021 05:46 PM)robve Wrote:For the record, this quote is from Albert, not me.(11032021 03:43 PM)JF Garnier Wrote: It can also be fooled to get it wrong 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 nthroot 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. JF 

11032021, 08:04 PM
Post: #39




RE: HP35’s x^y Why?
(11032021 06:41 PM)JF 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 "I count on old friends"  HP 71B,PrimeTi VOY200,Nspire CXII CASCasio fxCG50...Sharp PCG850,E500,2500,1500,14xx,13xx,12xx... 

11042021, 09:15 PM
Post: #40




RE: HP35’s x^y Why?
(10302021 06:33 PM)Matt Agajanian Wrote: Hi all. 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 builtin 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. Dave  My mind is going  I can feel it. 

« Next Oldest  Next Newest »

User(s) browsing this thread: 1 Guest(s)