Comment by lsiebert
11 years ago
You know what's worse? Javascript numbers are all floating point numbers, which means integers are 53 bits long. So, you might think this library would try to address issues this can cause, but nope, this is the average statement you'd write if you didn't know was a mantissa was and had never heard of big.js, bignumber.js, decimal.js, crunch.js or even strint (which represents integers as strings because wtf not).
Not to mention the fact that adding many floating point numbers in a naive way results in a serious error accumulation, which is why things like Kahan summation algorithm[1] exist.
[1] - https://en.wikipedia.org/wiki/Kahan_summation_algorithm
Every once in a while, I come to HN, and inevitably find a post about some new JavaScript technology on the front page, wherein I find some comment that gives me a new appreciation for the web app language I use at work, which fortunately is not JavaScript.
I'd be interested to know what language it is.
It must be one of: Elm, Purescript, GHSJS, Faye or Haste
What is the web app language you use at work? I assume you're talking about something that runs on the client -- a web browser -- so it probably compiles down to JavaScript, right? JS literally has no numeric type that isn't a float, so how does your language escape this fundamental limitation?
Not OP, but I used Google's Long.js (among other things) in a project[0] to get around the limitation of not being able to do as in Python:
Almost anything that compiles to JS would be better than by-hand JS; I'd love to use ClojureScript with re-frame at work...
[0] http://www.thejach.com/pseudo-public/webgl_coursera/assignme...
asm.js is proof that a compile-to-JS language doesn't necessarily have to discard the correctness of its number types. A statically typed language can do a lot. Integer values can be can to int32 via `| 0`, longs can be emulated with two numbers (GWT does this).
The tradeoff is speed, especially for dynamically typed languages. Having to check your operand types in JS before doing work is a performance killer.
9 replies →
That's not true. In most javascript implementations, integers will be represented by real 32 bit integers.
How does that help? Besides they overflow to doubles if they get bigger than 2^31-1 anyway.
The problem with a naive average like this is that if you're averaging a bunch of big numbers there is a very high chance of overflow when you're summing, so even if all the numbers fit in 32 or 53 bits your calculation will be off.
If you're not averaging thousands of large numbers, why are you even using a package instead of nums.reduce((a,b)=>a+b) / nums.length anyway?
How does storing integers in 32-bit values help the issue of integers being truncated to 53 bits?
53 bits that cannot overflow (it only becomes less accurate) is not enough but 64 bits are, even with the risk of overflow?
2 replies →
Clearly 2^32+2^32 < 2*53, so there is no problem ;-)
Source? I find this very hard to believe. 1. How does the engine know of it should be an integer or not? 2. Why would they have a special case for this, it won't benefit accuracy and treating them in a special way probably hurts performance more than just always keeping it as doubles.
As long as everything used is really an integer and that everyone you work with is careful to keep things as ints (oring with 0 and such)