Hacker News Reader

Comment by ricardobeat | Hacker News Reader

Almost every shopping cart in existence right now is written in PHP, Python or Ruby, and they have much of the same "issues". Write tests, use a good bignum library, maintain code standards. Syntax is subjective, I find it pretty nice when following a certain style.

Almost nobody modifies Object.prototype, and we now have plenty of APIs to deal with that - defineProperty, seal, freeze, etc.

View on HN

Was just going to say, a large percentage of online shopping is based on open source e-commerce solutions, most of which are written in PHP. Which shares (and possibly overshadows) Javascript's problems.

What's the big deal with getting bignum into js? Everything else I can agree with, but not having 64bit int support in a server side language has to hurt. (just look at most node db adapters and bigints are handled as strings)

Okay, aside from some scientific functions, what do you really need from an integer that 52bits isn't enough for?

It's not about storing large numbers, but math precision. For example:

    0.3 * 3 => 0.8999999999999999

A few rounding mistakes and you have a huge mess.

You seemed to have jumped from talking about integers to floating point!

And the example you have given is a problem with all floating point implementations, not just Javascript. You will get that exact same answer in C, Java, etc.

The only way to avoid this is to represent rational numbers directly, without simplification. For example:

  (3/10) * 3 => (9/10)

There are no integers in js, all numbers are floats. What you want to do is represent all values as integers choosing an arbitrary precision, then only do integer math.

In the example given, using node-bignum and assuming our precision is a thousand of a cent:

    big(30000).mul(3) => 90000

Of course you'd get the same result in plain javascript with these numbers, but then you'd have to handle everywhere an operation could return decimals, and using bignum you have "unlimited" precision > 52bits.

I agree with what you are saying. It's just that you gave a floating point multiplication example, where an integer multiplication with overflow would have been a relevant example.

Here's a relevant example,

    2^26 * 2^26 == 2^52

may not hold in javascript because it only supports 52 significant binary digits. Whereas other languages usually support 64 significant binary digits.

++ yes. for those not aware, all numbers in javascript are 64bit floats.

that said, you could still write your own bigint class if you need precision beyond that.

They're 64bit floats, but you get 52 bits of integer precision... You're as likely to hit issues as you are with a 32bit int.. the big difference is you need to use Math.round() if you want to multiply/divide in order to get to a whole number again.. Even with a 64-bit integer, you can suffer from overflow, it's only a matter of where.. and even with 32bit environments there have been work arounds for larger numbers/precision.. with JS there are bignum libraries for this.

I don't need "an integer bigger than 52 bits". I need a way to represent (fixed-precision) decimals exactly, and do arithmetic with them, preferably without performance being too terrible or the code looking too horrible. And I'd like it to be a standard implementation, or conform to a standard interface, so that a library ecosystem can build up with support for this type.

Reply on news.ycombinator.com