Hacker News Reader

Comment by lsiebert | Hacker News Reader

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

View on HN

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?

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.

And WebAssembly means that soon it will be practical to use any language on the client or server side.

It already is on the server-side. Feel free to use C; at least it would be performant.

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.

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.

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

You would have to argue with the overwhelming majority of safety-critical software that is and has been for decades, written in C...

Of course, static analysis is always used in combination with proper coding style... but that is just the normal (professional) C development environment.

> You would have to argue with the overwhelming majority of safety-critical software that is and has been for decades, written in C...

> Of course, static analysis is always used in combination with proper coding style... but that is just the normal (professional) C development environment.

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

Pretty sure you've just restated GP's point in your second paragraph.

You just have to use the right libraries:

https://github.com/Adaptv/ribs2

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/assignme...

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

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)

How does storing integers in 32-bit values help the issue of integers being truncated to 53 bits?

Clearly 2^32+2^32 < 2*53, so there is no problem ;-)

53 bits that cannot overflow (it only becomes less accurate) is not enough but 64 bits are, even with the risk of overflow?

Who said anything about 64 bits?

The complaint was that JavaScript doesn't have 64-bit integers but only 53.

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?

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.

Reply on news.ycombinator.com