On Thursday, April 30, 2015 at 7:20:22 PM UTC-4, Páll Haraldsson wrote: > > [Thanks for this addition..! I've been putting this off as I didn't really > need this personally. Just Wrapped PyDecimal as an exercise..] > > As far as I know, numbers in JSON are defined to be binary floating > point.. (as that is what JavaScript only has) but allowed to be taken > otherwise or something.. Not sure how that really works in practice. >
Not at all!!! They are definitely not defined to be binary floating point. In fact, the only way to exactly represent an arbitrary JSON number (in addition to just keeping it as a string), is to store it as an arbitrary precision *decimal* floating point number. There are a number of parsers that do just that. The JSON spec was written carefully to say nothing about the limits of scale and precision of numbers... it does say that Infinity and NaNs are not allowed, so it is actually not able to correctly store an arbitrary IEEE-754 floating point # (either binary OR decimal). Please read the relevant JSON specs, either RFC 7159 or ECMA 404. RFC 7159 (which obsoleted RFC 4627) talks very specifically about numbers - it does say that for *portability*, you might have troubles with numbers that are outside the range representable by an IEEE-754 64-bit binary floating point value (i.e. double). However, both the RFC and the ECMA standard are very explicit that JSON numbers are base-10 numbers. What I would think is the first priority is to change ODBC.jl I noticed it > uses binary floating point for the DECIMAL/NUMERIC type.. There was no good > alternative and as it isn't really meant to be binary and there is a > separate SQL binary type if that is what you want I'm not sure there is any > harm in changing only positive (to at least some type, do not think > arbitrary precision is needed or preferred, but not sure). > > The sooner ODBC.jl is changed fewer will notice a change. Maybe this > applies to other DB wrappers (didn't check, there are others). > Binary floating point is simply not acceptable for many database applications... A good example (which came from Dr. Mike Cowlishaw, IBM fellow, inventor of the Rexx language, author of the decNumber package and a large contributor to the IEEE 754-2008 decimal floating point standard), who showed how a telephone company could lose a large amount of money because of decimal to binary conversion errors... This is a very good presentation: https://www.sinenomine.net/sites/default/files/Cowlishaw-DecimalArithmetic-Hillgang2008_0.pdf Would a switch in any of such cases be needed, with default to the new way? > If default to binary people would probably never change/know about it.. And > I guess not either if default was decimal.. or probably not care about > compatible with old/incorrect way.. > ODBC.jl should simply switch to using a decimal floating point for those types of fields... (and JSON should be changed so that it can use decimal floating point if desired). Scott
