▼
Posts: 191
Threads: 41
Joined: Jun 2007
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 HP35s, 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.
JeanMichel.
▼
Posts: 562
Threads: 27
Joined: Oct 2006
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.
▼
Posts: 64
Threads: 17
Joined: Dec 2007
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
▼
Posts: 562
Threads: 27
Joined: Oct 2006
you're right, I should not say " meaningless", rather it has no practical use. ( e.g. the significant figures etc...)
▼
Posts: 124
Threads: 17
Joined: Dec 2006
I disagree. There are practical uses to very large numbers, though not for everyday use.
Posts: 149
Threads: 7
Joined: Dec 2006
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^(N1) to 2^(N1).
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.
Posts: 1,392
Threads: 142
Joined: Jun 2007
JeanMichel, 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 reissue the 15c or 42s in celebration!
Valentin, how about a "maxi" challenge here?
Posts: 1,792
Threads: 62
Joined: Jan 2005
Quote:
I was wondering why there is, in calculators like the HP35s, 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,
JeanMichel 
The basis of the HP35s limit of exponents  between 499 and +499 inclusive, with the number in scientific notation  is the format of the binarycoded decimal (BCD) data word used by the late1980's Pioneerseries units to represent numbers. (The HP35s evolved from the HP32SII.)
The word is 64 bits, or 16 4bit nibbles. Each digit of the 12digit mantissa requires one nibble. The sign of the mantissa also uses one nibble. This leaves only three nibbles for the BCD 3digit 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 Saturnprocessor 64bit word, but page 27 of the HewlettPackard Journal article from May 1983 about the HP15C ("Scientific Calculator Extends Range of Builtin Functions") describes the 56bit (14nibble) word used by HP calc's having preSaturn microprocessors. This file (83MAY15.PDF) is found on the MoHPC CD/DVD set.
The IEEE doubleprecision 64bit floatingpoint word does provide more range and precision, because it's a more "efficient" format than BCD:
http://en.wikipedia.org/wiki/IEEE_754
 KS
