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

[Scott Meyer]

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.  Because of this and the way
> processors and software libraries do calculations, rounding, etc, it's
> bad practice to check for exact equality of floating point numbers by
> comparing their binary representation.  Instead, the difference
> between the two numbers is calculated and compared to some small
> value, often referred to as "epsilon," and if the difference is less
> than this value, the numbers are considered equal.
> 
> It would appear that MQL is not using this technique or perhaps the
> value of epsilon is set too low to accommodate variability introduced
> by the software stack and the various conversions that are done.
> 
> Is my interpretation accurate (and thus this should be filed as a bug)
> or is something else going on here?

In the database, we store floating point values as strings so there's no
representational limit.  Equality means "exactly equal," not "close
to".

> On Tue, Jul 28, 2009 at 10:20 AM, Tom Morris<tfmorris at gmail.com> wrote:
>> If I run this query twice
>>
>> [{"guid": "#9202a8c04000641f80000000087c7629",
>>  "type": "/location/location",
>>  "area": {
>>    "connect": "insert",
>>    "value":   0.0012141000000000003
>>  }}]
>>
>> The second run will return the following error
>>
>>    "info": {
>>      "key":      "value",
>>      "newvalue": 0.0012141000000000003,
>>      "value":    0.0012141
>>    },
>>    "message": "Found existing value for unique property, try update",
>>
>> where I'd expect it to return "present."
>>
>> Is there any way around this behavior other than pre-reading and
>> comparing myself (doubling the latency)?

Case 1: your area computation really is accurate to 18 significant digits

I think that we're doing exactly the right thing.  Picking some
general purpose epislon is virtually guaranteed to to make the guy
who has lovingly hand crafted a fixed point area computation which is
really accurate to 18 SD apoplectic with rage.

Case 2: your area computation isn't really that accurate

How about clamping to a modest 5 SD?

I suppose we could come up with guidelines for how many significant
digits should go into particular properties; even 5 seems like
overkill for the purposes of describing real estate.

-Scott