couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Date Tue, 14 Feb 2012 05:35:32 GMT
On Mon, Feb 13, 2012 at 7:23 PM, Jason Smith <jhs@iriscouch.com> wrote:
> On Mon, Feb 13, 2012 at 5:26 PM, Paul Davis <paul.joseph.davis@gmail.com> wrote:
>> The issue here is how we define "same". Given your examples you appear
>> to be arguing for byte level equivalence between input and output.
>> While this may seem quite logical and even perhaps a necessity for
>> something that calls itself a datastore, its not how the world works.
>> Rather than convince you, I'll just show two examples:
>
> Hi, Paul. I hope you'll agree that just because SQL does that, CouchDB
> doesn't necessarily have to. Of course, you make a strong case that
> Couch can do what most people expect (round trip the sequence of
> numerals through IEEE floats).
>

I like this description and I agree completely. I only meant to
illustrate that numbers pass through IEEE representations often enough
that its not very safe to assume that numeric representations won't
change.

> FWIW, I started out by taking a similar position as yours; however, I
> feel the users and Filipe are describing a more relaxing Couch.
>

I disagree heartily. Expecting every bit of internal code to remember
that some JSON may or may not be partially parsed is about as
unrelaxing as possible. Saying that JSON numbers that contain a
decimal point or exponent are represented internally as IEEE-754
double precision floating points is much more relaxing.

> I notice you didn't like Filipe's patch; but what if CouchDB used a
> hypothetical decimal implementation? It had honest-to-God proper
> numbers, with round-trip identity and all of it? (View collation is a
> distraction since that is Javascript and we can all expect IEEE-754.)
>
> In other words, instead of an experimental encoding trick, CouchDB
> used well-known decimal types. Would that change your opinion at all?
>

Hypothetically I wouldn't reject it out of hand. Hypothetically, if
something were to exist and were significantly less intrusive than a
tagged binary then maybe. Though I hypothesize that nothing like this
exists. Erlang's type system is basic and has no notion of operator
overloading or otherwise. Thus, at best, we provide mathematical
routines for internal use but nothing else changes much. It'd still be
some sort of tagged value that we'd have to use function calls to do
any sort of mathematical manipulation if the need were to arise.

Also note that while JavaScript might be a PITA, its not the only view
server and other view servers (specifically Erlang) will have to deal
with this.

>> I'd try MySQL but I bet it returns 2.89 because of some bug.
>
> Hey, come on, that's bigotry.
>

http://sql-info.de/mysql/gotchas.html#1_14

>> In the end, as we've constantly repeated, anyone that wants the
>> absolute best numerical fidelity when using JSON should always use
>> strings and rely on application logic to ensure that a suitable
>> bignum/bigdecimal implementation exists.
>
> CouchDB has one already, https://github.com/iriscouch/bigdecimal.js
>
> I used GWT to compile the Apache Harmony (Java) BigDecimal
> implementation to Javascript, and wrap it in CommonJS. It works in
> CouchDB, Node.js, and browsers.
>

This approach is relaxing. If users need special number handling then
they can use special number handling.

Mime
View raw message