[SERVER-4141] NumberLong.bottom does not return values Created: 25/Oct/11  Updated: 07/Apr/23  Resolved: 27/Jan/17

Status: Closed
Project: Core Server
Component/s: JavaScript, Shell
Affects Version/s: 1.8.1, 2.0.1
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: 93e7a16c Assignee: DO NOT USE - Backlog - Platform Team
Resolution: Done Votes: 3
Labels: mapreduce,, query
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

db.version() 2.0.1 (linux)
db.version() 1.8.1 (win)


Issue Links:
Related
is related to SERVER-14217 Support NumberLong arithmetic in mong... Backlog
Backwards Compatibility: Fully Compatible
Operating System: Linux
Participants:

 Description   

within the javascript shell several NumberLong.bottom, NumberLong.top does not return any value.

s.
NumberLong("5188220513171889152").bottom

while surrounding values seems correct.
NumberLong("5188220513171889151").bottom -> 2147572735
NumberLong("5188220513171889153").bottom -> 2147572737

some more testcases:
NumberLong("5188220483643986944")
NumberLong("5188220484180857856")
NumberLong("5188220484717728768")
NumberLong("5188220485254599680")
NumberLong("5188220486328341504")
NumberLong("5188220486865212416")
NumberLong("5188220487402083328")
NumberLong("5188220487938954240")
NumberLong("5188220513171889152")
NumberLong("5188220517466856448")
NumberLong("5188220518003727360")
NumberLong("5188220518540598272")
NumberLong("5188220787512923136")
NumberLong("5188220788049794048")
NumberLong("5188220871264785408")
NumberLong("5188220871801656320")



 Comments   
Comment by Mira Carey [ 27/Jan/17 ]

After our change to SpiderMonkey, I don't believe this problem exists anymore (those fields are now mediated by special member functions, rather than sometimes being filled and sometimes not).

Comment by Reuben Garrett [ 21/Dec/11 ]

Convenience methods would be very helpful to perform arithmetic using, e.g., Google Closure's goog.math.Long. For example, bitsTop() could return 0 and bitsBottom() could return floatApprox for smaller values representable as 54-bit floats without loss of precision; otherwise, they could return top and bottom (respectively).

Comment by Antoine Girbal [ 02/Dec/11 ]

we can improve the doc and add some convenience methods.

Comment by 93e7a16c [ 03/Nov/11 ]

thank you for the Information.

The distinction (if( top == null ) then value) can, of course, be done on application side.

Without knowing those internal fields, working on a provided collection, there is no other way of evaluating arbitary stored 64bit values from NumberLong (afaik). For this I would like to vote, for having this fields externalized/documented.

Comment by Antoine Girbal [ 26/Oct/11 ]

It only uses top/bottom in case it cannot exactly represent the long value using a double value.
We could always set them, but they are not supposed to be used directly, it's more an internal field.

Comment by 93e7a16c [ 25/Oct/11 ]

approx. failure in 40 cases out of 50000 values.

Generated at Thu Feb 08 03:05:04 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.