Closed jpivarski closed 6 months ago
@jpivarski Thanks for filing this issue. If I am reading the specification correctly, the specification does, in fact, indicate what should happen in the event of ties. Namely, in the special cases section for floating-point operands, the specification states:
If two integers are equally close to
x_i
, the result is the even integer closest tox_i
.
Hence, for 1.5
and 2.5
, in both cases, the answer would be 2.0
.
This behavior matches NumPy:
In [3]: import numpy as np
In [4]: np.round(1.5)
Out[4]: 2.0
In [5]: np.round(2.5)
Out[5]: 2.0
Ah! I missed that under "special cases."
My request here was to get a line like that added, but now I see that it's already there, so I close the issue. Thanks for pointing it out!
Here is the current draft of the
round
function:https://github.com/data-apis/array-api/blob/5c2423a96c9fd5113e405df88f2422f14cd978b9/src/array_api_stubs/_draft/elementwise_functions.py#L2191-L2231
It doesn't say whether numbers like
1.5
and2.5
should be rounded to1.0
and2.0
or2.0
and3.0
. Sometimes, the rule is to always round up (toward positive infinity? away from zero?), but that can bias distributions to higher values. Sometimes, the rule depends on the evenness or oddness of the whole part, which would eliminate this bias if the distribution is not correlated with evenness/oddness (e.g. if it's broad/smooth on the scale of 1 unit).In particular, NumPy uses the evenness/oddness rule, in both its traditional API and its experimental implementation of the Array API:
In my opinion,
round
should be specified to do what NumPy does: use the evenness/oddness rule. This could be a "note" box, similar to the box describing what happens for complex numbers.