Robert,
As described in
http://trac.sagemath.org/sage_trac/ticaket/1044
in sage-2.8.10 this leads to a segfault:
sage: K.<a> = NumberField(x^2 - 5)
sage: B = K.maximal_order().basis();
sage: -1*B[1]
BOOM!
As does
sage: B[1]*-1
By putting some code to rain an exception in the
number_field_quadratic_element.pyx
file I was able to track this down to a call made by the init method of
cdef class LeftModuleAction(Action):
in coerce.pyx. In particular, you have this code:
# TODO: detect this better
# if this is bad it will raise a type error in the subsequent lines,
which we propagate
cdef RingElement g = G._an_element()
cdef ModuleElement a = S._an_element()
res = self._call_c(g, a)
And _call_c is:
cdef Element _call_c_impl(self, Element g, Element a):
if self.connecting is not None:
g = self.connecting._call_c(g)
if self.extended_base is not None:
a = self.extended_base(a)
return _rmul_c(<ModuleElement>a, <RingElement>g) # a * g
That line involving _rmul_c seems to me to be just totally wrong. The problem
is
that _rmul_c *assumes* that g is an element of the base ring of the
parent of a. However, I think you're calling it as some sort of test and
hoping that a TypeError will be raised. Unfortunately, we get a
segmentation fault.
So could you clarify what you think _rmul_c does compared to what I
thought it was supposed to do when I wrote it? I only thought
of external code calling _rmultiply_by_scalar. Indeed, in the above
case if you replace the _rmul_c line by
return (<ModuleElement>a)._rmultiply_by_scalar(<RingElement>g)
then this seems to fix all the problems (but is maybe slower).
Note also that there are similar issues with _lmul_c in coerce.pyx, and
*shudder* with _ilmul_c, where you didn't implement an analogue of
_rmultiply_by_scalar yet.
The easy fixes I can think of are:
1. Rewrite _call_c_impl to call safe methods, i.e., _rmultiply_by_scalar,
_lmultiply_by_scalar, and _ilmultiply_by_scalar (which will have to be
written). What are the performance impacts?
-- OR --
2. Change the semantics of _rmul_c, _lmul_c, and _ilmul_c, etc. so that
they must raise a TypeError if the type of the scalar isn't in the base
ring. This will slow them down, of course, but I think it's what you
assumed already in writing coerce.pyx, perhaps all over the place.
If this is the case, it means
(a) looking at the code for probably about 30-40 functions, and
in many of those cases making changes just like the one carl
witty attached to trac #1044.
(b) documenting that _rmul_c_impl, _lmul_c_impl, etc., must raise
a TypeError if the types aren't right (i.e, they can't segfault).
I think 2 might be more in line with what you meant when writing coerce.pyx.
However it goes completely antithetical to how _mul_c_impl, _add_c_impl,
etc., are defined -- they are supposed to get to assume that the types
are right, so _rmul_c_impl should also have that luxury. Thus it makes
the most sense to do 1. But what impact will that have on coerce.pyx?
For example, _call_c_impl gets called every single time I write
-1*B[1]
-- William
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
