New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Robo 3T 1.1 - Big float numbers are showing incorrectly #1447

Open
jimblind opened this Issue Oct 5, 2017 · 6 comments

Comments

4 participants
@jimblind

jimblind commented Oct 5, 2017

In Robomongo 0.8.5 using query "db.getCollection('collectionname').find({})" got results:

{
    "_id" : 1505121011565746.000000,
    "email" : "test@testemail.com",
    "name" : "John"
}

We use float number type for IDs - in 0.8.5 version such numbers looks OK

In Robo 3T 1.1 for the same query results are:

{
    "_id" : 1.50512101156575e+15.0
    "email" : "test@testemail.com",
    "name" : "John"
}

Please help to get proper values for big float numbers in Robo 3T 1.1.

@jimblind jimblind changed the title from Robo 3T 1.1 - Big floating numbers are showing incorrectly to Robo 3T 1.1 - Big float numbers are showing incorrectly Oct 5, 2017

@patrick-webs

This comment has been minimized.

patrick-webs commented Nov 10, 2017

I am experiencing the same issue. As a result, the "Copy JSON" output is not considered valid for "Insert Document" which makes it difficult to move data from one collection to another.

As a workaround the following regular expression can be used on the output of copy JSON:

find: (\d+)\.(\d+[1-9])e\+(\d+)\.0
replace: $1$2.0

@simsekgokhan

This comment has been minimized.

Collaborator

simsekgokhan commented Dec 7, 2017

Hi @jimblind, @patrick-webs, thanks for reporting the problem.
We plan to find a fix to this problem and include it in next release Robo 3T 1.2.

@patrick-webs
Can you give a concrete example for your problem?
Can be similar to @jimblind comment.

@simsekgokhan simsekgokhan self-assigned this Dec 7, 2017

@simsekgokhan simsekgokhan added this to Candidates in Robo 3T 1.2 Dec 7, 2017

@simsekgokhan simsekgokhan moved this from Candidates to In-progress in Robo 3T 1.2 Dec 7, 2017

@patrick-webs

This comment has been minimized.

patrick-webs commented Dec 7, 2017

Hi @simsekgokhan I think the problem I had was the exact same as reported by @jimblind , which is that when I do "Copy JSON" in Robo 3T I get a result like this:

{
    "_id" : ObjectId("5a21d0c62429ea3febffe394"),
    "foo" : {
        "bar" : {
            "1585620893902677" : {
                "a" : 1.58562089390268e+15.0,
                "b" : "abc",
                "c" : "def",
                "d" : 1
            },
        }
    }
}

note the value for the "a" key is not accepted as a valid JSON value for inserting back using the Insert Document feature of Robo 3T.

@simsekgokhan

This comment has been minimized.

Collaborator

simsekgokhan commented Dec 11, 2017

Update:
Using Qt functions for parsing double solves some of current issues but now system has new problems due to an incorrect parsing by mongo::BSONElement::Double().

Next Actions

  • Investigate mongo::BSONElement::Double() or find another solution

Details:

  • Current problems (Robo 1.1):
    . 1505121011565750 is shown in scientific format as 1.50512101156575e+15.0
    . 1.0000000000000002 shown incorrectly as 1 (1.0000000000000002 is the smallest double-precision number > 1)
    . 1.005 shown correctly

  • Solution-1:
    . Using QString::number(...)
    . 1505121011565750 shown correctly
    . 1.0000000000000002 shown correctly
    . 1.005 shown not correctly as 1.0049999999999999 (Root cause: mongo function elem.Double() returns vlaue 1.005 incorrectly as 1.0049999999999999 (mongo::BSONElement::Double()) )

simsekgokhan added a commit that referenced this issue Dec 24, 2017

#1155, #1447: Attempt to fix double type issues: scientific format pr…
…oblems, incorrect value representation for 15 digit precision, -Infinity problem.
@simsekgokhan

This comment has been minimized.

Collaborator

simsekgokhan commented Dec 24, 2017

Update:
After improving the existing solution, most of the problems in this ticket and in #1155 seem to be resolved.
Only remaining problem is: "1.0000000000000002 (16 digit precision) shown incorrectly as 1. (1.0000000000000002 is the smallest double-precision number > 1)".

Next Actions

  • Solve the issue: "1.0000000000000002 (16 digit precision) shown incorrectly as 1"

Details:

  • Current problems (Robo 1.1):
    . "_id" : 1505121011565750 is shown in scientific format as "_id" : 1.50512101156575e+15.0
    . 1605131049382900 is shown in scientific format as 1.6051310493829e+15.0
    . 1.0000000000000002 (16 digit precision) shown incorrectly as 1. (1.0000000000000002 is the smallest double-precision number > 1)
    . 1.000000000000002 (15 digit precision) shown incorrectly as 1.
    . "-Infinity" is shown incorrectly as "Infinity" in text mode.
    . Infinity and -Infinity is shown as inf/-inf in tree/table mode.

  • Solved cases with the latest commit b48dc0b:
    . Using QString::number(...) for solution.
    . "_id" : 1505121011565750 shown correctly in decimal format (not in scientific format).
    . 1605131049382900 shown correctly in decimal format (not in scientific format).
    . 1.000000000000002 (15 digit precision) shown correctly .
    . "-Infinity" is shown correctly as "-Infinity" in text mode.
    . Infinity/-Infinity is shown correctly as Infinity /-Infinity in tree/table/text mode.

  • Remaining problems after the latest commit b48dc0b:
    . 1.0000000000000002 (16 digit precision) shown incorrectly as 1. (1.0000000000000002 is the smallest double-precision number > 1)

@arboleya

This comment has been minimized.

arboleya commented Nov 5, 2018

@simsekgokhan Any news on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment