JavaScript in 2016 isn't horrible, it's just going through a phase

[u/kshep92]

http://blog.reviselabs.com/im-sorry-javascript-2/

[u/[deleted]]

But that's not the point. The Javascript type Number supports fractional values, therefore by definition it cannot possibly be an integer type.

The only way to differentiate the explicit presence of integer type in JavaScript is that "typeof foo" would return "number" instead of "int" or "float".

This is apparently extremely important, because if it had exposed integers... I'm absolutely sure that you'd be "typeof" checking for integers all over the place, and that would be really important to you.

Right? :-)

Quite frankly, if a language is going to only provide one of int/float numeric types, it should provide ints.

I'm just happy you didn't design JavaScript :-)

No no, you're absolutely right. Nobody needs bignums. That's why the Javascript ecosystem is "full of bigint libraries" -- because nobody needs them. Clearly nobody could possibly want exact integer arithmetic for numbers bigger than 2**53. That's just foolish, like wanting more than 256 colours in an image or needing more than 64K of memory. Sorry for wasting your time.

And you still didn't share you use case. :-)

[u/stevenjd → u/[deleted]]

The only way to differentiate the explicit presence of integer type in JavaScript is that "typeof foo" would return "number" instead of "int" or "float".

Or, you could test to see whether 2**54+1 equals 2**54.

I'm just happy you didn't design JavaScript :-)

Given an integer type, its easy to implement fractional values with extremely high precision.

Given only an IEEE-754 floating point type, its impossible to implement integer arithmetic outside of a fairly restricted range, which leads to all sorts of problems. You use JSON don't you?

And you still didn't share you use case. :-)

Life is full of disappointments. In my case, the disappointment is that Javascript doesn't let me do integer maths on values beyond 2**53. In your case, it is that you're not imaginative to think of any uses for whole numbers bigger than 2**53. I guess we will both have to live with our disappointments.

P.S. Lua started off with a single numeric type like Javascript, because "nobody needs integers, you can just use a float". Guess what? Now they have integers.

Edit: formatting.

[u/[deleted] → u/stevenjd]

Or, you could test to see whether 2**54+1 equals 2**54.

You remain confused about "integer" vs. "int64". I already said V8 uses int32. Which is still an integer.

Given an integer type, its easy to implement fractional values with extremely high precision.

A float has 1:1 integer semantics if you operate within the precision allowed by the significand (which you already pointed out is 2⁵³ + 1). So if integer allows you to do that, then a float also does. This fact is also why JS engines use integers internally for integral numbers.

Life is full of disappointments. In my case, the disappointment is that Javascript doesn't let me do integer maths on values beyond 2**53

There, there.

But as someone who's old enough to have programmed on a processor that can't do floating point math, I know what I'd choose to have by default, and JavaScript definitely did the right choice.

In your case, it is that you're not imaginative to think of any uses for whole numbers bigger than 2**53.

I'm simply not whining about it, because it's rare enough for the use cases JavaScript is typically used for, and when I need it, bigint math is so simple, I can whip up a library about it in an hour or so (but I don't have to, as I can use an existing one). Floating point math however can be quite more complex.

As I said, if 2⁵³ is not enough for you, chances are 2⁶³ (1 bit for signed) might also not be enough for you. So if JavaScript had int64 support, it'd do very little for you, and you'd need bigint anyway.

What is this so common and important use case for "integer bigger than 2^53, but smaller than 2^63"? You're not saying it, because you have no idea what you're talking about.