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 -- 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.
