IGNORED

# max float

## Recommended Posts

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?

##### Share on other sites

Posted (edited)

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 by Tursi
• 4
• 1
##### Share on other sites

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.

• 5
• 1
##### Share on other sites

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.

##### Share on other sites

Thanks for taking the time @Tursi !

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

##### Share on other sites

Posted (edited)
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 12710.

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 by Lee Stewart
• 1
• 1
##### Share on other sites

4 hours ago, OLD CS1 said:

Left as an exercise for the reader.

##### Share on other sites

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```

##### Share on other sites

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

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

##### Share on other sites

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.

##### Share on other sites

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

##### Share on other sites

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>

</pedantry>

...lee

##### Share on other sites

50 minutes ago, Lee Stewart said:

<pedantry>

</pedantry>

...lee

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

Looking: a general term is Radix Point.

##### Share on other sites

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.

• 1
• 4
##### Share on other sites

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.

• 2
• 1
##### Share on other sites

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```

##### Share on other sites

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.

##### Share on other sites

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...

##### Share on other sites

Posted (edited)
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 by senior_falcon
##### Share on other sites

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. 😏

##### Share on other sites

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. 🤨

##### Share on other sites

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.

##### Share on other sites

Posted (edited)
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 by sometimes99er
##### Share on other sites

Here BASIC has the speed advantage over XB:

BASIC                 1.49E-8 years

Extended BASIC   1.88E-8 years

• 1
• 1

## Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

×   Pasted as rich text.   Paste as plain text instead

Only 75 emoji are allowed.