W3C home > Mailing lists > Public > public-webont-comments@w3.org > July 2008

Re: ISSUE-126 (Revisit Datatypes): A new proposal for the real <-> float <-> double conundrum

From: Dave Peterson <davep@iit.edu>
Date: Mon, 7 Jul 2008 21:38:21 -0400
Message-Id: <a06240819c498723c07d6@[]>
To: "Richard H. McCullough" <rhm@PioneerCA.com>, paul@sparrow-hawk.org, Alan Ruttenberg <alanruttenberg@gmail.com>
Cc: Rob Shearer <rob.shearer@comlab.ox.ac.uk>, public-webont-comments@w3.org, public-owl-wg@w3.org, www-xml-schema-comments@w3.org

Let me put one thing to bed once and for all:  No one that I'm aware of
believes that (*absent artificial "coloring" for distinction*) the value
space of float is not a subset of the value space of double, or that
the value space of double is not a subset of the value space of decimal.
The problem is in the details of all the additional baggage a datatype
carries, over and above its value space.

At 4:38 PM -0700 2008-07-07, Richard H. McCullough wrote:
>I suggest that you consider following the example of classical 
>mathematical analysis -- the delta-epsilon arguments -- or the 
>example of engineering approximations.

I'm very interested in knowing how Leibnizian epsilon-delta arguments
impact the question of how one can or should derive double, and then
float, from decimal.

>Domains may be disjoint in theory, but when you make real measurements,
>and consider measurement precision/errors, they're not really disjoint.

True.  But there's a lot of difference between saying you have "numbers"
whose exact value you don't know (a la precisionDecimal) and saying that
you have a fixed finite set of numbers into which you must jam all your
values.  Some of the Schema WG members won't even talk to me about
precision any more because I get into too much detail as to just what
precision is in engineering measurement contexts.  Best don't get me
started.  ;-)
Dave Peterson

Received on Tuesday, 8 July 2008 01:39:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:09:30 UTC