+dhe Posted May 13 Share Posted May 13 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? Quote Link to comment Share on other sites More sharing options...
Tursi Posted May 13 Share Posted May 13 (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 May 13 by Tursi 4 2 Quote Link to comment Share on other sites More sharing options...
Tursi Posted May 14 Share Posted May 14 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 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted May 14 Share Posted May 14 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? 🤪 1 Quote Link to comment Share on other sites More sharing options...
+dhe Posted May 14 Author Share Posted May 14 Thanks for taking the time @Tursi ! I've never really seen the top end of Radix 100 math discussed. 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted May 14 Share Posted May 14 (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 May 14 by Lee Stewart additional information 2 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted May 14 Share Posted May 14 4 hours ago, OLD CS1 said: What about compiled? 🤪 Left as an exercise for the reader. 2 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted May 15 Share Posted May 15 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 1 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted May 15 Share Posted May 15 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 ... 🫠 1 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted May 15 Share Posted May 15 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. 2 Quote Link to comment Share on other sites More sharing options...
Gary from OPA Posted May 15 Share Posted May 15 The CC40 uses Radix100 as well, infact the manuals for CC40 go into more detail than the 4a ones 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted May 15 Share Posted May 15 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 1 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted May 15 Share Posted May 15 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. 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted May 15 Share Posted May 15 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 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted May 15 Share Posted May 15 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 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted May 16 Share Posted May 16 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 1 Quote Link to comment Share on other sites More sharing options...
Gary from OPA Posted May 16 Share Posted May 16 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. 2 Quote Link to comment Share on other sites More sharing options...
apersson850 Posted May 16 Share Posted May 16 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... 2 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted May 16 Share Posted May 16 (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 May 16 by senior_falcon 2 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted May 16 Share Posted May 16 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. 😏 1 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted May 16 Share Posted May 16 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. 🤨 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted May 16 Share Posted May 16 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. 2 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted May 17 Share Posted May 17 (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 May 17 by sometimes99er 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted May 18 Share Posted May 18 Here BASIC has the speed advantage over XB: BASIC 1.49E-8 years Extended BASIC 1.88E-8 years 2 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted July 28 Share Posted July 28 On 5/14/2024 at 12:12 AM, Lee Stewart said: 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): Hide contents 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 I missed one mistake of Thierry’s in the above quoted post. I can no longer edit that post, so here are the spoiler contents with the correct “actual” value in the fourth floating point number: 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.020305050618 <---corrected value >00 >00 >xx >xx >xx >xx >xx >xx 0 (any exponent!) 0 (any x values!) ...lee 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.