Re: Mixed radix arithmetic

[Dan Zuras <dan@xxxxxxxxx>]

> From: "Ivan Godard" <igodard@xxxxxxxxxxx>
> To: "Dan Zuras" <dan@xxxxxxxxx>
> Cc: <stds-754@xxxxxxxx>
> Subject: Mixed radix arithmetic
> Date: Thu, 27 Mar 2003 12:22:57 -0800
> 
> 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.

	Well, its only a problem in weak typed languages such as C
	since such expressions can't be formed in strong typed
	languages.

	Therefore, to that extent it is a language issue.

	However, to the extent that we define conversions between types
	(and we DO define them), it is addressed by the standard.

	And, I believe, should be.

> 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.

	It does.

> 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.

	It does support them.

	As for support in software or hardware, the standard is silent
	on this point.  Merely saying that the user should be presented
	with an interface that supports this ability.

	BTW, although the known methods are all software methods, I
	believe it will soon be possible to implement them efficiently
	in hardware.  Usually, base conversion is thought to be rare
	enough not to need hardware implementation.  But, if mixed radix
	expressions start to be routine, someone will rethink that idea.

> 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.

	The radix of a Not a Number.  An interesting concept, that.

	I believe I will disagree that this is necessary in any
	meaningful way but bring it up at the next meeting.

	After all, I may be wrong.

> 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.

	Well this is not how it would be done in any case.  And,
	intuition turns out not to be a good guide in this matter.

	In the last 20 years, several substantially similar methods
	have been created to support correctly rounded base conversion
	efficiently in software.  Even directed rounding may be
	supported.  This is what I meant earlier.

	So, we will be able to interconvert between any two supported
	datatypes across radix directly with no problem.

	I believe someone posted a good bibliography on the subject
	recently.  As you are new to this discussion, perhaps that
	person could re-post them.

> 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.

	As I said, intuition should not be your guide here.

> 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

	Ah, but you DO have the skills.  You just haven't had the
	necessary AHA to know it.  Read some of those papers.  They
	are not difficult to understand.  And the algorithms are not
	difficult to implement.

	BTW, I believe David mentioned that he thought that the use
	of base conversion in mixed expressions (in weak typed
	languages) should be made explicit.

	I agree.  As I don't think we will be able to come up with
	a consistent tower of mixed datatypes, it is really the only
	way to go.

	IMHO, that is.

				Dan