- From: Michael Smith <msmith@clarkparsia.com>
- Date: Thu, 10 Jul 2008 12:53:32 -0400
- To: Rob Shearer <rob.shearer@comlab.ox.ac.uk>
- Cc: public-owl-wg@w3.org
On Thu, 2008-07-10 at 15:31 +0100, Rob Shearer wrote:
> Two notes on this:
>
> 1. You obviously need ambiguous values for this problem to arise, and
> the IEEE spec only allows ambiguity for pretty wacky numbers. Anything
> representable (not just represented, but representable) in decimal as
> ±M × 10^{±N} for M < 10^9 and N < 14 is unambiguous (M < 10^17 and N <
> 28 for double-precision), so users need to type a lot of digits before
> they start experiencing the problem.
This information is very helpful. The magnitude of the exponent here
makes me much more comfortable living with this problem.
> 2. A single ambiguous value does not in itself produce a problem.
> Problems only arise in ontologies which use one ambiguous value, as
> well as other values within the range of IEEE-754-legal
> interpretations of that value. Given that the IEEE-754-legal range is
> quite small (a limited error is allowed only in the least significant
> digit of the destination type, which I read as the last bit of the
> float), this issue is unlikely to arise very often.
>
> I agree that this situation kind of sucks, but I don't see any viable
> alternatives. The non-viable ones I can come up with are:
>
> 1. Disallow floating-point numbers entirely. This seems like a non-
> starter---the vast vast majority of scientific data makes use of such
> numbers.
> 2. Only allow unambiguous floating-point representations. This seems a
> clear violation of the XSchema semantics. What is more, the
> implementation burden seems high; libraries usually don't have this
> functionality. I wouldn't know how to implement this, and I strongly
> suspect many implementors would either not implement it at all or get
> it wrong.
> 3. Impose explicit rounding rules above and beyond IEEE-754. This
> would break every floating point implementation in existence. I would
> encourage Oxford to object to such a model, and I can't imagine such a
> proposal passing a vote of the AC.
Would mandating the rounding algorithm remove the ambiguity?
> Other suggestions?
If we can define, as you have above, the circumstances in which problems
become visible, those circumstances should be documented in some user
facing document.
--
Mike Smith
Clark & Parsia
Received on Thursday, 10 July 2008 16:54:12 UTC