- From: Alan Ruttenberg <alanruttenberg@gmail.com>
- Date: Tue, 7 Dec 2010 14:04:42 -0500
- To: thaibinhtran@gmail.com, tredmond@stanford.edu
- Cc: User support for the Protege-OWL editor <protege-owl@lists.stanford.edu>, public-owl-dev@w3.org, Dmitry Tsarkov <dmitry.tsarkov@gmail.com>
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