-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Anderson wrote: > If your concern is this strong, then you should be encoding your > numbers as strings and writing your own number handling code.
The point is that they aren't my numbers :-) They are the numbers of the users of my component. That may be another developer or more likely yet another component. Additionally my component is about interoperability so I can't just go ahead and encode numbers differently. > number handling) but we can't, as a pragmatic matter, be responsible > for the behavior of JavaScript or other query-server engines. Well you can take a little "blame" for the one that comes with the CouchDB distribution :-) > If you need application level support for precise numbers, All I expected was to get out what I put in. > or just rely on CouchDB documents (not the view > servers) to handle large numbers accurately. I am changing my code anyway to get the complete documents (include_docs) as opposed to getting just the keys I am interested in via the view. In theory this may result in more data being transferred but I can live with that. > I think it's fine that our JS engine is lossy on large numbers. If it > turns out to be trivial to patch for better math, I'd be in support. I understand that it is just the way JS works and it is impractical to fix. I do think it would be valuable for there to be a test/compliance suite in CouchDB that at least detects and documents the issue for any view server. That is also valuable information for anyone choosing a view server. Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkr5IB4ACgkQmOOfHg372QSVywCdF+TxjiIrudIshGYeJoLekPlV W5YAn19RmaWEpPwQy56fMaZeqopbIe8m =1fqU -----END PGP SIGNATURE-----
