News for hackers. Stuff that matters.
Re:Node.js and the new web front-end by ricardobeat on Monday October 07, 2013 @05:47PM (#6511513)
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.

Re:Node.js and the new web front-end by adamors on Monday October 07, 2013 @06:52PM (#6511866)
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.
Re:Node.js and the new web front-end by troyk on Monday October 07, 2013 @07:29PM (#6512032)
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)
Re:Node.js and the new web front-end by tracker1 on Monday October 07, 2013 @09:11PM (#6512388)
Okay, aside from some scientific functions, what do you really need from an integer that 52bits isn't enough for?
Re:Node.js and the new web front-end by ricardobeat on Monday October 07, 2013 @09:46PM (#6512508)
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.
Re:Node.js and the new web front-end by hrjet on Tuesday October 08, 2013 @08:36AM (#6514386)
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)
Re:Node.js and the new web front-end by ricardobeat on Tuesday October 08, 2013 @09:44AM (#6514787)
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.
Re:Node.js and the new web front-end by hrjet on Wednesday October 09, 2013 @02:42AM (#6519749)
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.
Re:Node.js and the new web front-end by lmm on Tuesday October 08, 2013 @09:49AM (#6514833)
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.
Re:Node.js and the new web front-end by novaleaf on Monday October 07, 2013 @10:10PM (#6512595)
++ 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.

Re:Node.js and the new web front-end by tracker1 on Wednesday October 09, 2013 @03:21AM (#6519839)
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.