one-point-nothing

10 replies to this topic

#1 jrhodesOFFLINE

jrhodes

Moonsweeper

• 286 posts

Posted Wed May 2, 2018 4:45 PM

I was playing around on the TI when i discovered that .99999999999999 prints as "1", while .999999999999999 prints as "1."

print .9 = ".9"
print .99 = ".99"
print .999 = ".999"
print .9999 = ".9999"
print .99999 = ".99999"
print .999999 = ".999999"
print .9999999 = ".9999999"
print .99999999 = ".99999999"
print .999999999 = ".999999999"
print .9999999999 = ".9999999999"

print .99999999999999 = "1"

print .999999999999999 = "1."

#2 Lee StewartOFFLINE

Lee Stewart

River Patroller

• 3,947 posts
• Location:Silver Run, Maryland

Posted Wed May 2, 2018 9:20 PM

I was playing around on the TI when i discovered that .99999999999999 prints as "1", while .999999999999999 prints as "1."

print .9 = ".9"
print .99 = ".99"
print .999 = ".999"
print .9999 = ".9999"
print .99999 = ".99999"
print .999999 = ".999999"
print .9999999 = ".9999999"
print .99999999 = ".99999999"
print .999999999 = ".999999999"
print .9999999999 = ".9999999999"

print .99999999999999 = "1"

print .999999999999999 = "1."

Actually, you have the last two backwards.  The one with fourteen 9s after the decimal point prints “1.” and the one with fifteen 9s prints “1”.

The reason for this has to do with how the TI handles floating point numbers.  They are represented as eight-byte, radix-100 (base-100 or centimal) numbers with the first byte having a sign bit followed by a 7-bit, excess-64 exponent capable of representing 100-64 – 100+63.  The remaining 7 bytes represent a normalized centimal significand, i.e., if the number is non-zero, it is adjusted until the first digit is a non-zero, unit’s-place digit (radix-100 scientific notation).  The largest such significand is 99 99 99 99 99 99 99 (separating the centimal digits (bytes) with spaces makes this clearer, I think), i.e., fourteen decimal 9s.  As soon as you enter a number that has more digits than can be exactly represented in 7 bytes, it is rounded.

Consequently, before printing, entering 0.99999999999999 is exactly represented internally as decimal 63 99 99 99 99 99 99 99 or hex 3F 63 63 63 63 63 63 63 (bytes are separated by spaces).  However, entering more digits than can be exactly represented causes rounding of the internal representation, with 0.999999999999999 becoming exactly 1 and represented internally as decimal 64 01 00 00 00 00 00 00 or hex 40 01 00 00 00 00 00 00.

The PRINT function will print only 10 digits.  It will round any number that contains more than 10 digits before printing and it will display a decimal point if the number had a non-zero fraction before rounding.  Any number that has no fractional part will be treated by PRINT as an integer and will not have a decimal point.  PRINT rounded the fraction with fourteen 9s.  PRINT saw the number entered with fifteen 9s in the fraction as the integer “1”, so did not add a decimal point.

...lee

#3 VorticonOFFLINE

Vorticon

River Patroller

• 3,619 posts
• Location:Eagan, MN, USA

Posted Thu May 3, 2018 6:24 AM

My eyes glazed over for a second but I got it   "  The remaining 7 bytes represent a normalized centimal significand, i.e., if the number is non-zero, it is adjusted until the first digit is a non-zero, unit’s-place digit (radix-100 scientific notation) "  ? Damn!

Bruce Harrison actually dedicated an entire column of his "Art of Assembly" series to the radix-100 representation on the TI and he really did a great job of explaining it to the uninitiated. The entire series as a matter of fact should be required reading for any budding assembly programmer! I believe it is available on the whtech ftp site.

#4 Lee StewartOFFLINE

Lee Stewart

River Patroller

• 3,947 posts
• Location:Silver Run, Maryland

Posted Thu May 3, 2018 7:46 AM

My eyes glazed over for a second but I got it   "  The remaining 7 bytes represent a normalized centimal significand, i.e., if the number is non-zero, it is adjusted until the first digit is a non-zero, unit’s-place digit (radix-100 scientific notation) "  ? Damn!

Bruce Harrison actually dedicated an entire column of his "Art of Assembly" series to the radix-100 representation on the TI and he really did a great job of explaining it to the uninitiated. The entire series as a matter of fact should be required reading for any budding assembly programmer! I believe it is available on the whtech ftp site.

