[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Mixed radix arithmetic



Been thinking a little about the mixed radix problem, and have got this far:

1) I agree that mixed radix arithmetic operations are a language issue and
should not be addressed by the standard.
2) The standard must address interradix conversions, both on machines which
support both radices and to deal with data imported from foreign machines
via files.
3) To that end, the standard should specify that no matter which (or both)
radices an implementation supports, they must also support interradix
conversion in both directions. These conversions, as always, may be in
software. They would be invoked in a language-specified way, typically a
cast or pseudofunction.
4) There should be a defined union set of NaNs, so that all NaNs are
representable in either radix implementation, whether they can be created in
the native radix or not.
5) I don't think that it is sufficient to define conversion as the result of
converting the sourse to a print string per the standard and then converting
the string to the destination. Intuition says that this will produce
conversions that are not the closest representable value, and maybe not even
very close at all.
6) The alternative of defining conversion as selecting the closest
representable value will be very hard to implement in hardware due to the
non-linear "jaggies" as the exponents scale.
7) A conversion algorithm that is unambiguous, efficient in both software
and hardware implementations, and with good mathematical properties looks to
be hard to do, and in any case takes skills I don't have. Good luck :-)

Ivan

754 | revision | FAQ | references | list archive