HP-71B: 1^Inf Error

[Valentin Albillo]

.
Hi, Jean-François,

(06-09-2023 08:17 AM)J-F Garnier Wrote:  I only recently noticed that the HP-71B is raising an error when attempting to calculate 1^Inf. [...] I'm more curious of the reasons of the HP-71B development team: pure mathematical considerations or implementation constraints?

That, no one can know unless the development team left behind some notes/docs about it, or if the System source code includes comments on the implementation, which I haven't checked.

The HP-71B is a marvel in so many aspects but it has some glaringly bad decisions inflicted upon it, I posted some of the most egregious ones here, and left several others for another occasion.

One of them is the whole IEEE implementation, which no one in the users' base needed or asked for, and which only succeeded in adding unwanted complexity to the math functions implementation in assembler, also taking lots of ROM space to implement in the System and Math ROMs (and probably others), space which could've been put to much better use, and further slowing down the computations. I've extensively used the 71B for decades doing engineering and technical computations and not even once did I need its IEEE abilities. Positive zero ? Negative 0 ? For real-life applications ? Seriously ?

This preamble is just to make it clear that the development team did some very poor decisions, perhaps influenced by people at HP not belonging to the team and perhaps even dismissive of the HP-71B overall, and returning an Error for 1^Inf is one of those poor decisions.

In this thread, people are talking all the time of "limits" and "approaching" and such, but in fact none of that applies to this case because in 1^Inf we don't have the base "approaching" 1 or being 1 "in the limit", we have the plan, exact constant 1, and constants do not vary nor do they tend to some limit last time I checked.

When raising the exact constant 1 to the power of 100, 1000, one million, a Googolplex or Googolplex! (factorial), we don't get a result that approaches 1, we get exactly 1 every time, all the time, period. Thus, it's clear that 1^Inf can be safely and logically defined as 1, so the HP-71B should have returned 1 as a default value, perhaps with an overridable Warning for the squimish, but never ever Error.

Best regards and have a nice finde.
V.

[Werner]

(06-10-2023 06:29 PM)Valentin Albillo Wrote:  When raising the exact constant 1 to the power of 100, 1000, one million, a Googolplex or Googolplex! (factorial), we don't get a result that approaches 1, we get exactly 1 every time, all the time, period. Thus, it's clear that 1^Inf can be safely and logically defined as 1, so the HP-71B should have returned 1 as a default value, perhaps with an overridable Warning for the squimish, but never ever Error.

I agree with 1^Inf = 1, but not with the reasoning. Actually, I'm not sure I still agree with 1^Inf = 1. What's the difference with:

When raising 100, 1000, one million, a Googolplex or Googolplex factorial to the power of the exact constant 0, we don't get a result that approaches 1, we get exactly 1 every time, period.

Yet Inf^0 is undefined.

Cheers, Werner

[J-F Garnier]

Hi Valentin,

(06-10-2023 06:29 PM)Valentin Albillo Wrote:  One of [bad decisions] is the whole IEEE implementation, which no one in the users' base needed or asked for, and which only succeeded in adding unwanted complexity to the math functions implementation in assembler, also taking lots of ROM space to implement in the System and Math ROMs (and probably others),

I would not use words as abrut as you do, but I agree that the IEEE implementation added a significant amount of complexity to the math code, especially in the MATH ROM that I know a little, having reverse-engineered most of it. The management of the IEEE features for complex numbers is really complex (pun intended)...
BTW, the least useful IEEE feature, IMHO, is the inexact management (flag INX) that complicates the code a lot, for almost nothing.
In real, engineering live, all results are inexact by nature.

Quote:When raising the exact constant 1 to the power of 100, 1000, one million, a Googolplex or Googolplex! (factorial), we don't get a result that approaches 1, we get exactly 1 every time, all the time, period. Thus, it's clear that 1^Inf can be safely and logically defined as 1, so the HP-71B should have returned 1 as a default value, perhaps with an overridable Warning for the squimish, but never ever Error.

If we see the 1^Inf expression as 1x1x1x... there is little doubt that the result is 1.
But this is a trivial, useless case.
Who will ever need to program the expression Y=1^X and attempt to evaluate it for X=Inf to calculate 1x1x1x... ?

The point is that when the exponentiation code receives the arguments 1 and Inf to evaluate 1^Inf, the 71B has no way to know if these values come from a hardcoded 1^Inf expression, or are the results of the evaluation of a more complicate expression such as (1+1/X)^X for X=Inf.
In that later case, the correct answer for X=Inf should be 2.718281828... not 1.
Of course, in that case, the evaluation of (1+1/X)^X is "wrong" (i.e. not as expected) long before reaching X=Inf, for instance at X=1E12. So we may say it doesn't harm to give a "wrong" answer for X=Inf too, but it doesn't make any good neither.

What I want to say here is that a default value of 1 for 1^Inf is just of little (if any) usefulness, and this may be the reason the 71B doesn't provide it.
On the contrary, the default values 0^0=1 and Inf^0=1 may make things simpler in certain cases.

As Albert wrote, default values are for convenience only, they are not the Truth.

J-F
Edit: typos.