Re: Floating point proposal from left field... [long]

And "Arnold, Curt" writes:
 - Thanks for your comments, but I assume that the discussion will go over most
 - people's heads.  

If anyone wants further explanation on any of these points (or anything
else fp-related), please contact me.  I'll try my best to explain.

 - From your comments, it appears that you would agree with that.

Certainly, although the set of sensible floating-point systems
is starting not to look too big.  (In a theoretical sense, there
seem to be some very stringent restrictions on fp arithmetic for 
it to be at all useful in reliable systems.  The topic is still 
being explored.)

 - I believe that it is strongly preferrable for an application to
 - express a value to the best of its knowledge and let a receiving system
 - appropriately handle any problems fitting it into its implementation
 - datatype.

I agree with this as well.  The sender can also express the other
aspects it expects the receiver to handle through a compound type,
a struct with any of the bits*, significant digits, etc. fields.
This would both satisfy me and be extensible, so I really like it.

Again, if the intent is to specify an abstract type system to help
parsers quickly validate the _form_ of the data, then I agree with
pretty much all of your fp points.  That would serve my needs quite
well.  The current draft's float and double types would most certainly
not...

The {min,max}{Inclusive,Exclusive} facets do not leave me with a warm, 
fuzzy feeling, but if there's strong demand for them, who am I to 
disagree?  The current definitions of precision and scale can be seen
as advice to parsers in terms of storage space (the equivalents of
length for a string), but I don't see how the bounds can be so 
interpreted.  Simply specifying a non-trivial range for fp data tells 
you nothing of how much storage will be necessary to represent the 
given number in either text or binary.  

I guess I'm still confused as to the XML schema intent.  I haven't
seen a rationale document, and it would be nice to see the reasons
behind the choices in the draft.  That might help to clarify things.

And thank you for sending the files.  Also, thanks for pointing
out the broken link:
	http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf

Jason

Received on Monday, 17 January 2000 13:26:40 UTC