well then avoid floating point as representation. it is not keeping the input 100%, by design - no matter what language. Either use text - "1.1" - or fake-fixed-point via integer - e.g. "1100" for 3 digits after point. or both, i.e. keep the textual input separately from machine representation.
svil On Wed, 20 Feb 2013 14:58:41 +1100 Luca Morandini <[email protected]> wrote: > On 02/20/2013 02:01 PM, Jens Alfke wrote: > > > > On Feb 19, 2013, at 12:46 PM, Luca Morandini > > <[email protected]> wrote: > > > >> Well, there it goes my academic track paper on CouchDB and > >> GeoCouch for FOSS4G '13 :( > > > > Are roundoff errors on the order of one part in 2^56 really a > > deal-breaker for your application? I mean, “17.300000000000000711” > > does _look_ ugly compared to “17.3”, but the difference is > > completely negligible for most purposes. Have you worked out how > > many significant figures of accuracy you need, and are the results > > correct to within those significant figures? > > Well, it is not a matter of precision -as it may be enough for most > purposes- but of external representation: every user would expect to > get back the same data he had put into the database. > > Another issue is the sheer size of produced JSON: we use a lot of > geo-spatial data, and chopping off digits would be a performance boon. > > Regards, > > Luca Morandini > Data Architect - AURIN project > Department of Computing and Information Systems > University of Melbourne > Tel. +61 03 903 58 380 > Skype: lmorandini >
