Modify rounding method to use banker’s rounding

[cxzhong]

Update round method to use round-to-even for tie cases, aligning with Python 3 behavior and IEEE 754 default rounding.
Fix #41056

📝 Checklist

• The title is concise and informative.
• The description explains in detail what this PR is about.
• I have linked a relevant issue or discussion.
• I have created tests covering the changes.
• I have updated the documentation and checked the documentation preview.

⌛ Dependencies

[cxzhong]

Before that, such interesting thing raise:

sage: (5/2).round()
2
sage: (-5/2).round()
-2
sage: (2.5).round()
3
sage: (-2.5).round()
-3

I think it is definitely a bug we need to fix

[cxzhong]

Seems some doctests affects

[dimpase]

this is a major change, potentially breaking other people's code.

I'd rather have an interface to change the rounding mode, say during the creation of the field.

If we want to make this rounding default, it must come via the usual depreciation route.

[cxzhong]

this is a major change, potentially breaking other people's code.

I'd rather have an interface to change the rounding mode, say during the creation of the field.

If we want to make this rounding default, it must come via the usual depreciation route.

Yes. I know, we may merge it in 10.9 and we can take a deprecation notice?

[cxzhong]

this is a major change, potentially breaking other people's code.

I'd rather have an interface to change the rounding mode, say during the creation of the field.

If we want to make this rounding default, it must come via the usual depreciation route.

And we can create a interface to let people to choose the round way they need.

[nbruin]

I recommend reading the documentation of RIF().round. It explains this routine is probably not what you want. Perhaps you mean RIF(2.5,3.5).unique_round(). That routine fails and if you read the docs you see why: It tries to apply round to each element in the interval and only returns a value if all of those agree. Similar semantics apply to round. Remember that interval arithmetic as implemented in MPFI tries to return values that contain all answers that can arise from numbers in the input intervals. So "banker's rounding" on RIF(2.5,3.5) should return RIF(2,4) . The current code ends up returning RIF(3,4) because it rounds up/away from zero

In practice, the edge cases for interval bounds are never significant. That's with the FP rounding internally is down for lower and up for upper bounds. You can do RIF(2.5,3.5).floor() or RIF(2.5,3.5).trunc() for other results. But note that you're getting an interval back.

[github-actions]

Documentation preview for this PR (built with commit ca533b0; changes) is ready! 🎉
This preview will update shortly after each push to this PR.