EXTended NUMeric (EXTNUM)
SWBIC Products & Services >> Bioinformatics >> EXTNUM >> Internal Structure & Operation
2. Internal Structure and Operation
2.1 Range of representation

The EXTNUM class represents the floating point number in two parts: a type (double) mantissa and a type (long int) signed base 2 exponent without an offset. Upon construction of an instance of this class, the mantissa is normalized to have an absolute value between 1 and 2. The signed exponent may assume any value within the allowable range of a long, so that the composite EXTNUM number may assume any absolute value between 1 x 2^^{2147483648} and 2 x 2^^{2147483647}, or about 1 x 10^^{646456993 }to 2 x 10^^{646456992}.
2.2 Use of the IEEE floating point format

The IEEE 754 double precision floating point format utilized by this package consists of a 64bit word that is subdivided into a 1bit sign field, an 11bit exponent field, and a 52bit mantissa field. On most machines, the mantissa is normalized so that an implicit value 1 bit leads the mantissa, followed by the 52bit fractional mantissa. Under such normalization, the mantissa thus assumes base 10 absolute values between 1 and 2. The exponent field is offset by adding a value of 1023 (decimal), so that no sign bit is required (at the expense of dynamic range).
The sequence in which the bits of the type double word are stored varies among different machines. Most PC’s that run as Linux or BSD boxes use a “little endian” storage sequence in which the sign bit and 7 most significant bits of the exponent field are stored in the highest byte (byte [7]) of the 8byte double. The four least significant bits of the 11bit exponent field and the four most significant bits of the explicit (fractional portion) 52bit mantissa are stored in the next highest byte ([6]) of the double. On a “big endian” machine, the sign and most significant exponent bits reside in the lowest byte ([0]), followed by the remaining exponent bits and lead mantissa bits in byte [1]. The Silicon Graphics (SGI) and Sun systems tested with this package use the “big endian” format for the type double word.
2.3 Method of implementation

The EXTNUM class implemented here stores the exponent in a type long data member and the mantissa in a type double data member in the private section of the class. Unlike the builtin double type, the exponent portion of the EXTNUM data field is signed and is not offset. This arrangement simplifies the coding required to implement overloaded mathematical and relational operators and functions. Access to this class is provided by friend extractor/inserter operators for streams and various constructors. The extractor operator makes use of a member conversion function that takes base 10 mantissa and exponent values (parsed from the input stream) as its arguments. Like the mathematical member functions of the EXTNUM class that return an EXTNUM type argument, this conversion function returns with a call to a constructor that takes a mantissa and a base 2 exponent argument.
This EXTNUM constructor call renormalizes the number so that the exponent field of the type double mantissa is added (after removal of the 1023 offset) to the type long EXTNUM exponent. The reason that the EXTNUM result is renormalized after each overloaded operation is that chained sequences of operations can easily overwhelm the dynamic range of the mantissa unless normalization is enforced. The bit field manipulations necessary to renormalize an EXTNUM type are accomplished with the DblBits class.
When a DblBits variable is constructed (using the type double mantissa as its input argument), a union is formed between the double and an 8 byte array of unsigned characters. These byte array elements may be manipulated via multiplications, divisions, and bit shifts. Besides the constructor, the DblBits class provides two inspectors and two manipulators for the mantissa’s 11bit exponent field. The extraction manipulator decodes the bit field pattern of the exponent, removes the offset, and returns the base 2 result. This extracted value is added to the EXTNUM exponent by the EXTNUM constructor, as indicated above. The DblBits insertion manipulator is then used by the constructor to replace the exponent field of the mantissa with an offset zero (= 1023) to complete the renormalization.
The two inspection functions provided in the DblBits class are not used in the current implementation of EXTNUM. They are supplied to allow the user to examine the bit pattern of the entire mantissa or the offset value of its exponent, if so desired. Once a type EXTNUM number has been constructed, relational and mathematical operations similar to those for the builtin type double are relatively straightforward in implementation. Due to the C++ convention that the lefthand operand of a binary member operator is passed implicitly, binary operator overloads are implemented as friend functions for the EXTNUM class. Operands are then passed explicitly to the operator, allowing arbitrary typing for the lefthand operands.