5 ms·

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

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).

sdegutis 11y ago
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.
- artine 11y ago
  I'd be interested to know what language it is.
  - bbcbasic 11y ago
    It must be one of: Elm, Purescript, GHSJS, Faye or Haste
- monitron 11y ago
  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?
  - Jach 11y ago
    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: import fractions print str(fractions.Fraction.from_float(0.3333).limit_denominator(10)) 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/assignments/week2/approx_fraction.js http://www.thejach.com/pseudo-public/webgl_coursera/assignme...
  - spankalee 11y ago
    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.
    - ktRolster 11y ago
      And WebAssembly means that soon it will be practical to use any language on the client or server side.
      - TickleSteve 11y ago
        It already is on the server-side. Feel free to use C; at least it would be performant.
        lmm 11y ago
        It's easy to write code that does the wrong thing quickly in any language, and IME that tends to be the usual result of choosing C.
        TickleSteve 11y ago
        ok, you are aware that the vast majority of the worlds software is written in C.... yes there are problems with it but it is still suitable for real-time, embedded, safety critical software of the sort I've been making quite successfully for close to 30 years. Don't fall into the 'C is the devil' trap, any tool can be misused.
        lmm 11y ago
        Straight-up C is not at all suitable for safety-critical software. C plus various bolt-on tools for static analysis and the like can be usable, but is always going to be less effective (IMO) than a unified language where every tool is working according to the same rules. There might be a few legitimate use cases for C, but I've seen people pick it for the wrong reason so often (and using C because "it would be performant" is entirely invalid IME).
  - deleted 11y ago
    [deleted]
xyzzyz 11y ago
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 https://en.wikipedia.org/wiki/Kahan_summation_algorithm
nbzklr 11y ago
That's not true. In most javascript implementations, integers will be represented by real 32 bit integers.
- other_herbert 11y ago
  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)
- colanderman 11y ago
  How does storing integers in 32-bit values help the issue of integers being truncated to 53 bits?
  - e12e 11y ago
    Clearly 2^32+2^32 < 2*53, so there is no problem ;-)
  - esailija 11y ago
    53 bits that cannot overflow (it only becomes less accurate) is not enough but 64 bits are, even with the risk of overflow?
    - colanderman 11y ago
      Who said anything about 64 bits?
      - esailija 11y ago
        The complaint was that JavaScript doesn't have 64-bit integers but only 53.
- PeCaN 11y ago
  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?

sdegutis 11y ago

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.

artine 11y ago
I'd be interested to know what language it is.
- bbcbasic 11y ago
  It must be one of: Elm, Purescript, GHSJS, Faye or Haste
monitron 11y ago
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?
- Jach 11y ago
  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: import fractions print str(fractions.Fraction.from_float(0.3333).limit_denominator(10)) 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/assignments/week2/approx_fraction.js http://www.thejach.com/pseudo-public/webgl_coursera/assignme...
- spankalee 11y ago
  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.
  - ktRolster 11y ago
    And WebAssembly means that soon it will be practical to use any language on the client or server side.
    - TickleSteve 11y ago
      It already is on the server-side. Feel free to use C; at least it would be performant.
      - lmm 11y ago
        It's easy to write code that does the wrong thing quickly in any language, and IME that tends to be the usual result of choosing C.
        TickleSteve 11y ago
        ok, you are aware that the vast majority of the worlds software is written in C.... yes there are problems with it but it is still suitable for real-time, embedded, safety critical software of the sort I've been making quite successfully for close to 30 years. Don't fall into the 'C is the devil' trap, any tool can be misused.
        lmm 11y ago
        Straight-up C is not at all suitable for safety-critical software. C plus various bolt-on tools for static analysis and the like can be usable, but is always going to be less effective (IMO) than a unified language where every tool is working according to the same rules. There might be a few legitimate use cases for C, but I've seen people pick it for the wrong reason so often (and using C because "it would be performant" is entirely invalid IME).
- deleted 11y ago
  [deleted]

xyzzyz 11y ago

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 https://en.wikipedia.org/wiki/Kahan_summation_algorithm

nbzklr 11y ago

That's not true. In most javascript implementations, integers will be represented by real 32 bit integers.

other_herbert 11y ago
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)
colanderman 11y ago
How does storing integers in 32-bit values help the issue of integers being truncated to 53 bits?
- e12e 11y ago
  Clearly 2^32+2^32 < 2*53, so there is no problem ;-)
- esailija 11y ago
  53 bits that cannot overflow (it only becomes less accurate) is not enough but 64 bits are, even with the risk of overflow?
  - colanderman 11y ago
    Who said anything about 64 bits?
    - esailija 11y ago
      The complaint was that JavaScript doesn't have 64-bit integers but only 53.
PeCaN 11y ago
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?