W3C home > Mailing lists > Public > public-cwm-bugs@w3.org > June 2005

Re: Bug: Bad N-Triples Float Representation

From: EspeonEefi <eefi@mit.edu>
Date: Thu, 09 Jun 2005 17:21:32 -0400
To: public-cwm-bugs@w3.org
Message-Id: <1118352092.6620.81.camel@localhost.localdomain>

I've tracked down the source of this behavior.

In llyn.RDFStore.intern() a float Literal is created by doing repr() on
the float number. (See llyn.py line 1381 in current cvs.) Thus, when
54321.12345 gets put into a Literal, it's stored as the string

In notation3.ToN3.representationOf(), two different things are happening
to that Literal. (See notation3.py lines 1529 to 1542 in current cvs.)
With --ntriples, the n flag is set, so '54321.123449999999' is sent
straight to stringToN3 to be output. However, without the n flag set (as
in the second example), str(float(s)) with s == '54321.123449999999' is
done, so Python will return the stored string to a float, and then
convert back into a string, but because we're using str, Python will see
all the 9s and round.

The question becomes whether we should do the same prettying regardless
of the flag n. The documentation for n is that it mandates "no numeric
syntax - use strings typed with ^^ syntax." Does this preclude our
rounding of the binary-precision float to a very close much shorter
decimal version?
Received on Friday, 10 June 2005 07:12:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:52:00 UTC