(Edited to refine content, based on comments.)
Edited: 14 Jan 2008, 2:42 a.m. after one or more responses were posted
▼
Posts: 1,392
Threads: 142
Joined: Jun 2007
Quote:
The word is 64 bits, or 16 4bit nibbles. Each digit of the 12digit mantissa requires one nibble. The sign of the mantissa also uses one nibble. The BCD 3digit 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.
Posts: 191
Threads: 41
Joined: Jun 2007
Guten Tag, Karl!
Vielen Dank für deine Erklärung. (Thank your for your explanation, for nonGerman 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.
JeanMichel.
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
Don and JeanMichel 
Thanks for the kudos. Also please note some new information in my first post.
 KS
Posts: 1,041
Threads: 15
Joined: Jan 2005
For the RPL models, which use the Saturn processor or an emulated
"Saturn+" processor, each object starts with its prologue address
(a 5nibble address pointer to its "prologue", the ROM code that
executes that type of object), followed by the "body" of the
object.
Note that some objects are built into ROM, in which case they may
be represented by 5nibble pointers to the objects in ROM.
Everything is stored in memory in littleendian order
(leastsignificant nibble first), but when loaded into one of the
processor's registers (or a field of a register), the lowest
nibble from memory ends up as the least significant nibble in the
register or field (bigendian order). Similarly, when a register
or field is copied to memory, its leastsignificant nibble is
stored at the starting address.
For a "real" number object, the prologue address is 02933, and the
body is 16 BCD nibbles and fits perfectly into one of the Saturn
processor's 64bit working or scratch registers. Let's represent
this object as 33920EEEMMMMMMMMMMMMS.
The first three nibbles of the body represent the exponent from
499 through 499, with negative exponents in the ten's complement
form. For example, 1 is represented in ten's complement form as
999, and 499 as 501. But remember that it's stored in
littleendian order, so 499 is actually stored in memory as 105.
The next twelve nibbles are the mantissa, with an implied decimal
point between the 1st and 2nd digits, with the first nibble
nonzero for nonzero numbers, again in littleendian order
The last nibble is used for the sign, with 0 representing
nonnegative and 9 representing negative.
But when loaded into the processor's register, the nibbles of the
body are loaded in reverse order, so it becomes SMMMMMMMMMMMMEEE,
that is, first the sign, then the mantissa, and finally the
exponent, with the mantissa and exponent in bigendian order.
Some examples:

1.23456789012E499 is stored as 339209942109876543210 (breaking
this down, 33920 is the prologue address, 994 is the exponent,
210987654321 is the mantissa, and 0 is the sign nibble, all in
littleendian order), and the body is loaded into a register as
0123456789012499 (breaking this down, 0 is the sign nibble,
123456789012 is the mantissa, and 499 is the exponent, all in
bigendian order).

1.23456789012E499 is stored as 339209942109876543219, and the
body is loaded into a register as 9123456789012499.

1.23456789012E499 is stored as 339201052109876543210, and the
body is loaded into a register as 0123456789012501.

1.23456789012E499 is stored as 339201052109876543219, and the
body is loaded into a register as 9123456789012501.
Note that the real numbers 9 through 9 are compiled as ROM object
pointers. When loaded into a register, the body of the object
pointed to is loaded.
For a complex number object, the prologue address is 02977, and
the body consists of the bodies of two "real" numbers, with the
real part first, followed by the imaginary part.
For an extended real number object (SysRPL only), the prologue
address is 02955, and the body is 21 BCD nibbles, starting with
5 nibbles representing the exponent from 49999 through 49999
(again with negative exponents in ten's complement form), followed
by a 15nibble mantissa, followed by the sign nibble, 0 for
nonnegative or 9 for negative. In the processor, the mantissa and
sign nibble use one entire working or scratch register, and the
exponent uses the "address" field of another.
For an extended complex number object (SysRPL only), the prologue
address is 0299D, followed by the bodies of two extended real
numbers.
For a "hex string" object (used for user binary integers), the
prologue address is 02A4E, and the body starts with a 5nibble
selfinclusive length field (in hexadecimal), followed by the
nibbles of the hexadecimal number. User binary integers are always
stored as 16nibble (64bit) integers, so always have a "length"
of 00015 hex (21 decimal) (excluding the prologue address, of
course). Although you can (in SysRPL) have hex strings with values
longer than 16 nibbles, the available RPL arithmetic commands for
hex strings use no more than the leastsignificant 64 bits
(respecting the current wordsize), and it's up to the programmer
to deal with this, presumably using hex "substrings" with values
of no more than 16 nibbles each to fit into the processor's
registers.
For a system binary integer object (bint) (SysRPL only), the
prologue address is 02911, and the body consists of a 5nibble
hexadecimal number.
In the 49 series, we can have an "exact integer" (zint), which has
a prologue address of 02614, and the body starts with a 5nibble
selfinclusive length field (as always, in hexadecimal), followed
by the BCD nibbles of the integer, followed by a sign nibble, 0
for nonnegative or 9 for negative. The zint 0 is the exception,
being stored as 41620600000, which I suppose we could say has the
BCD integer nibble 0 with a missing sign nibble, or else as having
no BCD integer nibble, with a nonnegative sign; in any case, it's
the only zint with a length of 00006.
Note that the zints 9 through 9 are compiled as ROM object
pointers.
An array object (used for a real or complex vector or matrix in
UserRPL, and not to be confused with the 49 series' "symbolic
matrix") has a prologue address of 029E8, and the body starts with
a selfinclusive length field (number of nibbles in the entire
body), followed by a 5nibble prologue address indicating which
type its elements are (all must be the same type), followed by a
5nibble dimension count field, followed, for each dimension, by a
5nibble dimension size field, and finally followed by the object
bodies of its elements, in order. All elements must be present.
For arrays compiled from UserRPL source code, the element type
will always be "real number" or "complex number", and the
dimension count will always be 1 for a "vector" or 2 for a
"matrix"; note that the UserRPL commands for arrays are intended
for these kinds of arrays only; experiment with trying them with
other kinds of arrays at your own risk.
A linked array (SysRPL only) has a prologue address of 02A0A, and
the body starts with a selfinclusive length (number of nibbles in
the entire body), followed by a prologue address indicating which
type its elements are (all must be the same type), followed by a
5nibble dimension count field, followed, for each dimension, by a
5nibble dimension size field, followed by a pointer table,
followed by the elements (object bodies). The pointer table
consists of selfreferencing 5nibble forward offsets to the
actual elements. All pointers must be present, and each must
either point to a valid element or have the value of 00000. A
pointer value of 00000 indicates a missing element at that
position in the array. The elements (object bodies) themselves may
be in any order. Note that more than one pointer may point to the
same element. As far as I know, there are very few supported
SysRPL commands for dealing with linked arrays. Linked arrays of
character strings are used for some of the builtin message
tables, but I don't know whether linked arrays are used anywhere
else in ROM. You could, for example, make an identity matrix with
a 5nibble pointer for each element, but using only two actual
elements, the 16nibble object bodies for the real numbers 0 and
1.
All of the above are "atomic" objects; that is, they can't contain
any proper "objects", complete with their own prologue addresses.
In the 49 series, we can also have a "symbolic matrix", which is a
"composite" object, similar to a list, or a list of samesized
"sublists". Each element is a complete object in itself (or an
object pointer). The elements can be real numbers, complex
numbers, zints, or algebraic objects (or pointers to objects of
these types), or any combination of these, and all elements must
be present. The prologue address is 02686, and the object body
ends with an object pointer to the primitive code object (pco)
SEMI, at 0312B. A 1dimensional symbolic matrix object starts with
the prologue address, followed by the element objects (or object
pointers), followed by the object pointer to SEMI. A 2dimensional
symbolic matrix object starts with the prologue address, followed
by a series of samesized 1dimensional symbolic matrix objects,
and ends with the object pointer to SEMI. The UserRPL compilers
will build only 1 or 2dimensional symbolic matrices. In concept,
we can use the development tools to build a symbolic matrix with
more dimensions (as arrays and linked arrays can have), but I
don't know how the system will handle them; experiment at your own
risk.
Of course the various "numeric" objects can also be embedded
within the composite objects lists and programs, and for some
types, within algebraic objects, and a unit object always includes
a real number object and sometimes real number objects for powers.
Of course, the size of everything is limited by available memory.
For example, a hex string or zint could, in concept, have a length
field of FFFFF hex (10448575 decimal), which would make an object
(including the prologue address) of 1048580 nibbles or 524290
bytes, but the calculators don't have enough system RAM to hold
anything that large.
Regards, James
Edited: 7 Jan 2008, 3:06 p.m.
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
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 nonRPL Saturnprocessor 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 extendedprecision exponent of numbers in the Saturnprocessor 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 HP15C's range of internal and external representations of numbers is the same, but that is incorrect. The HP15C and others have three guard digits for the mantissa, but I'm not sure about the exponent.
http://www.finseth.com/~fin/hpdata/
and click on your model of choice.
Thanks!
 KS
▼
Posts: 1,041
Threads: 15
Joined: Jan 2005
Hi Karl,
Quote:
It's got me wondering whether I stated correctly the storage
format of the exponents on nonRPL Saturnprocessor 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
04, then it represents a nonnegative value, and if it's 59,
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 13nibble 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 04
would represent a negative exponent, and 59 would represent a
nonnegative 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 extendedprecision exponent of numbers in the
Saturnprocessor 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 123456789012345E49999 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 littleendian order.
For the extended real numbers, the (mantissa) sign nibble and
15nibble mantissa use one entire register, and the 5nibble
exponent uses the "address" field (so named because it's used for
5nibble addresses) of another register.
The Saturn Processor's 4 working registers (AD) and 5 scratch
registers (R0R4) 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 143: Mantissa
X: Nibbles 20: Exponent
XS: Nibble 2: Exponent sign
B: Nibbles 10: Byte
A: Nibbles 40: Address
W: Nibbles 150: Word (entire 64bit 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 ARMbased models' emulated processor (Saturnator, also
known as Saturn+) you can also use userdefined fields F1 through
F7. I don't know much about these. Considering that they're
defined using 64bit masks, do these fields still have to end at
nibble boundaries? Also, does a userdefined field have to be
contiguous?
In additional to the new opcodes for userdefined 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 PCbased emulators.
Of course there are several other Saturn registers. Quoting from
SASM.DOC:
Quote:
There are four working 64bit registers, five scratch 64bit
registers, two 20bit data pointer registers, one 4bit pointer
register, a 20bit program counter register, a 16bit input
register, and a 12bit output register. Return addresses are
stored on an eightlevel hardware return stack that accepts 20bit
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 12bit 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
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
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 Builtin Functions", in HewlettPackard Journal, May 1983:
 Page 28: The value of a negativesign nibble for the mantissa and for the exponent is encoded as 1001 (+9) on the HP15C (and likely on all preSaturn models, I would assume).
 Page 27: The twodigit BCD exponent is given by XX if the exponent sign equals 0 (positive value), and by (100XX) if the exponent sign equals +9 (negative value). So, the encoded exponent is also complemented on preSaturn 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 (twobit difference between 0000 and 1001). Another possibile use is to determine whether the sum of encoded exponents represented an overflow condition, as the twonibble exponents were not uniquely coded.
Regards,
 KS
Edited: 13 Jan 2008, 2:38 a.m.
▼
Posts: 223
Threads: 19
Joined: Jun 2005
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
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
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
Posts: 2,309
Threads: 116
Joined: Jun 2005
The reason for the 9 for both mantissa and exponent sign dates back to the HP35. 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=0C1 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 threedigit 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 threedigit 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 radixindependent 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.
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
Thanks, Eric  that's some real historical insight!
Of course, in addition to math modifications, display space would have required expansion to provide threedigit exponents for the HP41.
 KS
Edited: 17 Jan 2008, 2:23 a.m.
Posts: 1,153
Threads: 94
Joined: Mar 2006
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! ;)
