Re: [sage-devel] patchbot arando failure

The upgrade to setuptools 12.2 triggered that. It was occasional before but now systematic. We already have a ticket positively reviewed for it. http://trac.sagemath.org/ticket/17875 François > On 5/03/2015, at 20:44, Ralf Stephan wrote: > > Hello, > > many thanks to the persons running patchb

[sage-devel] patchbot arando failure

Hello, many thanks to the persons running patchbots. However they certainly want to know that the patchbot at 6.6.beta2 Ubuntu/14.04/i686/3.13.0-40-generic/arando suffers from this: doctest:122

[sage-devel] Re: Proposal: make _cmp_c_impl() override __cmp__()

Would it also be possible to check if (python) rich comparisons are implemented and use those first before falling back to _cmp_, or having the default try to call the rich comparisons? I remember implementing the rich comparisons but then I ran cmp(x, y) with the instances of this class x,y

[sage-devel] Re: Proposal: make _cmp_c_impl() override __cmp__()

On Wednesday, March 4, 2015 at 5:47:59 AM UTC-8, Simon King wrote: > > But wouldn't we still have the complication for Cython classes, that one > has to actually *copy* code from sage.structure.element.Element? If I > recall correctly, this is needed in order to create hashable elements > (if yo

Re: [sage-devel] Proposal: make _cmp_c_impl() override __cmp__()

On Wed, Mar 04, 2015 at 05:17:02AM -0800, Jean-Pierre Flori wrote: >The few times I played with comparison functions, I found what we have >quite confusing, especially the discrpancy between Python and Cython >classes, so any simplification would be welcomed. >And if it also eases t

[sage-devel] Re: Proposal: make _cmp_c_impl() override __cmp__()

Simon King wrote: > According to the documentation, one is allowed to treat __richcmp__ > separate from __cmp__. Hence, it is legal to have separate behaviour > for <,<= etc and for cmp(,). > > Is that possibility used in Sage somewhere? Yes, see src/sage/rings/real_mpfi.pyx. -- Marc -- You r

Re: [sage-devel] Re: Proposal: make _cmp_c_impl() override __cmp__()

On 2015-03-04 16:34, Simon King wrote: one should perhaps rather support _richcmp_ and _cmp_, where the default __richcmp__ tries to call _richcmp_ after coercion and falls back to _cmp_ if it fails. That's exactly how things are currently done (except there is also some _richcmp_c_impl and _cmp

[sage-devel] Re: Proposal: make _cmp_c_impl() override __cmp__()

Hi Jeroen, On 2015-03-04, Jeroen Demeyer wrote: > Anyway, continuing the above example: > sage: E += E > we got coercion > > The fact that __iadd__ calls _add_ would be analogous to __richcmp__ > calling _cmp_ instead of __cmp__. And that is what I want to do. According to the documentation, on

Re: [sage-devel] Error: FLINT failed to pass on Opensuse 13.1

Doh! I just saw that your patch was for Makefile.in and not Makefile. of course!!! ;-) That explains de problem with the distclean. Rebuilding. and will report back. Carl -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe fr

Re: [sage-devel] Error: FLINT failed to pass on Opensuse 13.1

It didn't work. But then again, I did a "make distclean", so the Makefile probably got recreated. I have to familiarise myself with the Makefiles, directories, etc, before I can find what would be the fix. Rebuilding and running the tests takes too long. I read the installation documentation and

Re: [sage-devel] Re: Proposal: make _cmp_c_impl() override __cmp__()

On 2015-03-04 15:18, Simon King wrote: No. If a Python class has just *some* __add__, then the coercion framework is out of the game. It must be sage.structure.element.ModuleElement.__add__, or it won't work. Example: sage: from sage.structure.element import ModuleElement sage: class MyClass

[sage-devel] Re: Proposal: make _cmp_c_impl() override __cmp__()

