CS2 Discussion: Features: integer cast/truncation operator(s)

[Inve1951]

I'm following your progress in this project and want to throw in another topic:

Using Math.floor() on negative numbers gives non-straight-forward results.

For example right now -5 // 3 compiles to Math.floor(-5 / 3) which results in -2 when -1 would be the result of proper "integer division".

I came across this stackoverflow question which displays some nice alterantives which even seem to perform better.

Keep up that good work of yours. 👍

[GeoffreyBooth]

@Inve1951 what would be your preference for what // should compile to?

[Inve1951]

I think the most elegant version is compiling a // b to (a / b)|0.

It seems ES6 got Math.trunc() but even with all major browsers supporting it I'd rather have (a / b)|0.

Switching //'s behavior is still a breaking change.

@GeoffreyBooth what are your thoughts on this topic?

[GeoffreyBooth]

I’ve never used that operator so I have no thoughts 😄

In #36 we’re discussing a breaking-change version of CoffeeScript that outputs ESNext, so Math.trunc would be an option. Can you explain the pros and cons of that versus (a / b)|0?

[Inve1951]

// is to be considered broken as is.

(a / b)|0 is a really slick fix and should definitely go into 1.11.0

What variant you put in 2.0.0 is fully up to you guys.

• However IE and mobile browsers seem to lack Math.trunc() support and babel doesn't transpile it.
• Also (a / b)|0 is 8 bytes shorter than Math.trunc(a / b) 😜

[GeoffreyBooth]

This sounds like a bugfix for //. Do you mind opening an issue (or even better, a pull request) on the main coffeescript repo?

You’ll need to explain what exactly (a / b)|0 does, and why it’s better than the current implementation. I’m not sure it’s a breaking change if the current behavior is incorrect, but you’ll need to explain why please 😄

[lydell]

I have used // a few times, but never with negative numbers, so I’ve never really thought about how that should work.

Just as a note: Python seems to do the same thing as CoffeeScript here:

$ python3 -c 'print(-5 // 3)'
-2

Might be worth reading through jashkenas/coffeescript#2887 (and the issues linked to from there) to see if this has been discussed before.

[Inve1951]

Just ran a speed test on both in chrome:

var t, i, dump;

t = Date.now();
for(i=0;i<10000000;++i) {
    dump = Math.trunc(Math.sqrt(i));
}
console.log( "Math.trunc: " + (Date.now()-t) );

t = Date.now();
for(i=0;i<10000000;++i) {
    dump = (Math.sqrt(i)|0);
}
console.log( "|0: " + (Date.now()-t) );

Output:

Math.trunc: 536
|0: 393

[lydell]

I don’t think it’s worth discussing performance before the semantics are worked out.

[alangpierce]

I don't think this is obviously a bug. Floor division and truncation division are both valid operations, and different languages make different decisions about what to use by default.

In Python, Guido intentionally chose the floor behavior. Here's a post explaining why:
http://python-history.blogspot.com/2010/08/why-pythons-integer-division-floors.html

Floor division and mod that returns a non-negative value (%% in CoffeeScript) are mathematically nicer, and I generally prefer them. I've been bitten a few times in C++ because of code breaking when given negative numbers, which wouldn't have happened with the more mathematically pure operators.

[Inve1951]

Sorta coming from C there which makes me expect dividing integers simply not resulting in floating point numbers. The float result (if there were one) is truncated at the decimal point (towards zero).
Same thing happens when casting floats to ints.

Python seems to do the same thing as CoffeeScript

I'd also blame python for that behavior.

[Inve1951]

As mentioned in a comment from @alangpierce's link this doesn't work: -5//3 * -1 == -1 * -5//3 the way // is implemented.

But I see now that there is a different way to think of "integer division".
My straight-forward interpretation was that it treats the expression like C does when doing a division with integers since CS's normal division operator / treats the operands as floats no matter what.

I still find the implemented behavior really odd.
If I'd want the result to be rounded down I'd intentionally use Math.floor()

Edit:
Just noticed that // is called the "floor division operator" in it's PR but is called the "integer division operator" at coffeescript.org.
With it's current implementation, calling it "floor division" in the docs would make it less missleading.

To me it seems that both implementations are reasonable and I'm clearly in favor of truncation towards zero since there is no int cast in js. (obviously one could just write a function _int = (x) -> x | 0 but one could also just use Math.floor() as desired)

Since it's not a bug please treat this as a proposal for changing the implementation. That's quite brazen, I know...

[GeoffreyBooth]

I think renaming it to ”floor division operator” in the docs is reasonable.

I’m less convinced that we should change the behavior of an operator when the current implementation is reasonable and might be preferred by people. Perhaps rather than changing //, a new operator should be created?