well, any language (of your input system) that uses floating point will change your numbers. Even before they reach database (of any kind).
This is not couchdb specific, just human2machine stuff - going through machine FP, anywhere in the data flow, will change the numbers. so u have to avoid/solve that first.. do not mix human (textual/symbolic) representation with the machine FP one. svil On Wed, 20 Feb 2013 16:39:59 +1100 Luca Morandini <[email protected]> wrote: > On 02/20/2013 03:10 PM, svilen wrote: > > 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. > > As I -repeatedly- have written, our system shall accept a number of > different data models, models that cannot be known in advance, hence > both suggestions are very difficult to implement, not to mention the > performance penalty involved. > > Transforming every number in a string would entail putting a "flag" > on every number, to tell which one was a genuine number. Something > like: [1.1, 2.2, 3.3, "abc"] ==> [{"_": "1.1"}, {{"_": "2.2"}, {{"_": > "3.3"}, "abc"] > > This "flag" would make possible the conversion back to numbers. > > Regards, > > Luca Morandini > Data Architect - AURIN project > Department of Computing and Information Systems > University of Melbourne > Tel. +61 03 903 58 380 > Skype: lmorandini >
