Re: [sage-devel] patchbot arando failure

[Francois Bissey]

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 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:1224: UserWarning: /home/patchbot/.sage//.python-eggs is writable 
> by group/others and vulnerable to attack when used with 
> get_resource_filename. Consider a more secure location (set with 
> .set_extraction_path or the PYTHON_EGG_CACHE environment variable).
> 
> and so is uselessly wasting its CPU.
> 
> Regards,
> 
> -- 
> 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 http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] patchbot arando failure

[Ralf Stephan]

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:1224: UserWarning: /home/patchbot/.sage//.python-eggs is writable 
by group/others and vulnerable to attack when used with 
get_resource_filename. Consider a more secure location (set with 
.set_extraction_path or the PYTHON_EGG_CACHE environment variable).

and so is uselessly wasting its CPU.

Regards,

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Travis Scrimshaw]

   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 
and getting an error thrown back by Sage since Element implemented __cmp__ 
which just called the unimplemented _cmp_ and raised an error.

Best,
Travis

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Nils Bruin]

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 you override __hash__ then you must also override __cmp__). That 
> said, this could be resolved in the same way: We should *never* override 
> sage.structure.element.Element.__hash__. Instead, the generic __hash__ 
> method should call _hash_. 
>

There's a penalty to that. This _hash_ method would be an ordinary method 
lookup and hence MUCH slower than the special __hash__, which is lightning 
fast, because it's a slot method that gets special cased a lot in many 
situations as well.
For _cmp_ we're getting some benefit because the coercion framework needs 
to hook into it, but for __hash__ this doesn't hold.

If someone overrides __hash__ (which they should do because the default 
hash sucks badly) and wants to still inherit the original __richcmp__ (it 
makes little sense to rely on __cmp__ being a special method anymore) then 
they should do just that, rather than force the introduction of another 
hook.

On cython level, it's not unprecedented to hack your way to setting the 
appropriate slot methods if the standards provided by PyType_Ready (and 
cython) are not to your liking:

(from sage/structure/coerce_dict):

(TripleDict).tp_traverse = &TripleDict_traverse
(TripleDict).tp_clear = &TripleDict_clear

The only CPython C-API non-compliant bit about this is that we';re making 
the modification *after* PyType_Ready has been called on the type 
structure, and that is just because cython doesn't provide a hook to insert 
your own code before that.

For a python type exactly the same trick would work, because it would 
require changing the same slot.

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Nicolas M. Thiery]

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 the transition towards Python 3 that would be
>great.

+1!!!

Thanks for your work in this direction.

I would need to double check each of them, but most likely the custom
cmp methods in the sage.combinat classes should be straightforward and
safe to refactor.

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" 
http://Nicolas.Thiery.name/

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Marc Mezzarobba]

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 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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Jeroen Demeyer]

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_c_impl involved) and I plan to keep this.


--
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Simon King]

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, 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? Do people think that it is
good to *have* that possibility? If the answer to one of these questions
is "yes", then 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.

Best regards,
Simon


-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Carl Robitaille]

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 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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Carl Robitaille]

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 
I'm trying to limit the number of things getting tested and tested.

=
tar xvfz sage-6.5.tar.gz
cd sage-6.5
export MAKE="make 
-j8" 
export SAGE_CHECK_PACKAGES="flint"
export SAGE_KEEP_BUILT_SPKGS="yes"
make build
=

Once it's built, I'll have a closer look at the error and report back.

Carl

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Jeroen Demeyer]

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(ModuleElement):
  : def __add__(self, other):
  : print "no coercion is involved"
  : return self
  : def _add_(self, other):
  : print "we got coercion"
  : return self
  :
  sage: E = MyClass(ZZ)
  sage: E+E
  no coercion is involved
  Generic element of a structure


I admit I got confused myself.

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.


