[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. 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). 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.. In general is there a better way for broken compatibility? I know about Compat.jl, seems for syntax level and can't work/not made for this. -- Palli. On Wednesday, April 29, 2015 at 12:08:48 PM UTC, Scott Jones wrote: > > One place where I'd like to see this used is with the JSON parser... the > current JSON parser can't represent all numbers, it's a potentially lossy > transformation from JSON numbers to > binary floats... although Javascript only has the equivalent of Float64 > for all numbers, the good JSON parsers that I've seen have the option of > using something like > Python's Decimal or Java's BigDecimal). This would get us part of the > way there... you do really need to use BigInt and an arbitrary precision > decimal floating point type to correctly > handle all numbers without losing information (this is why I'd also like > to see a wrapper for the decNumber package, it supports all 6 fixed with > formats, an arbitrary precision format, it supports many more platforms > such as IBM's Power, and might even be usable for ARM builds). > > Great stuff! > > On Tuesday, April 28, 2015 at 9:26:17 PM UTC-4, Steven G. Johnson wrote: >> >> The DecFP package >> >> https://github.com/stevengj/DecFP.jl >> >> provides 32-bit, 64-bit, and 128-bit binary-encoded decimal >> floating-point types following the IEEE 754-2008, implemented as a wrapper >> around the (BSD-licensed) Intel Decimal Floating-Point Math Library >> <https://software.intel.com/en-us/articles/intel-decimal-floating-point-math-library>. >> >> Decimal floating-point types are useful in situations where you need to >> exactly represent decimal values, typically human inputs. >> >> As software floating point, this is about 100x slower than hardware >> binary floating-point math. On the other hand, it is significantly >> (10-100x) faster than arbitrary-precision decimal arithmetic, and is a >> memory-efficient bitstype. >> >> The basic arithmetic functions, conversions from other numeric types, and >> numerous special functions are supported. >> >
