Re: Importing NaNs

[Dan Zuras <dan@xxxxxxxxx>]

> From: "Ivan Godard" <igodard@xxxxxxxxxxx>
> To: "Dan Zuras" <dan@xxxxxxxxx>
> Cc: <stds-754@xxxxxxxx>
> Subject: Importing NaNs
> Date: Thu, 27 Mar 2003 12:41:17 -0800
> 
> Should the Standard address importing of FP data from foreign systems?

	While the standard doesn't say anything about where an FP
	datum comes from, the standard has always supported data
	formats that are defined down to the bit.  So, assuming
	you can move those bits from one machine to another, the
	standard supports it.

	And, I believe we should continue to do so.

	The biggest problem has always been byte ordering.  But,
	assuming you can tell your "strings" from your "sgnirts",
	you should be able to tell your "123.456" from "654.321".

	(Please forgive the slight editorial license here but I have
	always thought that the punch line is more important. :-) )

> 
> The concrete representations have to be converted during import. The
> Standard could define a Wire Form representation, and require that any
> implementation support conversion to and from Wire Form. It appears that the
> current expectation is that textual representation would serve as Wire Form,
> and that is probably true for decimal radix implementations. But a round
> trip of a binary representation to text and back looks to lose bits (not
> sure of this). This could be avoided if the text form supported choice of
> exponent radix, which you may have already discussed. However, even text
> with choice of radix will not help when the source and target
> implementations use different radices.

	As you should be able to move the FPs directly, I'm not sure
	why the "wire form" should be different than the data format.

	After all, byte order aside, how is a number coming from RAM
	different from a number coming from France?

> 
> As a second note, it seems probably that many systems will store "useful"
> information in the the spare bits of a NaN in an implementation defined way.
> NaNs imported from foreign systems will have meaningless bits in a NaN on
> the new host, and the hardware and software behavior of the host in the
> presence of these bits might be undefined (by the host as well as the
> standard) and no doubt unfortunate. This suggests that there needs to be a
> Wire Form for NaNs too. The Wire Form (which might be text) should at least
> indicate the kind of NaN.
> 
> Ivan

	This has always been so & is one of the reasons we tried to
	dump SNaNs.  Without defining what you use NaNs for, I can't
	see how this can be fixed.

	And, I don't think we want to define what they're for.

	We may define what they're NOT for, though.  That might help.

	Its worth some thought.


				Dan