Sorry about that!    Perhaps my full-page explanation in Appendix L of fbForth 2.0: A File-Based Cartridge Implementation of TI Forth is a little clearer.  It is, at the very least, more nearly complete:

I am not sure I have read that part of Art of Assembly.  I will check it out in a bit, if I can find it—his clever column titles often offer no insight into their contents and the lack of an index makes his very useful asides impossible to find.  Bruce did have a way with explaining difficult topics in his rambling, stream-of-consciousness sort of way.

...lee

#5 mizapfOFFLINE

mizapf

River Patroller

• 3,563 posts
• Location:Germany

Posted Thu May 3, 2018 7:52 AM

Radix-100 loses quite some precision for its length (8 byte), because the bytes in this 8-byte sequence only take the values 0 - 99 (instead of 0-255). However, unlike the standard IEEE754, many more numbers can be precisely represented.

Specifically, you cannot precisely represent the value 0.1 in IEEE754, neither can you represent 0.2, 0.3 (while 0.5 is precise again, as is 0.25). The reason is that 0.1 yields a periodic sequence of bits: dec 0.1 = bin 0.00011001100110011001... Wherever you clip the sequence, it is an approximation.

The Radix-100 format is different: Here, 0.1 = 10*100⁻1, so you have 0.(10) as the representation. When you add it 10 times, it yields 1, unlike the IEEE754 which will never precisely hit the 1.

I don't know whether TI used that format in their calculators as well. Although the format is painfully slow to compute, the advantage is that we humans can only write non-periodic numbers in the decimal system, so this Radix-100 will turn them automatically into precise representations as long as the number of digits is not too high.

#6 --- Ω ---OFFLINE

--- Ω ---

Hexacorerunner

• 13,805 posts

Posted Thu May 3, 2018 8:40 AM

Interesting little experiment there.

I thought I was looking at a government FOIA release for a second because of what looked like a redacted document.

If you change your theme or highlight the text it all becomes clear, unlike a government document.

#7 VorticonOFFLINE

Vorticon

River Patroller

• 3,619 posts
• Location:Eagan, MN, USA

Posted Thu May 3, 2018 9:11 AM

Lee's explanation needed to be censured so as not to create undue anxiety for the readers...

(Ok ok just some friendly ribbing 😁 Thankfully Lee is very thick-skinned 😊)

#8 mizapfOFFLINE

mizapf

River Patroller

• 3,563 posts
• Location:Germany

Posted Thu May 3, 2018 11:43 AM

This reminds me of a now famous quote of our former German Minister of the Interior at a press conference, when asked for details about a certain police and intelligence action (in connection with suspected terrorist activities), refused to answer and instead said that "details may be unsettling for the public".

#9 Lee StewartOFFLINE

Lee Stewart

River Patroller

• 3,947 posts
• Location:Silver Run, Maryland

Posted Thu May 3, 2018 12:02 PM

Lee's explanation needed to be censured so as not to create undue anxiety for the readers...

(Ok ok just some friendly ribbing Thankfully Lee is very thick-skinned )

Surely, you meant “censored”.

...lee

#10 matthew180OFFLINE

matthew180

River Patroller

• 2,621 posts
• Location:Castaic, California

Posted Thu May 3, 2018 12:26 PM

TI is a calculator company, so it is natural that their engineers will know about how to represent decimal numbers in a computer (unlike many software developers I have worked with).  So it makes sense that they would use a floating-point format that can correctly handle decimal numbers.  "Binary" floating point (the representation used by most modern CPUs), i.e. float and double types in most programming languages, cannot be used to accurately represent decimal numbers, i.e. like money or metric numbers.  People have died due to such mistakes, and there is a lot of financial software out there that makes me nervous.  Correctly handling money is one of the reasons languages like COBOL were used (and continue to be used) for big financial systems.  Anyway, I think it is cool that you can correctly write things like calculators and financial software on the 99/4A in BASIC.

#11 VorticonOFFLINE

Vorticon

River Patroller

• 3,619 posts
• Location:Eagan, MN, USA

Posted Thu May 3, 2018 4:14 PM

Surely, you meant “censored”.

...lee

Yup. That's my francophone background catching up with me...

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users