A bugfix for this has been pushed into the 3.0 and devel branches. The fix
will become available with 3.0.2.
Best regards
Jan
Am Montag, 4. Juli 2016 12:36:08 UTC+2 schrieb Jan:
>
> For real numbers that cannot be represented as a binary number, we use a
> double-precision representation internally. There will some noise in the
> least significant bits of the double value if the original value cannot be
> represented as a binary number. This shouldn't matter too much in reality,
> however, it seems that the noise gets multiplied while parsing the
> individual digits of the input. This is a bug and a fix is currently in
> progress.
>
> Best regards
> Jan
>
>
> Am Samstag, 2. Juli 2016 17:42:59 UTC+2 schrieb Frank Celler:
>>
>> The pattern is basically: can a number represented as binary? For example
>> 0.25 = 1/4. Will try to find out, why it is not using a nicer
>> representation as decimal.
>>
>> Am Samstag, 2. Juli 2016 16:14:19 UTC+2 schrieb Scott B.:
>>>
>>> Frank,
>>>
>>> I see the issue without the use of the Java driver at all (but also with
>>> it). I see it when entering data directly into the ArangoDB web interface.
>>> I tried another document for testing purposes, and there is some kind of
>>> pattern, but I'm not sure what it is. I added another simple test document
>>> to a collection in both Arango 3.0.1 and Arango 2.8.9 via their web
>>> interfaces, and then retrieved the saved documents, with different results.
>>>
>>> Data entered:
>>>
>>> {
>>> "first": 0.43,
>>> "second": 0.32,
>>> "third": 0.2,
>>> "fourth": 0.25,
>>> "fifth": 0.26,
>>> "sixth": 0.47,
>>> "seventh":0.3,
>>> "eighth":0.95
>>> }
>>>
>>> On ArangoDB 2.8.9, a subsequent retrieval results in the following data:
>>>
>>> {
>>> "first": 0.43,
>>> "second": 0.32,
>>> "third": 0.2,
>>> "fourth": 0.25,
>>> "fifth": 0.26,
>>> "sixth": 0.47,
>>> "seventh": 0.3,
>>> "eighth": 0.95
>>> }
>>>
>>> But on Arango 3.0.1, I get extra digits added to some of the numbers:
>>>
>>> {
>>> "eighth": 0.9500000000000001,
>>> "fifth": 0.26,
>>> "first": 0.43000000000000005,
>>> "fourth": 0.25,
>>> "second": 0.32000000000000006,
>>> "seventh": 0.30000000000000004,
>>> "sixth": 0.47000000000000003,
>>> "third": 0.2
>>> }
>>>
>>> It isn't just .33 or .66/.67. I'm not sure I could actually describe a
>>> pattern. I thought is the number ended in "5" it was fine, but then look
>>> at how 0.95 was saved.
>>>
>>> I did try saving a simple document using arangosh, and it seems to work
>>> as expected on 3.0.1. However, as soon as I open that document, and a
>>> property to it, and then re-save it through the web interface, it
>>> immediately adds extra digits to the previously correct numbers in the
>>> document.
>>>
>>> So in short, the web UI and the Java drivers both seem to add extra
>>> digits to some floating point numbers on Arango 3.0.1. Arangosh seems to
>>> not have that issue.
>>>
>>> All three seems to work fine on Arango 2.8.9.
>>>
>>> On Saturday, July 2, 2016 at 5:01:57 AM UTC-6, Frank Celler wrote:
>>>>
>>>> In general, there is an issue with 1/3, because it cannot to
>>>> represented as binary number. ArangoDB uses some standard conversion that
>>>> produces the "expected" representation as "0.33". For example, if you use
>>>> the "arangosh", you should see the expected representation. Could you
>>>> check
>>>> this with your dataset? I. e. does
>>>>
>>>> arangosh> db.collectionname.toArray()
>>>>
>>>> show 0.33 and 0.66? If it is showing 0.33000000000000007, it is
>>>> possible that there are changes in Java driver causing this. I have to
>>>> check with my colleagues.
>>>>
>>>>
>>>>
>>>> Am Samstag, 2. Juli 2016 05:10:15 UTC+2 schrieb Scott B.:
>>>>>
>>>>> My apologies, the above makes it look like the value 0.33 in the array
>>>>> was changed to 0.6600000000000001. I ran several tests and copied and
>>>>> pasted the wrong results. It actually ends up as:
>>>>>
>>>>> {
>>>>> "first": 0.3300000000000001,
>>>>> "second": [
>>>>> 0.6700000000000004,
>>>>> 0.5,
>>>>> 0.33000000000000007
>>>>> ]
>>>>> }
>>>>>
>>>>> On Friday, July 1, 2016 at 8:31:34 PM UTC-6, Scott B. wrote:
>>>>>>
>>>>>> Is anyone else seeing odd behavior with ArangoDB 3.0.1 regarding
>>>>>> floating point (Double) numbers?
>>>>>>
>>>>>> I had something odd pop-up in my application after moving to ArangoDB
>>>>>> 3.0.1. JSON objects with decimal numbers (like 0.67) were suddenly
>>>>>> getting
>>>>>> extra precision added to them. To eliminate as many variables as
>>>>>> possible,
>>>>>> I saved the following very simply JSON document via the web interface
>>>>>> (add
>>>>>> document to collection) on both ArangoDB 2.8.9 and ArangoDB 3.0.1:
>>>>>>
>>>>>> {
>>>>>> "first": 0.33,
>>>>>> "second": [
>>>>>> 0.67,
>>>>>> 0.33,
>>>>>> 0.5
>>>>>> ]
>>>>>> }
>>>>>>
>>>>>> On ArangoDB 2.8.9, it is saved exactly as expected. However, on
>>>>>> ArangoDB 3.0.1, it gets saved as:
>>>>>>
>>>>>> {
>>>>>> "first": 0.33000000000000007,
>>>>>> "second": [
>>>>>> 0.6700000000000002,
>>>>>> 0.5,
>>>>>> 0.6600000000000001
>>>>>> ]
>>>>>> }
>>>>>>
>>>>>> My ArangoDB 3.0.1 server is running on a clean Ubuntu 16.04 LTS
>>>>>> install.
>>>>>>
>>>>>> My ArangoDB 2.8.9 server is running on Ubuntu 14.04 LTS with a lot of
>>>>>> other services/software installed.
>>>>>>
>>>>>> I also have the same problem when saving any documents with floating
>>>>>> point numbers using the Java driver to 3.0.1 (but it worked fine under
>>>>>> 2.8.9).
>>>>>>
>>>>>>
>>>>>>
--
You received this message because you are subscribed to the Google Groups
"ArangoDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