--
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Simon King]

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 _add_, then the *coercion framework* 
> will use _add_, not __add__.

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(ModuleElement):
 : def __add__(self, other):
 : print "no coercion is involved"
 : return self
 : def _add_(self, other):
 : print "we got coercion"
 : return self
 : 
 sage: E = MyClass(ZZ)
 sage: E+E
 no coercion is involved
 Generic element of a structure
 sage: E+1
 no coercion is involved
 Generic element of a structure
 sage: class MyClass(ModuleElement):
 :def _add_(self, other):
 :print "we got coercion"
 :return self
 : 
 sage: E = MyClass(ZZ)
 sage: E+E
 we got coercion
 Generic element of a structure
 sage: E+1
 we got coercion
 Generic element of a structure

Unless you mean something else when you say coercion framework.

Best regards,
Simon


-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Jeroen Demeyer]

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 __add__. When doing a + b, Python will call 
a.__add__(b) which the coercion framework will translate to an _add_ 
call on the coerced arguments. My proposal is to do the same for __cmp__.


--
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Simon King]

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 
> coercion framework should call _cmp_ (which will default to __cmp__).
>
> This would make _cmp_ analogous to other operators like _add_. The only 
> difference is that __cmp__ doesn't inherit if __hash__ is defined, so 
> you might need to define both __cmp__ and _cmp_.

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.

What *should* be the case (and I guess it is what you mean): If one
implements comparison for an element in Python, then one must not
override sage.structure.element.Element.__cmp__. Instead, one should
implement _cmp_ (which ought to be a cpdef method).

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 you override __hash__ then you must also override __cmp__). That
said, this could be resolved in the same way: We should *never* override
sage.structure.element.Element.__hash__. Instead, the generic __hash__
method should call _hash_.

By consequence, it would not be needed any longer to copy the generic
code, since neither __hash__ nor __cmp__ would be overridden (only
_hash_ and _cmp_ are).

Best regards,
Simon

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Jeroen Demeyer]

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


This would make _cmp_ analogous to other operators like _add_. The only 
difference is that __cmp__ doesn't inherit if __hash__ is defined, so 
you might need to define both __cmp__ and _cmp_.


--
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Jean-Pierre Flori]

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 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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Simon King]

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 "if you want to implement comparison for
elements, then implement "_cmp_" rather than "__cmp__"? Surely you do
not mean that Sage will call _cmp_ even when the programmer mistakenly
wrote "__cmp__", overriding what is inherited from the base classes in
sage.structure.elements?

Best regards,
Simon

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[John Cremona]

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 please do what needs to be
done, and if it still works (and is no slower) I will certailny not
complain!

John

On 4 March 2015 at 10:31, Jeroen Demeyer  wrote:
> 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 __cmp__ should be called.
> This is particularly annoying because testing for __cmp__ takes a lot more
> time than testing for _cmp_c_impl.
>
> 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__. Of course, for
> cmp() to work, both __cmp__ and _cmp_ will need to be defined (but this is
> already true for cdef classes). Any comments or objections?
>
>
> Note: below is the list of affected classes, where currently both
> _cmp_c_impl and __cmp__ are defined:
>
>  'sage.combinat.root_system.weyl_group.ClassicalWeylSubgroup_with_category.element_class'>
>  'sage.combinat.root_system.weyl_group.WeylGroup_gens_with_category.element_class'>
>  'sage.combinat.set_partition.SetPartitions_all_with_category.element_class'>
>  'sage.combinat.set_partition.SetPartitions_setn_with_category.element_class'>
>  'sage.combinat.set_partition.SetPartitions_setparts_with_category.element_class'>
>  'sage.combinat.set_partition.SetPartitions_set_with_category.element_class'>
> 
> 
>  'sage.groups.matrix_gps.group_element.FinitelyGeneratedMatrixGroup_gap_with_category.element_class'>
>  'sage.groups.matrix_gps.group_element.LinearMatrixGroup_gap_with_category.element_class'>
>  'sage.groups.matrix_gps.group_element.SymplecticMatrixGroup_gap_with_category.element_class'>
>  'sage.modular.abvar.morphism.EndomorphismSubring_with_category.element_class'>
> 
> 
> 
> 
> 
> 
>  'sage.rings.number_field.morphism.RelativeNumberFieldHomomorphism_from_abs'>
>  'sage.schemes.elliptic_curves.ell_curve_isogeny.EllipticCurveIsogeny'>
>  'sage.schemes.elliptic_curves.weierstrass_morphism.WeierstrassIsomorphism'>
>
> --
> 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 http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Jeroen Demeyer]

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 __cmp__ should be 
called. This is particularly annoying because testing for __cmp__ takes 
a lot more time than testing for _cmp_c_impl.


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__. Of 
course, for cmp() to work, both __cmp__ and _cmp_ will need to be 
defined (but this is already true for cdef classes). Any comments or 
objections?



