On Tue, Mar 5, 2019 at 7:27 PM Vincent Delecroix <20100.delecr...@gmail.com> wrote: > > 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 would also like to add that I don't think "floor", "ceil", and "trunc" are necessarily relevant to this discussion. I know that they are very similar, related operations, but there isn't any question about what to do about them in Sage. There's no question about them, because they are not "special" functions in any way in Python--they are not in the global namespace, and are only available (in plain Python) through the `math` module, where I believe they are simply thin wrappers around the C library math functions. The questioning here is focused specifically on round() because Python has a round() function that is historically quite *different* from the others in that it supports this additional functionality of rounding to some decimal place. Further, as of Python 3, it allows custom types to implement how they are handled when passed to this round() function by implementing a __round__ special method. If we want to be able to pass objects of our own custom types to the Python round() built-in this method needs to be implemented. That's why round() is specifically being focused on here. I think I summarized these questions in my previous message: 1. What to do with Sage's built-in round() function that replaces the Python round in a way that is compatible with Python 3 2. How .round() methods should be implemented on Sage-specific types and how it should relate to .__round__(), which should also support this additional decimal rounding functionality. -- 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.
