Fwd: SAGE ignores Ctrl-C?!? Is this a bug or a feature
John Cremona
to sage-support), since he asks a question which should be debated by
developers: see below.
---------- Forwarded message ----------
From: Simon King <simon.k...@nuigalway.ie>
Date: Dec 30, 11:07 am
Subject: SAGE ignores Ctrl-C?!? Is this a bug or a feature
To: sage-support
Hi Alex!
On 30 Dez., 06:37, Alex P <alexvpetr...@gmail.com> wrote:
> Here is the code:
> ----------------------------------------------------------------------
> | Sage Version 4.2.1, Release Date: 2009-11-14 |
> | Type notebook() for the GUI, and license() for information. |
> ----------------------------------------------------------------------
> sage: q = 3
> sage: F.<a> = FiniteField(q)
> sage: P.<T> = PolynomialRing(F)
> sage: PP.<z> = PolynomialRing(P)
[...]
> sage: time (z^3 + T*z)^(3^7)
> ^CException KeyboardInterrupt: KeyboardInterrupt() in
> 'sage.rings.polynomial.polynomial_zmod_flint.get_cparent' ignored
> ^C
> ------------------------------------------------------------
> Unhandled SIGFPE: An unhandled floating point exception occured in
> SAGE.
> This probably occured because a *compiled* component
> of SAGE has a bug in it (typically accessing invalid memory)
> or is not properly wrapped with _sig_on, _sig_off.
> You might want to run SAGE under gdb with 'sage -gdb' to debug this.
> SAGE will now terminate (sorry).
> ------------------------------------------------------------
That's certainly a bug. I created a ticket for it:http://
trac.sagemath.org/sage_trac/ticket/7794
As it is defined, PP is a polynomial ring in one variable over a
polynomial ring in one variable.
Would it be a good thing to automatically convert this into a
polynomial ring with *two* variables? What do people think?
I think: no, I do not want this automatic conversion and I can think
of situations where it is a bad idea. But it would be good to have
very easy conversions between them. For example, if I have created k
[x,y,z] then it would be nice to have a way of converting it to k[x,y]
[z], k[y,z][x] (etc) and k[x][y,z] (etc) and even k[x][y][z] (and
permutations). That's a lot of possibilities so some thought would be
needed in the interface; the result would be a new polynomial ring
and some kind of isomorphism between the old and a new. ("Some kind"
meaning at least a ring isomorphism, and at least a k-module
morphism.)
John
If you
have an opinion about it, you might also comment
onhttp://trac.sagemath.org/sage_trac/ticket/7580, where I do those
conversions for Infinite Polynomial Rings.
Note that Alex' example reveals another bug, this time in
MPolynomialRing_libsingular:
sage: F.<a> = FiniteField(3)
sage: P.<T,z> = PolynomialRing(F)
sage: type(P)
<type
'sage.rings.polynomial.multi_polynomial_libsingular.MPolynomialRing_libsingular'>
sage: (z^3 + T*z)^(81*3) # immediate answer
z^729 + T^243*z^243
sage: (z^3 + T*z)^(2^20)
/home/king/SAGE/sage-4.3/local/bin/sage-sage: line 206: 20889
Segmentation fault sage-ipython "$@" -i
This was without Ctrl-C.
Certainly there should be no segfault. If anything, there should an
error be raised.
I made this another ticket,http://trac.sagemath.org/sage_trac/ticket/
7795
Thanks for the report!
Simon
Simon King
On 30 Dez., 18:18, John Cremona <john.crem...@gmail.com> wrote:
[...]
> As it is defined, PP is a polynomial ring in one variable over a
> polynomial ring in one variable.
> Would it be a good thing to automatically convert this into a
> polynomial ring with *two* variables? What do people think?
>
> I think: no, I do not want this automatic conversion and I can think
> of situations where it is a bad idea.
It should be somehow restrictive, for example with respect to monomial
order. This is something I spent a lot of work on in my patch at
http://trac.sagemath.org/sage_trac/ticket/7580: If P is a ring and one
constructs a (finite or infinite) polynomial ring R over P then P
should be an *ordered* subring of R.
However, I think that a more sensible than the present mechanism is
necessary, for at least two reasons.
The first:
sage: R.<t>=ZZ['t'][]
sage: R
Univariate Polynomial Ring in t over Univariate Polynomial Ring in
t over Integer Ring
So, sage swallows a ring definition with two conflicting meanings of
t. I think in such situations an error should be raised -- and in the
patch for #7580 I demonstrate how this can be done, even if one has
R=ZZ['t']['x']['t'] (hence, the first t is not a variable in the
basering of R, but is a variable in the basering of the basering of
R).
Second reason:
Subsequent computations will be much quicker (and, by my experience,
less buggy) if one works in MPolynomialRing_libsingular, rather than
relying on generic algorithms in MPolynomialRing_polydict or
MPolynomialRing_integral_domain. So, it does make sense to keep the
definition simple.
Third (and probably most debatable) reason:
If we forget the monomial order for a moment: How does a polynomial
ring in x over a polynomial ring in y differ from a polynomial ring in
x and y, computationally? Shouldn't one simplify a construction if the
result is computationally equivalent?
And a last argument, more an observation:
From the point of view of construction functors, what I suggest is
already done in Sage.
sage: Fy,Fx = QQ['x','y'].construction()[0].expand()
sage: Fy
MPoly[y]
sage: Fx
MPoly[x]
sage: (Fy*Fx)(QQ)
Multivariate Polynomial Ring in x, y over Rational Field
Unfortunately, the construction functors are not functorial:
sage: Fy(Fx(QQ))
Univariate Polynomial Ring in y over Univariate Polynomial Ring in x
over Rational Field
So, (Fy*Fx)(QQ) != Fy(Fx(QQ)). Not nice. On the one hand, (Fy*Fx)
does what I suggests, on the other hand, Fy(Fx()) doesn't.
Best regards,
Simon
Simon King
> Third (and probably most debatable) reason:
> If we forget the monomial order for a moment: How does a polynomial
> ring in x over a polynomial ring in y differ from a polynomial ring in
> x and y, computationally? Shouldn't one simplify a construction if the
> result is computationally equivalent?
I meant to write: Shouldn't one *automatically* simplify a
construction? Of course, this is only possible if the result of the
simplified construction is computationally equivalent to the result of
the unsimplified construction -- which (I think) is essentially the
case here.
Cheers,
Simon