Float equality in OWL was: FYI fact++ bug?

I asked Dmitry Tsarkov, developer of Fact++ about this and he says:
"I'd like to remind you that any precise checks for the floating point
datatypes looks should be avoided and considered
implementation-defined."
He will check it out when he has a chance.

The OWL Spec defers to XML Schema for this and most datatypes.
http://www.w3.org/TR/xmlschema-2/#float

That spec says: A literal in the ·lexical space· representing a
decimal number d maps to the normalized value in the ·value space· of
float that is closest to d in the sense defined by [Clinger, WD
(1990)]; if d is exactly halfway between two such values then the even
value is chosen.

This looks well defined, though one could imagine a situation in which
not all parties were parsing floats as specified leading to troubles.
I this case we have at least the code that parses manchester syntax in
the interface and that parsing the OWL source involved.

I concur that the practice of depending on float equality can
generally lead to errors, but I'm not sure whether Dmitry is correct
in asserting that the results would be implementation independent.
Anyone on OWL-DEV care to comment?

It would be useful to design a test case that could be tested solely
by use of a single OWL file - not in addition the protege UI, so that
we might find that the culprit is the UI parsing of floats.

-Alan

> From: Timothy Redmond <tredmond@stanford.edu>
> Date: December 3, 2010 6:07:16 PM EST
> To: protege-owl@lists.stanford.edu
> Subject: Re: [protege-owl] Question on FaCT++ reasoner
> Reply-To: User support for the Protege-OWL editor
> <protege-owl@lists.stanford.edu>
>
>
> I tried this also and got the same result.  I think that complete reasoners
> should all get the same result.  So one of them is wrong and it seems to me
> that it is FaCT++.  Pellet agrees with Hermit.
>
> -Timothy
>
>
> On 12/03/2010 05:50 AM, Tran Binh wrote:
>
> Hi all,
>
> Maybe there is same question somewhere but I could not find out.
>
> My problem with FaCT++ for protege 4.1 beta is when I search for data
>
> property, for example I search for
>
> SatelliteImage and hasResolutionValue some float[<= 12f] DL query just
>
> return individuals<  12 not the individual = 12. I use HermiT 1.3.1 for
>
> testing and it work perfect, it return both the individual<  and = 12.
>
> Is that the rule of FaCT++ reasoner? Could anybody show me where I can get
>
> FaCT++ document?
>
> Thank in advances,
>
> Binh
>
> _______________________________________________
> protege-owl mailing list
> protege-owl@lists.stanford.edu
> https://mailman.stanford.edu/mailman/listinfo/protege-owl
>
> Instructions for unsubscribing:
> http://protege.stanford.edu/doc/faq.html#01a.03
>

Received on Tuesday, 7 December 2010 19:05:38 UTC