# HP Forums

Full Version: 50g - Exponent of zero
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I just realized the XPON of zero returns "Infinite result".

What would be the mathematical justification for this? I would expect either 0 by convention (since after all a normalized 0 is stored with 0 for exponent), or perhaps "Undefined", since 0*10^N is true for all N (not just for N=Infinity).
It seems to me returning 0 is perhaps more reasonable?
0 has no normalized exponential form of type a.b*10^c with at least one digit before the fraction mark.
Arno
(09-27-2017 05:28 PM)Arno K Wrote: [ -> ]0 has no normalized exponential form of type a.b*10^c with at least one digit before the fraction mark.
Arno

So shouldn't it be "Undefined" instead of "Infinite result"?

Maybe I shouldn't have used the "normalized" word, "standarized" is more appropriate.
Zero is typically represented with 0 mantissa and 0 exponent, so it would make sense for XPON to return 0.
For continuity of the function perhaps -Inf makes sense, but then XPON is limited to the actual floating point format that's being stored, in the HP50g XPON would jump from -499 to -Inf anyway, there's no continuity so why bother with returning "Infinite result".
FWIW, the HP-71B gives you some control over what happens when EXPONENT(0) is executed, by setting the DVZ (DiVision by Zero) trap to 0 (bomb out with an error messasge), 1 (return the default value), or 2 (return the IEEE-suggested value):

TRAP(DVZ,0) @ EXPONENT(0) --> <beep!> ERR:EXPONENT(0)
TRAP(DVZ,1) @ EXPONENT(0) --> <beep!> WRN:EXPONENT(0) --> -9.99999999999E499
TRAP(DVZ,2) @ EXPONENT(0) --> <beep!> WRN:EXPONENT(0) --> -Inf

ERR messages persist in the display until you clear them. WRN messages only flash momentarily (duration is user-settable with the DELAY command).

EXPONENT(0) is such a special case that the HP-71 even assigns a unique error number for it (ERRN=3), which the manual explains as "Indicates attempt to compute the exponent of a zero argument. Sets DVZ (division-by-zero) flag (-7)."
Ok, the prime returns undefined, the 50g -9.99...E499, undefined clearly would be better. As I am German I can only refer to some web pages concerning normalized versus standarized, Wikipedia for example:" 2,99792458 · 10^8 m/s. Nur die Mantisse der letzten Darstellung ist auf den Wertebereich [1,10[ normalisiert". Other pages use both as synonyms:see here
Arno
Question.
. By XPON, are we talking about using zero as an exponent, as in x^y, where y is the exponent and x<>0 ... or, are we talking E\EEX, as in x*10^y? Or are we talking about something entirely different?

Mathematically, the answer should be 1 in the first case, and x in the second? Soooo, I must be missing something? Does XPON mean something completely different? Now then... it is 2:30 in the morning here, so maybe I'm having a brain fart and just really need to get some sleep?? Interesting note: On my 32sii, 15c, 41cv, and two different Casios... 0^0 correctly gives an error. However, on my 48sx, 48gx, and according to a 42 emulator, 0^0 incorrectly returns an answer of 1.
(09-28-2017 09:37 AM)BarryT Wrote: [ -> ]are we talking E\EEX, as in x*10^y

We are talking about y.
Arno
(09-28-2017 09:37 AM)BarryT Wrote: [ -> ]Interesting note: On my 32sii, 15c, 41cv, and two different Casios... 0^0 correctly gives an error. However, on my 48sx, 48gx, and according to a 42 emulator, 0^0 incorrectly returns an answer of 1.

We've already been here several times in the past... :-)
This is just the first I can pick up googling around.
(09-28-2017 11:26 AM)Massimo Gnerucci Wrote: [ -> ]
(09-28-2017 09:37 AM)BarryT Wrote: [ -> ]Interesting note: On my 32sii, 15c, 41cv, and two different Casios... 0^0 correctly gives an error. However, on my 48sx, 48gx, and according to a 42 emulator, 0^0 incorrectly returns an answer of 1.

We've already been here several times in the past... :-)
This is just the first I can pick up googling around.

But this thread has nothing to do with 0^0, let's stay on topic since 0^0 was debated a million times, this one seems a lot less frequent.
This is about any number being represented by s*M*10^X, with 1<M<10 (using 2 instead of 10 in both expressions if binary floating point) and X being the exponent we are taking about (s=sign).
The C standard library frexp() and all its incarnations in different languages return M=0 and X2=0 for frexp(0), simply because that's what's stored when you store 0 as a real number (IEEE). Notice I used X2 since this is a binary exponent, s*M*2^X.
For those not using a 50g, XPON is the command that returns X for s*M*10^X The 50g returns Inifinite result (-Inf), while other calculators give other results.

Now 0 = 0*10^X so we could all agree that M=0, but that wouldn't meet the constraint of 1<M<10. If we are strict with the definition of the mantissa and force M to be 1<M<10, then:

0 = M*10^(-Inf)

And the 50g would be correct, however, 0 MANT does return 0 on the 50g. A more correct way would be:
If MANT(0)=0, then XPON(0)=Undefined, and since any value is a solution, then 0 is not a bad answer.
If MANT(0)=Undefined, then XPON(0)=-Inf

From a practical point of view, in this thread the solution would be much easier of XPON just returned 0 instead of an error.
Please note... not trying to flame anyone, nor cause a raucous... just curious It would be interesting to hear\understand what folks think about... the EXACT answer. Meaning, lets completely forget about taking the "limit of..." anything, as well, completely forget about what happens as things are "...approaching said value from the left or right...". Lets focus on THE answer, at THE EXACT value in question.