Hi Jeroen, On 2015-03-04, Jeroen Demeyer wrote: > On 2015-03-04 14:47, Simon King wrote: >> I don't agree with that description. If a Python class has both __cmp__ >> and _cmp_ (or both __add__ and _add_), then of course __cmp__ (resp. >> __add__) are called. > > If a Python class has __add__ and

Re: [sage-devel] Re: Proposal: make _cmp_c_impl() override __cmp__()

On 2015-03-04 14:47, Simon King wrote: I don't agree with that description. If a Python class has both __cmp__ and _cmp_ (or both __add__ and _add_), then of course __cmp__ (resp. __add__) are called. If a Python class has __add__ and _add_, then the *coercion framework* will use _add_, not __

[sage-devel] Re: Proposal: make _cmp_c_impl() override __cmp__()

Hi Jeroen, On 2015-03-04, Jeroen Demeyer wrote: > On 2015-03-04 14:14, Simon King wrote: >> "Priority" in the sense of "if you want to implement comparison for >> elements, then implement "_cmp_" rather than "__cmp__"? > Yes. In other words: if a Python class has both __cmp__ and _cmp_, the > co

Re: [sage-devel] Re: Proposal: make _cmp_c_impl() override __cmp__()

On 2015-03-04 14:14, Simon King wrote: "Priority" in the sense of "if you want to implement comparison for elements, then implement "_cmp_" rather than "__cmp__"? Yes. In other words: if a Python class has both __cmp__ and _cmp_, the coercion framework should call _cmp_ (which will default to __

Re: [sage-devel] Proposal: make _cmp_c_impl() override __cmp__()

The few times I played with comparison functions, I found what we have quite confusing, especially the discrpancy between Python and Cython classes, so any simplification would be welcomed. And if it also eases the transition towards Python 3 that would be great. -- You received this message b

[sage-devel] Re: Proposal: make _cmp_c_impl() override __cmp__()

Hi Jeroen, On 2015-03-04, Jeroen Demeyer wrote: > In #17890, I want to rename _cmp_c_impl to _cmp_ and make it cpdef (like > the other arithmetic functions such as _add_). Then I also would like to > reverse the convention and make _cmp_ take priority over __cmp__. "Priority" in the sense of "

Re: [sage-devel] Proposal: make _cmp_c_impl() override __cmp__()

For the last two in your list it is quite possible that I wrote the code and did not understand what I was doing at the time, just happy that what I wrote worked. (Particularly true of the WeierstrassIsomorphism code which I wrote in 2007, the very first Sage/python code I ever did write). So ple

[sage-devel] Proposal: make _cmp_c_impl() override __cmp__()

Hello, I am trying to simplify and optimize the "comparison" part of the coercion framework at #17890. There is one convention we currently have in Sage which is posing an obstacle: if a Python class (not a Cython cdef class) inheriting from Element defines both _cmp_c_impl and __cmp__, then

Re: [sage-devel] Re: Addition of zero in the coercion model

On 4 March 2015 at 08:11, Nicolas M. Thiery wrote: > On Sat, Feb 21, 2015 at 08:47:40PM +, Simon King wrote: >> > How should I fix this? >> >> By providing a starting point for the summation: >> sage: sum([myElement]).parent() >> ModularFormsRing(n=3) over Integer Ring >> sage: myElement

Re: [sage-devel] Re: Addition of zero in the coercion model

On Sat, Feb 21, 2015 at 08:47:40PM +, Simon King wrote: > > How should I fix this? > > By providing a starting point for the summation: > sage: sum([myElement]).parent() > ModularFormsRing(n=3) over Integer Ring > sage: myElement.parent() > ModularForms(n=3, k=4, ep=1) over Integer Rin

Re: [sage-devel] Re: Failure in doctesting framework when running Sage in docker

Hi Volker! On Tue, Mar 03, 2015 at 02:23:47PM -0800, Volker Braun wrote: >I'm guessing you are hitting resource limits, e.g. compare "ipcs -l" >inside and outside of the docker container. Thanks for the tip! There does not seem to be a major difference though; just a few less que