How should rounding between Integer and Number be specified?

[littledan]

I'll start the spec with deliberately vague text since I don't know the answer. Should it always round towards 0? If that were done, then are there cases where there would be issues with round-tripping? If there are such issues, do we care?

When rounding from a Number to a Integer, should lower, insignificant digits be "accurate" or round towards 0-digits, as we see coming up in the existing specification in tc39/ecma402#128 ?

[littledan]

According to Waldemar Horwat,

When converting a Number to an Integer, existing tradition is to drop the fraction, truncating towards zero. That's what C and C++ do when converting a floating-point number to an integral type, and that's I would expect.

If the Number is NaN or one of the infinities, throw?

For the reverse conversion (Integer to Number), do the standard IEEE round-to-nearest, breaking ties to even. That's what C and C++ are specified to do.

TODO(littledan): Write this up in spec text.

[kgryte]

For reference, in Python,

>>> int(3.14)
3

>>> int(-3.14)
-3

Hence, Python rounds toward 0.

In Julia,

julia> convert( Int32, 3.14 )
ERROR: InexactError()
 in convert at int.jl:209

julia> convert( Int32, floor( 3.14 ) )
3

Julia requires you to be explicit in how you want to round.

In terms of which approach is better, I see pros and cons for each. Julia has no default behavior, which means that no one has to guess what the default behavior is. However, this runs contrary to current precedent in JavaScript where the default behavior when converting a number to an implicit int32 is to round toward 0 by default.

> 3.14|0
3

> -3.14|0
-3

Of course, having a default behavior is not mutually exclusive with explicitly specifying rounding.

In this case, I side with being consistent with current int32 behavior.

For the reverse conversion, not sure how a rounding mode is applicable here. IEEE 754 rounding rules, unless I am mistaken, are applied when rounding an IEEE 754 float to an integer, not the other way around.

[littledan]

For the Integer to Number rounding, there's actually already a section in the spec that defines this, in #sec-ecmascript-language-types-number-type . I'll reference that for this direction, as a start.

For Number to Integer, the place where this comes up is in the Number constructor, which this specification makes into a cast operator. Unfortunately, this API doesn't give a clean place for a parameter to specify direction, but we could throw an exception on Numbers which are not already exactly expressible in integers, and expect people to call Math.ceil, Math.floor. What do you think?

[kgryte]

My stance is similar Waldemar Horwat: round toward zero (i.e., mirror Python and current JS behavior).