While it's mathematically relevant as well as interesting to see what values are getting approached, it's still not THE point in question. If absolutely every number in the real or complex planes, for example, will satisfy an equation... then that's pretty much an undefineable answer, or, an infinite result answer.

For this particular question, who cares what an equation or a graph "approaches" as it comes upon the 0 value... if you enter "0" in for the value, and you're not asking for a limit approach or approximation, but instead say "Hey there little calculator... tell me what the EXACT value is for '42/0', '42^0', etc...", I completely expect the calculator to tell me what the answer is at that exact point. I don't want it to tell me what someone feels like defining it as, nor do I want it to tell me what it's "approaching", if I wanted to know what it was approaching, I'd have specifically asked that. But that's not what was asked... so, I want to know what THE answer is... exactly at ZERO. If that's not defined, or, infinite, that's a perfectly acceptable answer... but don't just give me some arbitrarily decided bogus value that's not THE actual value.
Now then, on more advanced calculators it might be nice if they would program in something that says "undefined, but the equation is 'approaching' X".

Again... definitely not trying to start wars... I'm just one of those types of people who expects if someone or something is asked a question, the actual answer, ( or handful of answers in the case of multiple, but finite, roots or something ), is given, and not something that's "kinda sorta" the answer.
Feel free to beat me over the head if you like, just do so gently please. Hmm.. This interesting discussion again, what is zero. I have not any academic degree to say what is the "right" way.

However. In my eng. brains always says to me that 0=+-inf^-1 and n^0 = 1 and 1/0 = inf WolframAlpha seems to agree (although giving 'wrong' answer for 1/0 as complex infinity, while the "right (my interpretation)" should be 1/1/inf = (1/1)*(inf/1) = inf), so does 50g to some degree.  OK. Is there even a consensus on these, between mathematicians.
We seem to have lot of discussions about the same sort of stuff these days. I don't know where the misguided assumption that you can say something like:

"Hey there little calculator... tell me what the EXACT value is for '42/0', '42^0', etc...", I completely expect the calculator to tell me what the answer is at that exact point.

(and expect an umbiguous answer) comes from, but totally misguided it is. At least from a mathematical point of view.
Perhaps I should expand, at the risk of boring everybody again.

When you build the number systems and arithmetic from the ground up, you define everything very precisely. But as you expand your context (I like that word), previously defined concepts or results may become undefined (e.g. ordering when going from real to complex numbers), or vice versa (e.g. extending/compactifying the real or complex numbers).

While I don't think that there is a context in which 42^0 is anything but 1, 42/0 is a perfectly valid infinity in the extended complex plane but not on the real line or the (two point) extended real line.

To bad for the suggestion that you do not want to consider limits, because in many cases that is just how things (including the numbers themselves) are defined. Or at least that's one standard way of defining for example the real numbers (it's actually a bit more complicated than that). And even when a definition does not necessarily require you to use limits, limiting behaviour is very relevant to the question of whether a certain definition makes sense and will be useful. If you want to, you can build your own mathematical world around the definition that 42/0 = 7, but good luck getting any value out of such a system.
(09-29-2017 01:24 AM)Mike (Stgt) Wrote: [ -> ]This said, the result XPON(0) = inf looks very reasonable for me, it has nothing to do with the internal representation of 0 and its exponent in your HP-50G.

Ciao.....Mike

But it does have to do with the internal representation, since XPON returns exactly the exponent stored on every real number (except zero as it happens on the 50g).
Also, your argument uses continuous functions. Let's not forget that XPON is not continuous, but discrete, as it only exists for the numbers representable by the machine. It exists for 0.999999999999 and 1.0 but is undefined in between.
If we choose to ignore this granularity and treat it like continuous, then the approach to 0 with an error e:
limit XPON(0+e) = -499 because e would be the smallest number representable
limit XPON(0-e)=-499 as well

So why -Inf? If both limits coincide then this is an avoidable discontinuity and its value should be -499 (now I'm confused...)

Actually, somebody might make the argument that XPON's domain excludes the whole range:
-1e-499<x<+1e-499

So it's not only undefined at 0, it is undefined for every real number that is not representable by the machine in that range. In that case you can't even take a limit when it approaches zero, because the function only exists in isolated "dots", is discrete.

But if this is the case, then XPON is mostly a practical function to retrieve the stored exponent, since it's defined only for machine representable numbers. In that case why not define it with a 0 for x=0. After all, 0 is a special number because its mantissa cannot be represented by 1<M<10, therefore why not make a special definition for a special number?

From this practical point of view, -Inf sounds just as made up as 0, because it's a theoretical number obtained from limits, but the actual function XPON is not defined in the vicinity of zero, so how do you determine that the result is -Inf? It seems Undefined would be more appropriate.
(09-29-2017 12:24 PM)Mike (Stgt) Wrote: [ -> ]I do not know much about the HP-50G's internas. If the internal representation of real numbers is something mantissa&exponent then for a mantissa of 0 the exponent is void/irrelevant/meaningless and to put it to zero is a programmer's free choice. This 'ad libitum' should not affect the result of XPON(0).

Ciao.....Mike

The more I think about it, the more I agree with the answer of the HP-71 as Joe mentioned. The true result should be an error "You attempted to compute the XPON of zero, what in the world do you think you can achieve by that?".

That's the best answer to XPON(0).
Reference URL's
• HP Forums: http://www.hpmuseum.org/forum/index.php
• :