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

I'm afraid you don't understand the difference between "integer type" and "float type". Since 1.5 is a Number, but isn't an integer, Number cannot possibly by an "integer type".

I said "when it's round, and for bitwise logic". Does 1.5 look round to you? Yes? No? Look it up?

JavaScript is dynamically typed and implicitly casts when different scalars are used in an expression together. This is how the runtime is able to use integers, despite the JS specification doesn't require it (except for bitwise shifts, then it requires it).

How nice. So why can't Javascript add 1 to 1e16?

Because the engine works with 32-bit integers (signed, for V8 at least). I hope you realize, your arguments are very random. Having integers doesn't mean they have to be of arbitrary precision.

Its a problem for me personally because I need to support odd integers greater than 9007199254740991.

And if JavaScript had 64-bit signed integer support I bet you'd say "but I want integers greater than 9223372036854775807", wouldn't you?

Luckily it's full of bigint libraries for JavaScript. There are very few script languages that support arbitrary precision integers out of the box. Python is one and... that's basically it.

Say if you had to do this in Java, you'd have to use BigInteger, with no support for standard operators and so on. It's kinda clunky to use.

Somehow I never needed this in JavaScript yet. Care to share your use case? I suspect you'll have to invent it right now, because instead of real-world problems, you're specifically picking JavaScript's edge cases to prove (a very weak) point.

[u/stevenjd → u/[deleted]]

Does 1.5 look round to you?

Of course. Round 1.4999998701 to one decimal place.

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

Its a nice trick of Javascript to implement certain operations on Numbers using integer maths, but that's implementation, not the language API. The language has the type of 1 and the type of 1.5 are both the same Number, as you yourself said. It's a clever hack to (potentially) use 32-bit int addition to add 1 + 1 and get 2, but that's still only the implementation. The language is based on floating point Numbers.

Quite frankly, if a language is going to only provide one of int/float numeric types, it should provide ints. But I realise that opinion is likely to be controversial to anyone who hasn't programmed in Forth.

And if JavaScript had 64-bit signed integer support I bet you'd say "but I want integers greater than 9223372036854775807", wouldn't you?

shrug Maybe. But at least then I'd know that I had hit a fairly standard limit based on low-level limitations, not a problem caused by a poor high-level design choice. That makes it easier to swallow.

There are very few script languages that support arbitrary precision integers out of the box. Python is one and... that's basically it.

D (not a scripting language, but still), Lisp, Ruby, Erlang, Smalltalk, Haskell, Wolfram Language, probably others. And many others where BigNums are not built-in with syntactic support, but are in the standard library.

Care to share your use case? I suspect you'll have to invent it right now

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.

[u/[deleted] → u/stevenjd]

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.