HP71 Scale10() function

[KeithB]

The hyperbolic thread made me drag out my HP71 Math Pac manual and I saw an entry for the Scale10() function.
What good is it?
Has anyone used it?
Was it ever used on any other calculators?

I note that they did not even bother to put in an example for it!

[Joe Horn]

(09-12-2022 06:55 PM)KeithB Wrote:  What good is it?

The manual (page 29) says, "You will find SCALE10 useful in preventing intermediate underflows and overflows in long chain calculations." This is because it directly modifies the number's exponent by addition or subtraction, rather than performing ordinary multiplication or division on the entire number. I suspect that it's also faster than ordinary multiplication and division, which could be useful in long-running programs, but I haven't tested that.

[Stefan_Titan2944A]

I suppose (former) users of slide rulers will understand this function immediately.
The intermediate results are scaled.

I guess, it's mostly targeted at engineers to simply adjust the unit range

mA > µA - SCALE10(X, 3)

V > mV - SCALE10(X, 3)

g > kg - SCALE10(X, -3)

nF > pF - SCALE10(X, 3)

MHz > kHz - SCALE10(X, 3)

MHz > Hz - SCALE10(X, 6)


Over-/underflow on a HP calculator shall not be an issue, though.
Unless, you DO try to solve inter-galactic spacetime ( 4- dimensional ) problems on a Planck-Length scale.

Modern calculators just rot our mind - use FIX 3

[Valentin Albillo]

.
Hi, KeithB,

(09-12-2022 06:55 PM)KeithB Wrote:  The hyperbolic thread made me drag out my HP71 Math Pac manual and I saw an entry for the Scale10() function. What good is it? Has anyone used it? Was it ever used on any other calculators?
I note that they did not even bother to put in an example for it!

It's a mostly useless function, IMHO. I guess they put it as a keyword because it already was in the ROM as an internal routine, so making it user-accessible was just a matter of providing a keyword for it and simply calling the internal routine, as in the case of the REV$ string function, which was absent from the mainframe's instruction set but implementing it in a LEX file required just assigning a keyword to it and directly calling the internal routine already present in the System ROMs without further ado. Perhaps the implementation of IEEE math did require having the SCALE10 function exposed to the user for full compliance.

I only used it a very few times (perhaps twice or thrice) and mostly to check its suitability for very specific one-of-a-kind purposes, but as the usual suspects at HP decided to burden it with so long a keyword (7 characters !), it was problematic to include several instances within a single math expression, where it would be most useful, without overflowing the length of the line. They did the same with the Math ROM's INTEGRAL keyword, which J-F Garnier shortened in his new revamped Math ROM.

Also, it seems that accessing a function in the Math ROM does carry some overhead in execution time, so I found it slower than its obvious equivalent ( SCALE10(X,N) -> X*10^N ), if I recall correctly, so in the end I considered it useless and even aesthetically unappealing in listings and discarded using it for good.

V.

[Albert Chan]

SCALE10(X,N) is safer than X*10^N, avoiding intermediates overflow/underflow

>SCALE10(1.2E345, -678)
 1.2E-333
>SCALE10(1.2E-345, 678)
 1.2E333

Is there an "inverse" for SCALE10, to split number to mantissa/exponent?

[Valentin Albillo]

(09-13-2022 11:25 AM)Albert Chan Wrote:  SCALE10(X,N) is safer than X*10^N, avoiding intermediates overflow/underflow

>SCALE10(1.2E345, -678)
 1.2E-333
>SCALE10(1.2E-345, 678)
 1.2E333

Nice to know.

Quote:Is there an "inverse" for SCALE10, to split number to mantissa/exponent?

Theres's EXPONENT(x), which returns the exponent of the normalized equivalent of x.

V.

[Stefan_Titan2944A]

HP71B MATH ROM was widely appreciated as a state-of-the art extension to
"missing" root functionality - maybe, just try to live and deal with it!

Sure, there always have been HP Management / Sales interferences
and questionable decisions, which functions to add - maybe even how the name them.

It's great to know, that modern enthusiasts are capable to improve the
HP SW dev team misalignments and misconceptions.

[J-F Garnier]

(09-13-2022 11:25 AM)Albert Chan Wrote:  Is there an "inverse" for SCALE10, to split number to mantissa/exponent?

No, there isn't, and this is one of the rare use of SCALE10 I found:
IF X THEN E=EXPONENT(X) ELSE E=0 ! exponent
M=SCALE10(X,-E) ! mantissa

Valentin is right, a form of scaling is internally used inside the Math ROM, especially in the matrix LU decomposition that involves a lot a multiplication/division.
I guess the goal of the SCALE10 was to provide this functionality at user code level for advanced algorithms.

Probably this is the same reason as for the NEIGHTBOR(X,N) function that gives the predecessor or successor of a number X (differing by +/- 1ULP°), a function internally used by the HP Solver (called FNROOT in the HP-71 Math ROM) to locate a root down to the last place.

For me, the most mysterious HP-71 Math ROM keyword is the complex PROJ(Z) function, no clear idea of its function and use. Has it ever been used?

J-F

° ULP = Unit in the Last Place

[Valentin Albillo]

.
Hi, Jean-François,

(09-13-2022 11:52 AM)J-F Garnier Wrote:  For me, the most mysterious HP-71 Math ROM keyword is the complex PROJ(Z) function, no clear idea of its function and use. Has it ever been used?

Never used it, not even once. I think it's there only for full compliance with the IEEE standard, and SCALE10 might fit that bill as well.

Best regards.
V.

[KeithB]

Thanks everyone, I think the most practical use is for eng scaling from A to mA, for example.

I am not complaining about the Math Pac in general, I think it is amazing how it extends the usage of the HP71 seamlessly. Complex numbers alone are worth the purchase price.

I know C++ was still in the future, are there any other computer languages/systems that allowed for operator overloading?

[Stefan_Titan2944A]

ALGOL 68, FORTRAN

(F#, SWIFT, R)

[KeithB]

When was operator overloading added to Fortran? Daniel McCracken never mentioned it in his books. 8^) I suspect it was Fortran 90, *after* the HP71.