Note: below is the list of affected classes, where currently both 
_cmp_c_impl and __cmp__ are defined:


'sage.combinat.root_system.weyl_group.ClassicalWeylSubgroup_with_category.element_class'>
'sage.combinat.root_system.weyl_group.WeylGroup_gens_with_category.element_class'>
'sage.combinat.set_partition.SetPartitions_all_with_category.element_class'>
'sage.combinat.set_partition.SetPartitions_setn_with_category.element_class'>
'sage.combinat.set_partition.SetPartitions_setparts_with_category.element_class'>
'sage.combinat.set_partition.SetPartitions_set_with_category.element_class'>



'sage.groups.matrix_gps.group_element.FinitelyGeneratedMatrixGroup_gap_with_category.element_class'>
'sage.groups.matrix_gps.group_element.LinearMatrixGroup_gap_with_category.element_class'>
'sage.groups.matrix_gps.group_element.SymplecticMatrixGroup_gap_with_category.element_class'>
'sage.modular.abvar.morphism.EndomorphismSubring_with_category.element_class'>







'sage.rings.number_field.morphism.RelativeNumberFieldHomomorphism_from_abs'>
'sage.schemes.elliptic_curves.ell_curve_isogeny.EllipticCurveIsogeny'>
'sage.schemes.elliptic_curves.weierstrass_morphism.WeierstrassIsomorphism'>


--
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[John Cremona]

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.parent()
>>   ModularForms(n=3, k=4, ep=1) over Integer Ring
>>   sage: sum([myElement], myElement.parent().zero()).parent()
>>   ModularForms(n=3, k=4, ep=1) over Integer Ring
>
> Alternatively, you can use the form:
>
> parent.sum(elements)
>
> whose role is precisely to use the zero of the parent just when needed
> (that is if the list is empty).

That is a very nice idiom!  I did not know that, but I will use it a
lot from now on.

John

>
> Cheers,
> Nicolas
> --
> Nicolas M. Thiéry "Isil" 
> http://Nicolas.Thiery.name/
>
> --
> 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 http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Nicolas M. Thiery]

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 Ring
>   sage: sum([myElement], myElement.parent().zero()).parent()
>   ModularForms(n=3, k=4, ep=1) over Integer Ring

Alternatively, you can use the form:

parent.sum(elements)

whose role is precisely to use the zero of the parent just when needed
(that is if the list is empty).

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" 
http://Nicolas.Thiery.name/

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Nicolas M. Thiery]

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
queues system wide:

root@sage:~# docker run sagemath/sage ipcs -l  > inside
root@sage:~# ipcs -l > outside
root@sage:~# diff outside inside
1a2,6
> -- Messages Limits 
> max queues system wide = 1285
> max size of message (bytes) = 8192
> default max size of queue (bytes) = 16384
> 
14,18d18
< 
< -- Messages Limits 
< max queues system wide = 1542
< max size of message (bytes) = 8192
< default max size of queue (bytes) = 16384

I would have guessed the test would not be a big resource hog either.

>Afair my image passed doctests on my machine, though that machine
>is still boxed up in my closet right now...

Ok!

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" 
http://Nicolas.Thiery.name/

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.