The Museum of HP Calculators

HP Forum Archive 18

 Displaying numbers greater than 9.99E499?Message #1 Posted by Jean-Michel on 4 Jan 2008, 7:49 a.m. Hi all, I've heard about a puzzle (Eternity II) made of 256 square colored pieces, to be put into a square frame (16x16), by making the patterns figuring on the sides of the squares corresponding to each other, with only one solution (as for all the puzzles !) The one who would find this solution should win US \$ 2,000,000…but the probability seems very near to zero. Correct me if I'm wrong: There are : 256! (256 pieces) x 4^256 (each square piece can be put in 4 different positions) / 4 (the final solution can rotate in 4 different orientations, but remains one single) = 2,875 x 10^660 (!) solutions This is just a preamble and not the main subject of my post, which is the following : by considering those very great numbers, I was wondering why there is, in calculators like the HP-35s, a limit (i.e. 499) for the magnitude of the power of ten used to represent great numbers ? Why can’t the calculators handle numbers like 2,875 x 10^660, and why not, to go further, any magnitude of the power of ten, as soon as there are enough digits on the screen to represent the number (mantissa + E + power of ten) ? For instance, MS Excel maximum number is « only » 9.999…E307. Kind regards. Jean-Michel.

 Use LOG domain for calculations -> Big bangMessage #2 Posted by Allen on 4 Jan 2008, 8:15 a.m.,in response to message #1 by Jean-Michel I am not sure I follow your puzzle solution, nevertheless, numbers of that size (ABS(MANTISSA)>499) have very little meaning, especially when you can just do all of your calculations in LOG domain, and convert them back at the end. It will work in excel (except for the last LOG-> DEC conversion). Why not try that? I did this once at a conference where the presenter showed the audience a picture of a "1000 db Gain Antenna". ( clearly presenter error!!!) I became quite nervous, after a quick LOG calculation of the expansion of the universe from the time the universe was the size of an electron, until present day. (Using some estimates e.g. the average mass of a star, number of stars in a galaxy, number of galaxies, some extra DARK matter ingredients etc.... So with the assumptions made the BIG BANG was only about 850 db. That number could be displayed on my 48G or even a 10s, but the corresponding decimal number would be inaccessible. Edited: 4 Jan 2008, 8:23 a.m.

 Re: Use LOG domain for calculations -> Big bangMessage #3 Posted by Nick on 7 Jan 2008, 9:40 a.m.,in response to message #2 by Allen Allen, I must disagree completely on the "meaning" of any number "too large". After Peano and as long as induction is taken for correct, it is simply too easy to state that a number ceases to have a meaning after some given exponent, be it 499 or 2^499. It might have no physical correspondance to any big number in this universe, but after all: Mathematics is the science that you can still do when you wake up in the morning and find out that the universe is... gone! ;-) Nick

 Re: Use LOG domain for calculations -> Big bangMessage #4 Posted by Allen on 7 Jan 2008, 4:49 p.m.,in response to message #3 by Nick you're right, I should not say " meaningless", rather it has no practical use. ( e.g. the significant figures etc...)

 Re: Use LOG domain for calculations -> Big bangMessage #5 Posted by Mad Dog ebaycalcnut on 26 Jan 2008, 5:33 p.m.,in response to message #4 by Allen I disagree. There are practical uses to very large numbers, though not for everyday use.

 Re: Displaying numbers greater than 9.99E499?Message #6 Posted by Ken Shaw on 4 Jan 2008, 10:43 a.m.,in response to message #1 by Jean-Michel Assuming I understand your question, I think the simple answer is that the hardware inside a computer or calculator is basically a counter. It counts in units of 1 and has a fixed memory size for a single number (let's say N bits), which limits the range of countable numbers to 2^N. To include negative numbers, zero is placed in the middle of the range, so the actual range is approximately -2^(N-1) to 2^(N-1). What I think you are complaining about is that when the numbers are sufficiently large, why doesn't the machine simply shift the least significant digits out of range and work within a higher range of numbers? I think the answer is that only you can decide how much precision you need and what range of numbers you would like to work in. Simply make that decision and then make the adjustment yourself. You can work with numbers larger than 9.99E499 simply adjusting the problem before and after you use the machine. I think that's the same answer as "work within the log domain", but I thought it needed a bit more explaining.

 Re: Displaying numbers greater than 9.99E499?Message #7 Posted by Don Shepherd on 4 Jan 2008, 11:04 a.m.,in response to message #1 by Jean-Michel Jean-Michel, relating this to another thread, "programming programmable calculators," wouldn't it be great if one of us on this forum solved the Eternity II problem on an HP programmable! Not only would that clever individual win 2 million dollars, just think of the terrific publicity for HP that would surely result. Who knows, maybe HP would re-issue the 15c or 42s in celebration! Valentin, how about a "maxi" challenge here?

 Re: Displaying numbers greater than 9.99E499?Message #8 Posted by Karl Schneider on 4 Jan 2008, 1:37 p.m.,in response to message #1 by Jean-Michel Quote: I was wondering why there is, in calculators like the HP-35s, a limit (i.e. 499) for the magnitude of the power of ten used to represent great numbers ? Why can’t the calculators handle numbers like 2,875 x 10^660, Jean-Michel -- The basis of the HP-35s limit of exponents -- between -499 and +499 inclusive, with the number in scientific notation -- is the format of the binary-coded decimal (BCD) data word used by the late-1980's Pioneer-series units to represent numbers. (The HP-35s evolved from the HP-32SII.) The word is 64 bits, or 16 4-bit nibbles. Each digit of the 12-digit mantissa requires one nibble. The sign of the mantissa also uses one nibble. This leaves only three nibbles for the BCD 3-digit signed exponent. One way to store the exponent might be to add an offset of +500 that "centers" the range of 999 possible values. Thus, an exponent of 0 would be encoded as 500; +499 would be 999, and -499 would be 001. Another way -- which seems more likely, given James Prange's subsequent comments along with information presented in the reference article below -- would be to store the negative exponents using ten's complement by adding 1000. Thus, -1 would be encoded as 999, and -499 would be 501. Presumably, the unused code for the exponent could represent something else (1E+500?), and any extra bits of the mantissa sign might also be utilized for other purposes. 1E+500 is the result of an overflow. It can be displayed and used for calculations, but cannot be entered by the user. The above is what I believe to be true. If I'm mistaken, anyone should feel free to correct me. I can't specifically recall having seen a detailed specification of the Saturn-processor 64-bit word, but page 27 of the Hewlett-Packard Journal article from May 1983 about the HP-15C ("Scientific Calculator Extends Range of Built-in Functions") describes the 56-bit (14-nibble) word used by HP calc's having pre-Saturn microprocessors. This file (83MAY15.PDF) is found on the MoHPC CD/DVD set. The IEEE double-precision 64-bit floating-point word does provide more range and precision, because it's a more "efficient" format than BCD: -- KS (Edited to refine content, based on comments.) Edited: 14 Jan 2008, 2:42 a.m. after one or more responses were posted

 Re: Displaying numbers greater than 9.99E499?Message #9 Posted by Don Shepherd on 6 Jan 2008, 11:49 a.m.,in response to message #8 by Karl Schneider Quote: The word is 64 bits, or 16 4-bit nibbles. Each digit of the 12-digit mantissa requires one nibble. The sign of the mantissa also uses one nibble. The BCD 3-digit signed exponent uses the remaining three nibbles, stored with an offset of +500 that "centers" the range of 999 possible values, and also facilitates internal comparisons and calculations. Thus, an exponent of 0 is encoded as 500; +499 becomes 999, and -499 becomes 1. Karl, excellent explanation. I have seen many references to how BCD representation works in calculators, but none explained as clearly as yours.

 Re: Displaying numbers greater than 9.99E499?Message #10 Posted by Jean-Michel on 6 Jan 2008, 1:36 p.m.,in response to message #8 by Karl Schneider Guten Tag, Karl! Vielen Dank für deine Erklärung. (Thank your for your explanation, for non-German speaking people :) ). If I well understand, the only way to handle number greater than 9.999...E499 would be do decrease the number of significant digits of the mantissa, and to use the resultent free digits for the exponent. Fortunately, those numbers aren't used so often (at least that's what I think, correct me if I'm wrong).It's always possible to remove the powers of ten of the different numbers for the calculus and to compute the final power of ten separately. That's what I did to compute the numbers of combinations of the puzzle. Auf wiedersehen. Jean-Michel.

 Re: Displaying numbers greater than 9.99E499?Message #11 Posted by Karl Schneider on 6 Jan 2008, 8:02 p.m.,in response to message #10 by Jean-Michel Don and Jean-Michel -- Thanks for the kudos. Also please note some new information in my first post. -- KS

 Re: Numeric objects in RPL models Message #13 Posted by Karl Schneider on 8 Jan 2008, 10:46 p.m.,in response to message #12 by James M. Prange (Michigan) Paul Brogger said, Quote: I think it goes without saying: if we make a mistake on this board, we get corrected! ;-) That's the truth! I've been on both ends of that one... Thanks again, James, for yet another detailed and informative post. It's got me wondering whether I stated correctly the storage format of the exponents on non-RPL Saturn-processor calc's, as I wasn't using any definitive reference. I did convey the important point in that the maximum magnitude of the exponent is 499 instead of 999, so that the exponent can fit within three BCD nibbles. Here's something interesting: Craig Finseth's site states that the maximum magntitude of the internal extended-precision exponent of numbers in the Saturn-processor models is 49999 -- i.e., two extra nibbles for the exponent as well as three for the mantissa. Is that true? The site also states that the HP-15C's range of internal and external representations of numbers is the same, but that is incorrect. The HP-15C and others have three guard digits for the mantissa, but I'm not sure about the exponent. and click on your model of choice. Thanks! -- KS

 Re: Numeric objects in RPL models Message #14 Posted by James M. Prange (Michigan) on 12 Jan 2008, 6:56 p.m.,in response to message #13 by Karl Schneider Hi Karl, Quote: It's got me wondering whether I stated correctly the storage format of the exponents on non-RPL Saturn-processor calc's, as I wasn't using any definitive reference. I wondered the same, but I don't know. For what it's worth, even RPLMAN.DOC (the document describing RPL that HP released in 1991) didn't get it exactly right: Quote: ...and EEE the exponent in tens complement form (-500 < EEE < 500). Of course it's only the negative exponents that are in ten's complement form, very much like the usual convention for representing binary "signed integers" using the two's complement form for negative values. I did understand what was intended though, as using the ten's complement form for all values would seem rather pointless. Note that if the most significant nibble of the encoded number is 0-4, then it represents a non-negative value, and if it's 5-9, then it represents a negative value, so the most significant nibble of the exponent serves as both a numeric value and a sign nibble. Notably, 500 (encoded), which presumably would represent -500, isn't used. You made a good point that the mantissa sign nibble could've been used to hold more information. In particular, what's often come to my mind is that it could also have been used for the sign of the exponent as well, allowing the maximum magnitude of the exponent to be 999. Alternatively, they could've used a 13-nibble mantissa with negative values in the ten's complement form for a range of +/-4.999999999999. Oh well, I suppose that the developers had their reasons for their choices, and the current design seems to suffice for the intended uses of the calculators To verify that I had things right (and to check the new object types of the 49 series), I used the development library's \->H command. Given any argument on level 1, this command returns a character string of the hex nibbles of the object as stored in memory. The matching command, H\->, takes such a character string and returns the object, but has the hazard that it will happily try to build invalid objects, which may very well corrupt memory. Quote: I did convey the important point in that the maximum magnitude of the exponent is 499 instead of 999, so that the exponent can fit within three BCD nibbles. Yes, and that's indeed the most important point. The design that you described would work, including using the most significant nibble as both a numeric value and a sign nibble (except that 0-4 would represent a negative exponent, and 5-9 would represent a non-negative exponent). Perhaps the ten's complement form for negative exponents was chosen to simplify subtraction of them? Quote: Craig Finseth's site states that the maximum magntitude of the internal extended-precision exponent of numbers in the Saturn-processor models is 49999 -- i.e., two extra nibbles for the exponent as well as three for the mantissa. Is that true? Yes. Extending the range of the exponent makes sense because they're intended for internal use, and intermediate results used internally may well have exponents with a greater magnitude. As long as the magnitude of no intermediate results' exponents exceed 49999 and the magnitude of the final result's exponent doesn't exceed 499, the final result can be converted back to a normal user "real" number without overflow. For example, the extended real number -123456789012345E-49999 is stored in memory as 55920100055432109876543219. Breaking that down, 55920 is the prologue address, 10005 is the ten's complement of the negative exponent, 543210987654321 is the mantissa, and 9 is the (mantissa) sign, all in little-endian order. For the extended real numbers, the (mantissa) sign nibble and 15-nibble mantissa use one entire register, and the 5-nibble exponent uses the "address" field (so named because it's used for 5-nibble addresses) of another register. The Saturn Processor's 4 working registers (A-D) and 5 scratch registers (R0-R4) have (at least in the RPL models) fields as follows: ```| 15| 14| 13| 12| 11| 10| 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | ================================================================= | S |<----------------------M---------------------->|<----X---->| | XS|<--B-->| |<--------A-------->| |<------------------------------W------------------------------>| ?P? ?P<--------------WP------------->| ================================================================= S: Nibble 15: Sign (mantissa) M: Nibbles 14-3: Mantissa X: Nibbles 2-0: Exponent XS: Nibble 2: Exponent sign B: Nibbles 1-0: Byte A: Nibbles 4-0: Address W: Nibbles 15-0: Word (entire 64-bit register) P: Nibble selected by the P (Pointer) register WP: Nibble selected by the P register through nibble 0 ``` Most of the opcodes for these registers work on only a particular field, without using any other nibbles in the register. With the ARM-based models' emulated processor (Saturnator, also known as Saturn+) you can also use user-defined fields F1 through F7. I don't know much about these. Considering that they're defined using 64-bit masks, do these fields still have to end at nibble boundaries? Also, does a user-defined field have to be contiguous? In additional to the new opcodes for user-defined fields, the Saturnator adds many more new opcodes, but of course using a new opcode means that the routine won't be compatible with hardware Saturn models or the available PC-based emulators. Of course there are several other Saturn registers. Quoting from SASM.DOC: Quote: There are four working 64-bit registers, five scratch 64-bit registers, two 20-bit data pointer registers, one 4-bit pointer register, a 20-bit program counter register, a 16-bit input register, and a 12-bit output register. Return addresses are stored on an eight-level hardware return stack that accepts 20-bit addresses. In addition, there are 4 Hardware Status bits, a Carry bit, and 16 Program Status bits. The lower 12 Program Status bits can be manipulated as a 12-bit register. In assembly language programming, as long as you're careful, most of these resources can be used for things that the designers perhaps never intended. Regards,James

 BCD encoding of exponents and signsMessage #15 Posted by Karl Schneider on 13 Jan 2008, 2:06 a.m.,in response to message #14 by James M. Prange (Michigan) James -- Thank you for the informative reponse. I have only one comment: Quote: You made a good point that the mantissa sign nibble could've been used to hold more information. In particular, what's often come to my mind is that it could also have been used for the sign of the exponent as well, allowing the maximum magnitude of the exponent to be 999. According to "Scientific Calculator Extends Range of Built-in Functions", in Hewlett-Packard Journal, May 1983: Page 28: The value of a negative-sign nibble for the mantissa and for the exponent is encoded as 1001 (+9) on the HP-15C (and likely on all pre-Saturn models, I would assume). Page 27: The two-digit BCD exponent is given by XX if the exponent sign equals 0 (positive value), and by -(100-XX) if the exponent sign equals +9 (negative value). So, the encoded exponent is also complemented on pre-Saturn models. Page 27: However, the value of the "mantissa sign" nibble of a matrix descriptor is 0001. I'm not quite sure what was the reason for the +9 encoded value of a negative sign -- perhaps enhanced reliability of data offered by lack of adjacency (two-bit difference between 0000 and 1001). Another possibile use is to determine whether the sum of encoded exponents represented an overflow condition, as the two-nibble exponents were not uniquely coded. Regards, -- KS Edited: 13 Jan 2008, 2:38 a.m.

 Re: BCD encoding of exponents and signsMessage #16 Posted by Giancarlo (Italy) on 14 Jan 2008, 2:25 a.m.,in response to message #15 by Karl Schneider Hi Karl and James. Far from being able to contribute to the thread, I just would like to express my deep appreciation for this kind of discussion, which allows myself (and many others too) to learn a lot of things. Thank you for your valuable and knowledgeable contributions. Best regards. Giancarlo

 Re: BCD encoding of exponents and signsMessage #17 Posted by karl Schneider on 16 Jan 2008, 2:19 a.m.,in response to message #16 by Giancarlo (Italy) Hi, Giancarlo -- Thanks for the kind words. I have to admit that James did most of the work; I just answered the OP's basic question and dug up some references... -- KS

 Re: BCD encoding of exponents and signsMessage #18 Posted by Eric Smith on 16 Jan 2008, 3:48 p.m.,in response to message #15 by Karl Schneider The reason for the 9 for both mantissa and exponent sign dates back to the HP-35. The processor used in the Classic series could only do BCD arithmetic, and had no bit (logical) operations, which meant that a full digit had to be used for a sign. Packing would have required a lot of instructions, and the entire firmware for the 35 had to fit in 768 words of ROM. (An amazing feat!) For the mantissa sign, if 0 is positive, the most obvious choices for negative would be 1 or 9, since those can be obtained from 0 by an increment or decrement. However, it is even more efficient on the Classic processor to use a C=0-C-1 instruction when necessary to change the sign. That wouldn't work if negative was represented using 1. Using 9 for negative also has advantages in distinguishing overflow and underflow conditions. The exponent, with a range of -99 to +99, is stored as a three digit ten's complement number, from 901 to 099. By doing this, the addition and subtraction of exponents can be done using simple three-digit BCD addition and subtraction, with no special care for dealing with positive or negative exponents other than on entry and display. This also potentially allows internal intermediate results to have a greater exponent range, as long as the final result is in the -99 to +99 range. While the earlier calculators could have used the three-digit exponent field for a larger range for the user, it would have needed more code, which was not justified on the 35 and other early calculators. By the time of the 41C, they could have expanded the exponent range if they'd felt there was a compelling need, but instead they kept the math routines almost unchanged from the 30 series, and used them again with minimal changes in the Voyagers. The 71B was the first product to use the Saturn processor, and the math routines saw a major update to support the IEEE 854 standard for radix-independent floating point. They chose to expand the exponent range at that point, presumably because the engineering effort was relatively small compared to the overall scope of the updates to the math routines.

 Re: BCD encoding of exponents and signsMessage #19 Posted by Karl Schneider on 17 Jan 2008, 2:17 a.m.,in response to message #18 by Eric Smith Thanks, Eric -- that's some real historical insight! Of course, in addition to math modifications, display space would have required expansion to provide three-digit exponents for the HP-41. -- KS Edited: 17 Jan 2008, 2:23 a.m.

 Re: Displaying numbers greater than 9.99E499?Message #20 Posted by Paul Brogger on 8 Jan 2008, 4:39 p.m.,in response to message #8 by Karl Schneider Quote: If I'm mistaken, anyone should feel free to correct me. I think it goes without saying: if we make a mistake on this board, we get corrected! ;-)

Go back to the main exhibit hall