Actually, regarding fractions, the 49 series has additional functionality compared with the 48 series.

The 49 series adds the "exact integer" (object type 28); the only limit on the length of an exact integer is available memory. When in "exact" mode (flag -105 clear), numbers entered without fraction marks are compiled to exact integers. With flag -3 cleared ((Function -> symb) and flag -2 cleared (Constant -> symb), a calculation won't change the exact integers to "real numbers" (object type 0) unless a real number (or an expression which contains a real number) is an argument. Additionally, there's a "textbook" display mode, which displays an expression on the stack in a manner similar to how it would look in the equation writer.

The PROPFRAC command, with an improper fraction (or expression that evaluates to an improper fraction) for its argument returns either an integer plus a proper fraction, or an integer. Alternatively, with an integer plus a fraction for its argument, PROPFRAC returns either an improper fraction or an integer. For example, '4/3' PROPFRAC returns '1+1/3', '6/3' PROPFRAC returns 2, '1+1/3' PROPFRAC returns '4/3', and '1+3/3' PROPFRAC returns 2.

For PROPFRAC, the CAS requires flags -2, -3, and -105 to be clear, which seems straight-forward enough, but also requires flag -17 to be set (radians mode), the reason for which being beyond me.

The ->NUM command will attempt to evaluate any object to a real number, erroring out if it can't.

I->R changes an exact integer to a real number, and R->I changes an integer-valued real number to an exact integer.

In case anyone is interested, the memory required for most exact integers is 5.5 bytes plus 0.5 bytes per digit (5 nibbles for the prologue address, plus 5 nibbles for the self-inclusive length field, plus 1 nibble per digit, plus 1 nibble for a sign field. The exact integer 0 is an exception, using only 5.5 bytes because it doesn't have a sign field. Also, some exact integers are built-in to ROM, in which case they need only 2.5 bytes (5 nibbles for the ROM address) in many cases. For example, the exact integers -9 through 9 will be compiled to this 2.5-byte ROM address form and the stack pointers will be the ROM addresses, but if one of these numbers is stored in a variable, the 5.5- or 6-byte object found at the ROM address is stored instead; 0 BYTES returns #0h and 2.5, but 0 'FOO' STO FOO BYTES returns #4789h and 5.5.

With an exact integer for its argument, the SIZE command returns the number of digits (as a real number) in the integer. An exception: with the exact integer 0 for an argument, SIZE returns 0.; bug?

Regards,

James

*Edited: 20 Nov 2006, 6:00 a.m. *