Le 05/03/2019 à 17:32, E. Madison Bray a écrit :
On Sun, Mar 3, 2019 at 2:12 PM Frédéric Chapoton <fchapot...@gmail.com> wrote:
Hello everybody.
In sage 8.7.b6 built with python3, there are now 464 failing doctests, in a
total of 137 files. Among these files, 55 have just one failing doctest. The
worst file is now 'src/sage/matroids/matroid.pyx' with 22 doctests failed.
To make further progress, one thing that we must handle is the "round" problem.
See the discussion in https://trac.sagemath.org/ticket/25827 and below.
To summarize:
- the behaviour of python's own "round" changed between py2 and py3. In
python3, it calls the method .__round__
- our rings mostly implement a method .round
- round can mean two distinct things : return the closest integer like
round(pi)=3 or return an approximation like round(pi,4)=3.1416
- the rounding to an integer can be ambiguous for half integers, and there are
competing norms to decide what to do (up, down, away from zero, according to
parity)
I would appreciate if somebody would stand up and take the job of caring for
round. This may fix a big bunch of doctests.
My previous naive tentatives have not been received with any enthusiasm. I
would rather not go on and transmit the task to people knowing the matter.
Frédéric
P.S. Python3 progress is tracked at https://trac.sagemath.org/ticket/26212
To add a point about the "round" issue that I think is too often
neglected, and to me is the biggest open question as to what to do
with it:
Sage implements its own "round" function which it inserts into the
global namespace, replacing Python's built-in round() [1]. It seems
to me it exists primarily for two reasons: To always return a
RealDoubleElement (instead of Python <float>), and to allow calling
arbitrary types' .round() method if it has one (since the ability to
provide a custom __round__ method for arbitrary classes did not exist
in Python 2).
ISTM these use-cases can be mostly satisfied, at least by Sage's
custom types, by using the Python 3 built-in round() and providing the
appropriate __round__() methods (which we need to implement anyways
for those types to work properly with the round() built-in).
So the question to me is whether to keep Sage's round( ) replacement
at all on Python 3. One argument in favor of keeping it is the
additional documentation. But it still needs to be modified to call
types' __round__ methods when they exist (this could even be supported
on Python 2).
The next tricky question then, is what should be the relationship
between a type's .__round__() method and its exiting .round() method?
Should elem.round() be equivalent to elem.__round__(n=0)? Or should
elem.__round__(n=0) be equivalent to elem.round() (with
elem.__round__(n!=0) implemented some other way?)
I think these questions can be answered, but I don't know if there's
any deep reasoning behind the current behavior such that it should be
kept. In particular, in #25827 I proposed that maybe
RealNumber.__round__() should take into consideration the rounding
mode of its parent field. But it's not clear how that should then
relate to the RealNumber.round() method which does not, nor is it
clear what the rationale is behind ignoring it.
[1]
https://gitlab.com/sagemath/sage/blob/master/src/sage/misc/functional.py#L1506
[2] https://trac.sagemath.org/ticket/25827
Just to give some elements of comparison. Following the specifications
of the standard math library in C what MPFR [3] does is that
- "floor", "ceil", "round", "trunc" are the standard rounding
functions to some integer in their mathematical definition (ie
independently of the rounding mode)
It also implements an extra rounding operation "rint" that is
rounding dependnt, more precisely
floor = rint with RNDD (down)
ceil = rint with RNDU (up)
round = rint with RNDN (nearest)
trunc = rint with RNDZ (toward zero)
I am fine having extra argument to floor, ceil, round, trunc in
sage to ask for bits after the decimal point. But I would keep
carefully the above specifications.
[3]
https://www.mpfr.org/mpfr-current/mpfr.html#Integer-and-Remainder-Related-Functions
Vincent
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
