max float

[+dhe]

if in basic you did something like,

   10 x=x+1

   20 print x

   30 goto 10

 

Question 1: What is the max of x?

Question 2: What happens when it hits the max (overflow error, flip back to zero)?

Question 3: Is there enough time in a life time for it to hit max float of x?

 

 

[Tursi]

Per the XB manual, the maximum value is 9.9999999999999E127. This is well over a googol (in fact I think that's an octillion more than a googol.)

(EDIT: I had an error in my program...)

It looks like the result is a NUMERIC OVERFLOW warning, but you might not be able to get there with '1'. This program prints the first three successfully, and throws the warning on the last one (then prints 9.99999E+** anyway).

 

10 A=9.9999999999999E127
20 PRINT A
30 A=A+1
40 PRINT A
50 A=A-1
60 PRINT A
70 A=A+A
80 PRINT A

 

As for time... well... no. Not even on a modern PC. On a TI in XB, figure 10 A=A+1::GOTO 10 can add about 150 per second in my test. This would take over 2000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 years to reach the maximum, if no rounding errors occurred. (Should be 90 zeros on there...)

 

It's not even worth trying a PC test... let's just assume the best case that a 3GHz machine can manage 3 billion additions per second (since it's one value being incremented, we'll discard multi-threading). This would take only a little over  100000000000000000000000000000000000000000000000000000000000000000000000000000000000 years.

Edited May 13 by Tursi

[Tursi]

I did some more testing cause I was curious. The internal resolution of the number, in the XB manual, is "13 or 14 digits". In this case, I used this program:

 

10 A=9.9999999999999E127
20 A=A+1E113 :: GOTO 20

 

This program will never overflow, because 1E113 is too small a number to actually increment A anymore. Change it to 1E114 and it will suddenly overflow.

 

[+OLD CS1]

14 minutes ago, Tursi said:

It's not even worth trying a PC test... let's just assume the best case that a 3GHz machine can manage 3 billion additions per second (since it's one value being incremented, we'll discard multi-threading). This would take only a little over  100000000000000000000000000000000000000000000000000000000000000000000000000000000000 years.

What about compiled? 🤪

[+dhe]

Thanks for taking the time @Tursi !

 

 I've never really seen the top end of Radix 100 math discussed.

[+Lee Stewart]

3 hours ago, dhe said:

 I've never really seen the top end of Radix 100 math discussed.

 

Well...There is the fbForth 2.0 Manual, Appendix L. “Notes on Radix-100 Notation” (referenced here) and Chapter 7, “The Floating Point Support Package”.

 

As @Tursi said, the XB Manual discusses it. Also, the User’s Reference Guide discusses it in various places, but in some detail in §3.10.2. “Technical Information on Number Representation”. There is a typesetting error in the last reference: 12710 should be 127₁₀.

 

The E/A Manual discusses radix-100 notation on page 279, but has the highest radix-100 exponent as 64, which is wrong!—it is 63. Also, exponent representation is only half right and could be explained better.  The manual says,

If the exponent is positive, the byte value is 64 more than the exponent. If the exponent is negative, the byte value is obtained by subtracting the exponent from 64.

 

It should have said,

The exponent is stored in the lower 7 bits (0..127) of the most significant byte in excess-64 format, i.e., 64 is added to the exponent before storing and subtracted from the stored value to retrieve it. The lowest exponent is 0 – 64 = -64 and the highest is 127 – 64 = 63.

 

Though Thierry Nouspikel talks about radix-100 math and notation, he does not go into minimum/maximum numbers, at least not on the referenced page. But, I should mention the errors in notation in the examples on that page (see spoiler):

Spoiler

Exponent  Mantissa                      Value               Actual Value     
--------  ---------------------------   -----------------   ------------------
>40       >01 >02 >03 >04 >05 >06 >07    1.020304050607        <correct>
>41       >01 >02 >03 >04 >05 >06 >0B   10.20304050611      102.0304050611
>3F       >05 >00 >00 >00 >00 >00 >00    0.5                  0.05
>BF(-41)  >FF >02 >03 >05 >05 >06 >12  -10.20304050618       -1.020304050618
>00       >00 >xx >xx >xx >xx >xx >xx    0 (any exponent!)    0 (any x values!)

 

 

...lee

 

Edited May 14 by Lee Stewart
additional information

[Tursi]

4 hours ago, OLD CS1 said:

What about compiled? 🤪

Left as an exercise for the reader.

 

[sometimes99er]

On 5/14/2024 at 1:10 AM, dhe said:

if in basic you did something like,

   10 x=x+1

   20 print x

   30 goto 10

 

Question 1: What is the max of x?

Question 2: What happens when it hits the max (overflow error, flip back to zero)?

Question 3: Is there enough time in a life time for it to hit max float of x?

If you startup in TI Basic or XB, the variable x will initialize with the value of zero.
At a certain point, because of the Radix 100 floating point precision, adding one will not add one, the variable cease to advance, it will stall, - as somewhat demonstrated by these two programs. And long before 9.9999999999999E127.
 

100 y=9.9999999999999E13
110 x=y
120 x=x+1
130 if x<>y then 120

 

100 y=9.99999999999999E13
110 x=y
120 x=x+1
130 if x<>y then 120

 

[sometimes99er]

On 5/14/2024 at 2:03 AM, OLD CS1 said:

What about compiled? 🤪

Well, you then move out of Radix 100 floating point, so yes, that's something rather different ... 🫠

[+FarmerPotato]

I like that the 4A has radix-100.  
 

Since IEEE-754 (and the 8087 chip) everyone uses base 2. Before that  IBM used base 16 and so did Texas Instruments.  (TI put this in their FORTRAN and the 99110.) 

 

The good thing about Radix 100 is that it represents base 10 fractions exactly. 0.1 is exact. Any factor of 10 is exact. 
 

In IEEE-754 the number 8.2 is not exact.  IEEE-754 is better for calculating formulas, but a bit worse for money and human expectations where Radix 100 is nicer. 
 

Neither one keeps track of significant digits by default. It's always 15.79 (log10 of 2^57)(EDIT:WRONG) decimal digits in IEEE-754 double (8 bytes.) Radix 100 (8 bytes) wobbles between 13 and 14.

 

In IEEE-754 floating point, the number 8.2 falls between two possible exact numbers , both of which satisfy the C language standard.

One of them often prints as 8.1999999999999999, a common oversight in printf("%.16f"). It's sad. 

 

Wobble 

 

Radix 16 suffers from "wobble". For example, with 4 byte single precision, when you add F.1234567 and 1.000000 you get 1.0123457 e+1.  Whenever the decimal point shifts left, you must round off the 4 least significant bits.
 

(Intermediate calculations use extra precision and round for the digit that would be dropped.) 

 

Radix-100 has more wobble because the least significant 8 bits or 2 decimal digits must be rounded.

 

The decimal exponent goes left 2 places in:

50.142857142857 * 2  = 1.002857142857 E+2. 

The two least significant decimal  digits of the product (14) fall off.

 

If you divide by 2 again you get:

 

50.142857142850 
 

 

There's BCD, which uses 4 bits per decimal digit instead of counting 0-99 within a byte. BCD was suited to 4-bit processors in calculators, but was still facilitated by the 16-bit  TMS9940's DCA and DCS instructions. And most mainframes. Nuff about that. 

 

 

[Gary from OPA]

The CC40 uses Radix100 as well, infact the manuals for CC40 go into more detail than the 4a ones

[+Lee Stewart]

57 minutes ago, FarmerPotato said:

Radix 16 suffers from "wobble". For example, with 4 byte single precision, when you add F.1234567 and 1.000000 you get 1.0123457 e+1.  Whenever the decimal point shifts left, you must round off the 4 least significant bits.

 

<pedantry>

That would be “hexadecimal point”.

</pedantry>

 

...lee

[+FarmerPotato]

50 minutes ago, Lee Stewart said:

 

<pedantry>

That would be “hexadecimal point”.

</pedantry>

 

...lee

You are correct.  I didn't have a word for it. 
 

Looking: a general term is Radix Point. 
 

Probably I made other errors talking about floating point errors. 

[senior_falcon]

On 5/13/2024 at 7:48 PM, Tursi said:

Per the XB manual, the maximum value is 9.9999999999999E127. This is well over a googol (in fact I think that's an octillion more than a googol.)

(EDIT: I had an error in my program...)

It looks like the result is a NUMERIC OVERFLOW warning, but you might not be able to get there with '1'. This program prints the first three successfully, and throws the warning on the last one (then prints 9.99999E+** anyway).

 

10 A=9.9999999999999E127
20 PRINT A
30 A=A+1
40 PRINT A
50 A=A-1
60 PRINT A
70 A=A+A
80 PRINT A

 

As for time... well... no. Not even on a modern PC. On a TI in XB, figure 10 A=A+1::GOTO 10 can add about 150 per second in my test. This would take over 2000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 years to reach the maximum, if no rounding errors occurred. (Should be 90 zeros on there...)

 

It's not even worth trying a PC test... let's just assume the best case that a 3GHz machine can manage 3 billion additions per second (since it's one value being incremented, we'll discard multi-threading). This would take only a little over  100000000000000000000000000000000000000000000000000000000000000000000000000000000000 years.

So it looks like you can get up to 99999999999999 before adding 1 has no effect. I didn't time it, but let's say the TI can add 1 and print 10x per second. (I didn't time this) At that rate it would take only 317,098 years to get there. There is hope, but be sure to have a good battery backup. I'd hate to see you get to 300,000 years and have the power go out.

[+OLD CS1]

9 hours ago, senior_falcon said:

There is hope, but be sure to have a good battery backup. I'd hate to see you get to 300,000 years and have the power go out.

And pay attention to your local hyperspace council for any un-fortuitous demolition which might be planned to occur right before the solution is found, as happened with the Answer to the Ultimate Question.

[sometimes99er]

Do not run. Take a guess. How many years would this program run ?
 

100 x=1
110 x=x+x
120 if x<>x+1 then 110

 

[Gary from OPA]

10 minutes ago, sometimes99er said:

Do not run. Take a guess. How many years would this program run ?
 

100 x=1
110 x=x+x
120 if x<>x+1 then 110

 

Would be a lot quicker as it is doubling each time. 1,2,4,8,16,32,64,128,256,512,1024 so I would say about a minute or two at most.

[apersson850]

The p-system implements a data type called long integer. It's integer values with more digits than you can fit into 16 bits. I've seen financial programs written for the p-system which uses these for monetary values. If you do your math with cents (öre in Sweden), then you don't drop any digits even for large amounts. The max number of decimal digits the data type supports is 36.

 

So now you can start estimating how long it will take before incrementing such a value causes a roll-over...

[senior_falcon]

6 hours ago, sometimes99er said:

Do not run. Take a guess. How many years would this program run ?
 

100 x=1
110 x=x+x
120 if x<>x+1 then 110

 

I punched a few numbers into the calculator on my phone. With what I found there, and Tursi's estimate at the beginning of the thread, I would guess that it would take about 1/10000000 or 1E-7 years

(edit) I misinterpreted line 120 in the program, so my answer is quite a bit off. If you make line 120 GOTO 110 then my answer is pretty close.

Edited May 16 by senior_falcon

[sometimes99er]

40 minutes ago, senior_falcon said:

I punched a few numbers into the calculator on my phone. With what I found there, and Tursi's estimate at the beginning of the thread, I would guess that it would take about 1/10000000 or 1E-7 years

(edit) I misinterpreted line 120 in the program, so my answer is quite a bit off. If you make line 120 GOTO 110 then my answer is pretty close.

Well, it actually only runs for a few seconds. 😏

[sometimes99er]

44 minutes ago, senior_falcon said:

I punched a few numbers into the calculator on my phone. With what I found there, and Tursi's estimate at the beginning of the thread, I would guess that it would take about 1/10000000 or 1E-7 years

(edit) I misinterpreted line 120 in the program, so my answer is quite a bit off. If you make line 120 GOTO 110 then my answer is pretty close.

With your change, it seems to run forever. However, after a few seconds a warning saying "number too big in 110" continues to emerge. 🤨

[senior_falcon]

1 hour ago, sometimes99er said:

With your change, it seems to run forever. However, after a few seconds a warning saying "number too big in 110" continues to emerge. 🤨

You are right, it does not stop. With ON WARNING STOP then it halts when the number is too big.

As you wrote the program it would take an estimated 1E-8 years.

[sometimes99er]

18 hours ago, senior_falcon said:

As you wrote the program it would take an estimated 1E-8 years.

Yep, somewhere between 1E-7 and 1E-8 years, - or perhaps simply 0 years. 😉

Edited May 17 by sometimes99er

[senior_falcon]

Here BASIC has the speed advantage over XB:

BASIC                 1.49E-8 years

Extended BASIC   1.88E-8 years