Details

Type: Improvement

Status: Open

Priority: Major

Resolution: Unresolved

Affects Version/s: 1.2

Fix Version/s: None

Component/s: None

Labels:None

Skill Level:Committers Level (Medium to Hard)
Description
The JSON spec has a very loose definition of Number. CouchDB, as a database, should have welldefined and first class support for numbers (both integral and decimal). The precision of number support should be formally specified as should the algorithm used to represent floatingpoint values, especially where an approximation must be made in the conversion.
So this whole thing has really gotten blown out of proportion. While we have never formally documented what's going on internally, it can be described as such:
A number is parsed into one of two forms:
If the number contains a decimal point (".") or an exponent ("e" or "E") then the number is internally converted into an IEEE754 floating point representation. This means that numbers containing either a decimal point or exponent are subject to the constraints of having a finite number of bits representing the number as is standard operating procedure.
If a number does not contain a decimal point or exponent then it is parsed as an integer with (theoretically) no loss of precision (I think precision is bound by the amount of RAM IIRC but I don't promise there aren't any bugs). (Side note for Jiffy, technically, if a number fits in a signed 64bit representation, that is used. If not then parsing is deferred back to Erlang which handles parsing as a bignum).
Literally, the only thing that's wrong in
COUCHDB1407is that number formatting for doubles changed a wee bit and it has a simple fix and now people are getting all crazy about numbers and ignoring other places that JSON is munged. Blergh.