10E500?

[mpowell@rogershsa.com]

1. I've notice that the mantissa only goes up to 10E500. Is there a way to configure it to go any higher? like 10E999?

[Snorre]

Hello mpowell,

You cannot configure the Prime to go up to 1e+999.
The floating point number's exponent is three decimal digits wide, i.e. 1000 possible values: ranging from 1e-499 to nearly 1e+500.

Check out the constants MINREAL and MAXREAL (You'll find them also within the [Units] menu) and notice the differences in HOME (decimal floats) and CAS (binary floats).

[EDIT] Despite these limits are by far big enough for all physics, You're free to program some kind of big floats (handling mantissas and exponents separately) for Your special needs, e.g.
bigfac(n):=alog10(FP(sum(log10(k),k=1..n)))+"e"+IP(sum(log10(k),k=1..n))
to get the faculty up to 10001 (or even higher when summing by a program loop).

Greetings

[mpowell@rogershsa.com]

(12-08-2014 08:28 AM)Snorre Wrote:  Hello mpowell,

You cannot configure the Prime to go up to 1e+999.
The floating point number's exponent is three decimal digits wide, i.e. 1000 possible values: ranging from 1e-499 to nearly 1e+500.

Check out the constants MINREAL and MAXREAL (You'll find them also within the [Units] menu) and notice the differences in HOME (decimal floats) and CAS (binary floats).

[EDIT] Despite these limits are by far big enough for all physics, You're free to program some kind of big floats (handling mantissas and exponents separately) for Your special needs, e.g.
bigfac(n):=alog10(FP(sum(log10(k),k=1..n)))+"e"+IP(sum(log10(k),k=1..n))
to get the faculty up to 10001 (or even higher when summing by a program loop).

Greetings

Cool, thanks I'll try that.

[Gerald H]

On the HP 48G, 49G, 49G+ & 50G extended reals' exponent goes from -50,000 to 50,000.

[mpowell@rogershsa.com]

Hi. I tried it but got a syntax error.
   

[Snorre]

(12-09-2014 08:21 PM)mpowell@rogershsa.com Wrote:  Hi. I tried it but got a syntax error.

Hi,
it didn't work because it was just a CAS-function, not a program.
A program might look like

Code:

EXPORT BIGFAC(n)
BEGIN
  LOCAL s:=0,k;
  FOR k FROM 2 TO n DO s:=s+LOG(k); END;
  ALOG(FP(s))+"ᴇ"+IP(s);
END;

Note: this is meant just as an example how to deal with big floats for a particular problem (faculty in this case). It returns a string which cannot be used for further calculations.
You may program a big float math library by representing them as [mantissa, exponent] vectors and (re)defining some basic operators (+, -, *, /, !, ...). But that may not work very well for operators where mantissas and exponents cannot treated separately.
On the other side: such big numbers occur mostly in combinatorial problems which often require not more than a few basic operators.

[mpowell@rogershsa.com]

(12-10-2014 05:35 PM)Snorre Wrote:  

(12-09-2014 08:21 PM)mpowell@rogershsa.com Wrote:  Hi. I tried it but got a syntax error.

Hi,
it didn't work because it was just a CAS-function, not a program.
A program might look like

Code:

EXPORT BIGFAC(n)
BEGIN
  LOCAL s:=0,k;
  FOR k FROM 2 TO n DO s:=s+LOG(k); END;
  ALOG(FP(s))+"ᴇ"+IP(s);
END;

Note: this is meant just as an example how to deal with big floats for a particular problem (faculty in this case). It returns a string which cannot be used for further calculations.
You may program a big float math library by representing them as [mantissa, exponent] vectors and (re)defining some basic operators (+, -, *, /, !, ...). But that may not work very well for operators where mantissas and exponents cannot treated separately.
On the other side: such big numbers occur mostly in combinatorial problems which often require not more than a few basic operators.

Cool, thanks. Got it to work.

[cyrille de brébisson]

Hello,

Prime uses the math library which was first developed for the HP71 in the early 80's!
the HP71 had CPU registers of the form:
4 bit: s
12*4 bits: m
12 bits: x

for a total of 64 bits.
s was used for the sign (including special encoding for infinite)
m was a 12 digit BCD mantissa...
x was a BCD signed number for the exponent... due to the sign and BCD encodding, this limited the exponent to the -500/+499 range...
Why did they decide to use BCD and not binary (which would have provided exponents all the way to 2048, I do not know)...

The math algo were reused in Prime. the same limits were put in place, even as we now have 32 bits to store the exponent because, we do trust the library and the also as is, but we do not know/have no certainty that they would work well if the exponents were increased...

Sure, basic operations would have no problems. But things such as sin when x is very small (and x could get a whole lot smaller with larger exponents) might prove problematic....

The other issue is the CAS.
The CAS uses 64 bit IEEE floats. These are limited to an exponent +/-308! this difference between CAS and non CAS already causes issues for some users in placed. increasing the exponent would just exacerbate the problem.

So, here you go. sorry about that, but this does put a limit on what you can do with the calculator...

cyrille

[debrouxl]

BCD floats are much better than binary floats at avoiding rounding errors, the likes of e.g. 24 being printed as 23.999999999999 or so. The major FPU-less CPUs from the 80s, maybe from even earlier, have support for BCD arithmetic. Binary floats are faster, however.

Advanced Mathematics Software in the TI-68k series uses a custom 10-byte format for floating-point values:
* 1 bit for sign;
* 1 bit for exponent sign;
* 14 bits (binary) for exponent;
* 64 bits (BCD) for mantissa.
In principe, this allows usage of 16 digits and exponents up to -16384/+16383. However, only some low-level BCD arithmetics functions support that extended range; many higher-level functions use overflow to infinity for exponents outside the -999/+999 range, and round to 14 or 12 digits.

[lenborje]

(12-12-2014 07:07 AM)cyrille de brébisson Wrote:  Why did they decide to use BCD and not binary (which would have provided exponents all the way to 2048, I do not know)...

The HP Saturn CPU used in the old RPN calculators was designed for BCD operations. That way all cumbersome binary-decimal conversions was avoided, and decimal numerical accuracy maintained.

[cyrille de brébisson]

Hello

Quote:BCD floats are much better than binary floats at avoiding rounding errors

Actually untrue... They are just as bad as binary floating points in this respect...

BUT the rounding errors end up in different places which are much easier to understand for human being used to base 10.
For example, we can all understand that 1-3*1/3 = 1e-12 in bcd but we have a hard time understanding why 100-99.99-0.01 = 5e-15 in binary.


As other have stated before, the reason for the +/-499 limit on exponent comes from a long way away...

Althrough it would be in theory easy to change the limit to +/-2 billions, the problem is that not all the algorithms are designed to work with such values.
For example, trigonometric algorithms are absolutely not designed for it and would be relatively hard to modify to do so.

cyrille

Cyrille

[Paul Dale]

(01-28-2015 10:06 AM)cyrille de brébisson Wrote:  Actually untrue... They are just as bad as binary floating points in this respect...

If I had to commit either way, I'd say BCD was worse than binary for rounding.

They certainly round quite differently and the analysis is generally easier in binary.


- Pauli