[Developers] Problem writing floating point value twice (or "What value of epsilon does MQL use?")

[Warren Harris]

On Jul 29, 2009, at 2:19 PM, Tom Morris wrote:

> On Wed, Jul 29, 2009 at 3:17 PM, Scott Meyer<sm at metaweb.com> wrote:
>> Tom Morris wrote:
>>> I guess maybe I should define my use of "epsilon."  In any given
>>> floating point representation, not all numbers can be represented
>>> exactly, even if they are in range.
>>
>> In the database, we store floating point values as strings so  
>> there's no
>> representational limit.  Equality means "exactly equal," not "close
>> to".
>
> I guess I should have qualified my statement mroe.  That's the one
> floating point representation where exact comparisons will work.
>
> Given that you intend to do exact comparisons, there's definitely a
> bug.  Worse than that, the values getting written to the database are
> getting truncated which is what causes the later comparison to fail.
>
> On Wed, Jul 29, 2009 at 3:59 PM, Warren Harris<warren at metaweb.com>  
> wrote:
>
>> Aside from the epsilon comparison issue, there is probably a bug here
>> in that our python layer will often munge the number of significant
>> digits before it ever gets to our database where the comparison is
>> performed. I plan to fix this in then next major release of mql.
>
> The fact that float are stored as strings makes the comparison to
> epsilon unnecessary.
>
> I'm not sure which Python layer you're referring to, but the bug can
> be demonstrated in the query editor, so it's not just freebase-api
> that's affected.  Is there a bug entry for this already or should I
> create one?

These seem closest to what I'm talking about:

https://bugs.freebase.com/browse/ME-1181
https://bugs.freebase.com/browse/MQL-413

>
> I just experimented a little and it appears the truncation starts
> happening after 14 characters or 12 significant digits (not sure which
> is the significant number) i.e. 0.123456789012 works,  0.1234567890123
> doesn't.
>
> If I convert my Python float to a string and truncate the string, will
> the JSON marshalling done by python-api and lower layers do the right
> thing or does it need to be in float format as it goes into the pipe?

The issue here is partly related to how our json library parses your  
float, and how python formats it before sending it to our graph  
database. But without a careful analysis of all possible code paths,  
it seems unlikely that you'd be able to work around this in all cases.

Warren