HP50g - internal vs displayed precision ?
DDS
I don't understand why certain numbers (e.g. the value of pi) are
displayed with 12 decimal place accuracy, yet other numbers (e.g. 12^53)
are displayed with several dozen digits.
Is there a method of getting internal values displayed to greater
resolution? I'm interested in solving problems where certain non-integer
numbers, raised to their self power (e.g. 3.1415 ^ 3.1415) are solved
such that the result in an integer.
I presume the calculator is limited to a certin number of digits of
precision and the=at the floating-point "lives" somewhere within that
range. I don't really understand floating point terminology so please
feel free to correct and educate!
Thanks
DDS
Virgil
> Hello
>
> I don't understand why certain numbers (e.g. the value of pi) are
> displayed with 12 decimal place accuracy, yet other numbers (e.g. 12^53)
> are displayed with several dozen digits.
There are two types of numbers, decimals (floating points numbers) with
a limit of displayed precision of 12 significant digits, and exact which
appear as integers or fractions of potentially considerably greater
precision.
>
> Is there a method of getting internal values displayed to greater
> resolution? I'm interested in solving problems where certain non-integer
> numbers, raised to their self power (e.g. 3.1415 ^ 3.1415) are solved
> such that the result in an integer.
As far as I know, expressions involving numbers in floating point format
can only simplify to decimals with that same 12 significant digit
accuracy..
However
'3.1415 ^ 3.1415' XQ
produces
'(6283/2000)^(6283/2000)'
which then EVALUATEs to something you might find of interest.
But be aware that '3.14159265359' XQ will produce the symbol for pi.
>
> I presume the calculator is limited to a certin number of digits of
> precision and the=at the floating-point "lives" somewhere within that
> range. I don't really understand floating point terminology so please
> feel free to correct and educate!
>
> Thanks
>
> DDS
--
Nemo
> Hello
>
> I don't understand why certain numbers (e.g. the value of pi) are
> displayed with 12 decimal place accuracy, yet other numbers (e.g. 12^53)
> are displayed with several dozen digits.
>
> Is there a method of getting internal values displayed to greater
> resolution? I'm interested in solving problems where certain non-integer
> numbers, raised to their self power (e.g. 3.1415 ^ 3.1415) are solved
> such that the result in an integer.
>
>
> DDS
Hi
As Virgin wrote, the HP50 can work with integers ( limited only by the
memory of your HP) or decimals (real number) (from -9.99999999999E499
to 9.999999999999E499). (Note that there are also binary number wich
begin with a # char but it s another story)
For the HP, all numbers without fractionnal mark are considered as
integers. For exemple 15678 1 0 etc.
All others are decimals (real)
For example 100 ! gives the all 158 digits of the result
100. ! returns 1.85327186949E280
Note that if in a calculation there is one real the result will be
real: 12. 1 + give 13. (and not 13). You can force this with the R-
>I ou I->R commands
13. R->I give 13
13 I->R give 13.
Virgil wrote : "But be aware that '3.14159265359' XQ will produce the
symbol for pi. "
But you can use ->Q instead if you don't want any 'pi' in the result
3.14159265359 ->Q give 1146408 / 364913
The ->Q precision command depends of the FIX argument
For exemple, if you are in FIX 2 (2 decimals)
3.14159265359 ->Q give 22/7
Nemo
> On 13 juil, 00:20, DDS <D...@home.com> wrote:
>
Oupss
For example 100 ! gives the all 158 digits of the result
100. ! returns 9.33262154439E157 of course !
Dave Hayden
> Hello
>
> I don't understand why certain numbers (e.g. the value of pi) are
> displayed with 12 decimal place accuracy, yet other numbers (e.g. 12^53)
> are displayed with several dozen digits.
First, some terminology. In a number like "8.23 E67" 8.23 is called
the "mantissa"
and 67 is called the "exponent."
Building on what Nemo wrote, the calculator stores real numbers in a
format
that maps directly to the way they are displayed. In other words, all
real numbers
store:
- 12 digits of mantissa
- the 3 digit exponent (e.g. the "52" in 1.234 E52)
- the sign (+ or -) of the number
- the sign of the exponent.
The exponent and its sign are a little more complicated but you get
the idea.
Note that it always stores 12 digits of mantissa and 3 digits of
exponent,
even if it doesn't display them:
This is stored like this
1.23456789012 E100 1.23456789012 E 100
1.23 1.23000000000 E 0
342. 3.42000000000 E 2
0.00456 4.56000000000 E-3
Dave
John H Meyers
"floating point" values actually come in two flavors:
Normal precision (12 mantissa digits, 3 exponent digits)
Extended precision (15 mantissa digits, 5 exponent digits)
The latter are generally used internally,
via "SysRPL" functions,
to arrive at accurate "normal precision" results
of standard commands available to users (UserRPL commands).
I seem to recall that there may also be some sort of external library
which may handle any precision of "floats," but the above is,
I believe, all that is available in pre-loaded ROM from HP.
[r->] [OFF]
DDS
firstly, thanks for the clear explanation - thanks to the other posters
replies too (Virgil, Nemo, John). I am of course constantly outshone in
this NG! Which is a positive thing - I can't fail to learn.
My original question was
>> I don't understand why certain numbers (e.g. the value of pi) are
>> displayed with 12 decimal place accuracy, yet other numbers (e.g. 12^53)
>> are displayed with several dozen digits.
And the storage methodology is explained as
> ...all real numbers store:
> - 12 digits of mantissa
> - the 3 digit exponent
> Note that it always stores 12 digits of mantissa and 3 digits of
> exponent, even if it doesn't display them:
> This is stored like this
> 1.23456789012 E100 1.23456789012 E 100
> 1.23 1.23000000000 E 0
I can understand what's said but I can't understand why the mantissa in
a sum such as 12^53 can be displayed by the machine as a 56 digit number:
1572555712320371480831006735579195460947411969842738102272
or alternatively (and sensibly!) as 1.57256x10^57
In the "long" case we've got 58 mantissa digits and an undisplayed
exponent of 0 and in the second case we've got something that fits into
the limited number format of 1.57256000000 x 10^00 with the unneeded
zeroes suppressed from the display).
oliverue
Further to Nemo's explanation, integers are "arbitrary precision":
there's no fixed limit; only memory constrains the internal
representation. These are a data type, often called "BigInteger",
distinct from floats.
You can have fractions involving BigIntegers, and you could write code
that specifies Pi at an arbitrary precision, as a rational number.
Though you can do some math with such an assembly, you cannot convert
it into a decimal representation, or use functions that expect reals,
without converting it back down into a 12-bit mantissa float.
If you need that, or want to work with arbitrary-precision irrational
numbers, you'll need a "BigFloat" data type, for which you will have
to look elsewhere, I'm afraid. (That is, I'm not aware of a BigFloat
library for HP-50g.)
Virgil
> Hello Dave
>
> firstly, thanks for the clear explanation - thanks to the other posters
> replies too (Virgil, Nemo, John). I am of course constantly outshone in
> this NG! Which is a positive thing - I can't fail to learn.
>
> My original question was
> >> I don't understand why certain numbers (e.g. the value of pi) are
> >> displayed with 12 decimal place accuracy, yet other numbers (e.g. 12^53)
> >> are displayed with several dozen digits.
>
> And the storage methodology is explained as
> > ...all real numbers store:
> > - 12 digits of mantissa
> > - the 3 digit exponent
>
> > Note that it always stores 12 digits of mantissa and 3 digits of
> > exponent, even if it doesn't display them:
>
> > This is stored like this
> > 1.23456789012 E100 1.23456789012 E 100
> > 1.23 1.23000000000 E 0
>
> I can understand what's said but I can't understand why the mantissa in
> a sum such as 12^53 can be displayed by the machine as a 56 digit number:
>
> 1572555712320371480831006735579195460947411969842738102272
>
> or alternatively (and sensibly!) as 1.57256x10^57
In the top line there is either an R (for real ) or a C (for complex).
Immediately following it there will be either an equal sign (for exact
mode) or a tilde (for approximate mode) which will determine part of how
the HP50 will deal with input and evaluations. When in approximate mode,
there are also a wide variety of formatting choices, which are a whole
other problem.
If your HP50 is set to exact mode and you enter '12^53' without any
decimal points, then in evaluation the result will be exact, so long as
there is time and sufficient memory, but if you are in approximate mode,
entry of '12^53' will display as '12.^53.', or with some zeros following
the decimal point if you are in certain display formats and will
evaluate to display in scientific notation.
>
> In the "long" case we've got 58 mantissa digits and an undisplayed
> exponent of 0 and in the second case we've got something that fits into
> the limited number format of 1.57256000000 x 10^00 with the unneeded
> zeroes suppressed from the display).
NOte: to switch between exact mode and approximate mode, hold down the
right shift key and press the ENTER key. You should see at the very top
of the screen a switch between an equal sign and a tilde character.
--
Virgil
<c6193bea-2f09-4766...@q5g2000yqj.googlegroups.com>,
oliverue <oliv...@hotmail.com> wrote:
Go to http://www.hpcalc.org and search for longfloat.
There are at least 3 libraries there devoted to extended accuracy on the
49 and 50.
--
John H Meyers
> I can understand what's said but I can't understand why the mantissa in
> a sum such as 12^53 can be displayed by the machine as a 56 digit number:
>
> 1572555712320371480831006735579195460947411969842738102272
>
> or alternatively (and sensibly!) as 1.57256x10^57
>
> In the "long" case we've got 58 mantissa digits and an undisplayed
> exponent of 0 and in the second case we've got something that fits into
> the limited number format of 1.57256000000 x 10^00 with the unneeded
> zeroes suppressed from the display).
The 56-digit number is _not_ a "floating point" object;
it's an "integer" object, and all that an integer object can contain
is _all_ the digits of an _integer_ -- it is never an approximation,
but _must_ be the _exact_ value of the integer, not omitting
any digit whatsoever, which is the very reason why "integers"
have to get very long when their value is very large.
Integer objects can not represent any value having a
"fractional" part, nor any value (other than exactly zero)
of absolute value less than 1, but they can represent
the absolutely _exact_ value of as huge an integer
as free memory in the calculator can hold,
which is something that no "long float" can boast of.
The words "mantissa" and "exponent"
are used basically to describe systems in which
a huge range of exponentially scaled numeric values
can be represented _approximately_ rather than exactly,
in a small (generally constant) amount of memory per value,
by both limiting the number of significant digits and
carrying a separate exponent (of ten, in these calculators,
but of two or sixteen, etc., in other well-defined,
more "binary-oriented" environments).
That must be why the numeric modes of the calculator
are called "exact" (in which most calculations
disallow the use of any numeric type but integers),
vs. "approximate," in which all _numeric results_
are always expressed solely in "floating point" form,
a/k/a "real" or "complex" in these calculators,
and all integer _input_ values are even first converted
to "real" before applying "approximate" arithmetic to them.
If one tries to supply any non-integer numeric input
to any operation performed in "exact" mode,
the usual action is to either perform that particular operation
in "approximate" mode only, or to abort because of invalid input
(as the CAS sometimes may do, though it's not very consistent
in following this policy).
So why, we might ask, is there a separate, "exact" calculating
universe, rather than doing all calculation in "approximate" mode,
as number-crunching engineers (and you) think of
as the only "sensible" way to do things?
Well, it's not just for possible use in cryptography,
whose basis nowadays has a lot to do with large-integer operations,
but it's actually for its great importance to the
_symbolic_ operations of a Computer Algebra System (CAS),
which is the major advance that sets these calculators apart
from previous editions of mere "electronic slide rules"
for engineers, which was the actual marketing phrase applied
to HP's first "shirt pocket sized" calculator (HP-35) ca. 1980,
"The Powerful Pocketful" as it was called in the "HP Journal."
Even though there was some symbolic capability built into
the earlier HP48S/G series of calculators, which had no
special "exact integer object" type, it was limited
by the very fact that only relatively "small" numeric
quantities could be represented exactly, and most fractions,
in particular, could not be so represented.
For example, the "cube root of minus 8," if written
in "approximate" fashion as '(-8.)^.333333333333'
would result in the "complex number" (1.,1.73205080757)
which is very different from the real (and exact) number -2
You have seen someone in this thread casually say
that "fractions" can be represented in "exact" mode,
but that needs a little deeper look -- what they mean by
"fractions" is actually in the form of _algebraic expressions_
whose components are solely exact integer objects and math operators,
e.g. '2+1/3' or '7/3' Etc.
Many aspects of the CAS depend upon representing all symbolic
expressions as algebraic objects containing no other numeric parts
than _exact_ integer objects, and that's why, when you try to invoke
many CAS commands at any time that the calculator is set to
"approximate" mode, you will be asked to either let the CAS
switch to approximate mode, or else abort the operation.
The CAS will also demand to switch to RADian angle mode
for many operations, and in fact there are so many modes
which it wants to set a certain way that a special command
CASCFG is provided to set all modes at once that the CAS cares about.
What can you do if you currently have an algebraic expression to
work with that contains some "real" values, that the CAS won't like,
for example, what about '(-8.)^.333333333333' that we mentioned above?
Why, there's a very special (and powerful) command (XQ)
provided for just this purpose, which magically transforms
the above to '(-8)^(1/3)' in which form the CAS can proceed to act.
XQ can be applied to any algebraic expression at all,
and will convert all "approximate" numeric values in that expression,
however deeply buried, to what we referred to above as "fractions"
(or "rational" expressions), also leaving the calculator in "exact" mode,
with nothing but "exact" input to handle, ready for any CAS activity to follow.
Is the "wonder land" of the two vastly different numeric modes
(approximate vs. exact) of the HP49/50 series now beginning
to converge at all toward a more complete and comprehensive
perspective of coexistence, and perhaps even make some sense?
"Take care of the sense, and the sounds will take care of themselves"
https://www.cs.indiana.edu/metastuff/wonder/ch9.html
--
"Co-existence or no existence" -- Piet Hein
http://www.piethein.com/usr/piethein/HomepagUK.nsf
"Throughout the Napoleonic wars, while the landowners of England
continually increased their rent-rolls, the mass of the wage-earning population
sank into greater and greater destitution. It was only afterward,
during the long peace, that a less unjust distribution began to be possible.
It cannot be doubted that the desire on the part of the rich
to distract men's minds from the claims of social justice
has been more or less unconsciously one of the motives leading to war.
Everywhere the well-to-do,
and the political parties which represent their interests,
have been the chief agents in stirring up international hatred
and in persuading the working man that his real enemy is the foreigner.
Thus war, and the fear of war,
has a double effect in retarding social progress:
it diminishes the resources available
for improving the condition of the wage-earning classes,
and it distracts men's minds from the need and possibility
of general improvement, by persuading them that the way
to better themselves is to injure their comrades in some other country.
Of all the evils of war the greatest, in my opinion,
is the purely spiritual evil: the hatred, the injustice,
the repudiation of truth, the artificial conflict,
where, if once the blindness of atavistic instincts
and the sinister influence of anti-social interests, such as
those of armaments with their subservient press, could be overcome,
it would be seen that there is a real consonance of interest
and essential identity of human nature,
and every reason to replace hatred by love.
Mr. Norman Angell has well shown how unreal,
as applied to the conflicts of civilized States,
is the whole vocabulary of international conflict,
how illusory are the gains supposed to be obtained by victory,
and how fallacious are the injuries to which nations, in times of peace,
are supposed to inflict upon each other in economic competition.
The importance of this thesis lies,
not so much in its direct economic application,
as in the hope which it affords for the liberation
of better spiritual impulses in the relations of different communities.
To love our enemies, however desirable, is not easy;
and therefore it is well to realize
that the enmity springs only from blindness,
not from any inexorable physical necessity."
-- Bertrand Russell
http://www.voiceseducation.org/content/betrand-russell-coexistence-or-no-existence
"Operation Warrior Wellness NYC Launch Event"
http://www.youtube.com/watch?v=YBTFoXRJywQ
http://www.youtube.com/user/DavidLynchFoundation
http://dlf.tv/
DDS
> Further to Nemo's explanation, integers are "arbitrary precision":
> numbers, you'll need a "BigFloat" data type, for which you will have
> to look elsewhere, I'm afraid. (That is, I'm not aware of a BigFloat
> library for HP-50g.)
Prompted by Virgil's post (see later in the thread):
DDS
> The 56-digit number is _not_ a "floating point" object;
[...]
> Is the "wonder land" of the two vastly different numeric modes
[...]
perspective of coexistence, and perhaps even make some sense?
What a thorough answer!
Now that will take some reading and absorbing but to answer your
question, yes it is making some sense. Thankyou for taking the time to
explain in such detail. I'll do it justice by trying to grasp it all;
which is not a 5 minute task.
DDS
John H Meyers
> Many aspects of the CAS depend upon representing all symbolic
> expressions as algebraic objects containing no other numeric parts
> than _exact_ integer objects, and that's why, when you try to invoke
> many CAS commands at any time that the calculator is set to
> "approximate" mode, you will be asked to either let the CAS
> switch to approximate[?] mode, or else abort the operation.
Oops -- "to let the CAS switch to _Exact_ mode"
My language is obviously only approximate,
even if my original thoughts were exact :)
"If I'm not pure, at least my jewels are"
<http://www.stlyrics.com/lyrics/candide/glitterandbegay.htm>
With Leonard Bernstein's complex score,
originally sung in 1956 by the perfect Barbara Cook,
who is still actively performing,
and here in 2004 by another perfect performer:
http://www.youtube.com/watch?v=U5liuHR6wug [lyrics included]
(stealing the applause at the start is Patti Lupone)
http://en.wikipedia.org/wiki/Barbara_Cook
http://en.wikipedia.org/wiki/Kristin_Chenoweth
http://www.youtube.com/watch?v=K3hSW0EsBzU#t=520s [Barbara Cook 1956]
(the above also has extensive notes and other songs)
http://www.youtube.com/watch?v=dZf6oQeqSww [Barbara Cook 200?]
http://www.youtube.com/watch?v=oCIdCk-Sq2o [Barbara Cook 200?]
<http://en.wikipedia.org/wiki/Candide_(operetta)>
http://www.amazon.com/gp/product/B0000996FW/ [Cook & Co. 1956, click #6]
http://www.amazon.com/dp/B0007WFXZI [Chenoweth & Co. 2004]
http://www.playbillstore.com/cabylebedvd.html
That was amazingly thorough, wasn't it? ;-)
-[ ]-
Nicola Bressanin
50g...the last is really powerful.
Found a minor bug,tough:
(with 512 digits,std rounding)
2 FSQRT
3 FSQRT
FMULT
FSQ
6 R<->F
FSUB
(now appears "700....000" instead of "nnn...nnnE-nn")
R<->F
0 is shown on the stack