Dear all,
At SAGE Days 16 I implemented some code for division-free matrix
operations, which is being tracked as ticket #6441. The main
contribution is code to compute the characteristic polynomial without
divisions, and this leads to code to compute the characteristic
polynomial, the adjoint matrix and the determinant of matrices over
any ring (commutative and with unity). On the one hand this will
extend the capabilities of SAGE, but in some cases it will also
provide a speed-up (by avoiding working in the field of fractions, or
because an O(n^4) algorithm beats the previous backup option for
computing determinants).
With this little background provided, here is the actual problem on
which I would very much like to hear your opinion.
A design-related technical problem is that, when given a ring R and
asked to construct or compute with certain objects related to R (see
below for some examples), SAGE tries to find out whether R is merely a
ring, or maybe an integral domain,or perhaps even a field. The
generic methods for this are located in sage/rings/ring.pyx.
In this file, the current behaviour is the following,
o Try to establish the answer (yes or no).
o If this doesn't work, throw an exception.
although the actual behaviour is down to the inheriting classes.
>From the point of view of the ring, this might seem sensible. But I
think the case where this is used is something like this: One has
various algorithms at hand for computing with a given ring, and the
computation would be done much better if one knew the ring was a
field, say. I think the code would be a lot cleaner if the following
behaviour was offered:
o Try to find out whether the ring is a field, say.
o If the positive answer can be established, return yes. Otherwise,
return false.
To this extent, the current patch code includes methods
"is_certainly_field" and"is_certainly_integral_domain".
As part of the discussion on the trac ticket #6441, it was suggested
to instead do with the usual "is_field" etc. methods and handle
exceptions in the calling method. If it was only my new method that
would suffer from this problem, I'd be tempted to agree that this
would be the correct way to handle the problem. However, there are
two reasons why I think rings should have simple yes/no (rather than
yes/no/some exception) methods to be queried for being a field,
integral domain,etc. Firstly, the same problem occurs in other
places, too, for example when constructing polynomial rings or
vectors. Secondly, the exceptions can also be raised at a deeper
level, e.g. when a quotient ring is asked whether it is a field, it
checks whether the ideal is maximal. It is not clear to me from this
that the current implementation provides an answer of the kind (yes/no/
NotImplementedError); it's a least plausible that the determination
of whether a ring is a field could fail for a number of other reasons
and hence raise other exceptions, too.
I think this is one of the last few things in the way of completing
this trac ticket, so please let me know what you think.
Many thanks,
Sebastian
[Examples]
Let's take the following quotient ring S.
sage: R.<a,b> = QQ[]
sage: S.<x,y> = R.quo((b^3))
sage: A = matrix(S, [[x*y^2,2*x],[2,x^10*y]])
sage: A
[ x*y^2 2*x]
[ 2 x^10*y]
Then computing the charpoly of A will fail with a NotImplementedError
in "is_maximal" when checking whether the defining ideal is maximal.
sage: A.charpoly('T')
T^2 + (-x^10*y - x*y^2)*T - 4*x
(Interestingly, A.det() fails with an IndexError, but this would also
disappear with the patch in ticket #6441 applied.) The same happens
if we try to create a vector over the ring S,
sage: v = vector(S, 3)
or if we try to create a univariate polynomial ring over S,
sage: P.<x> = PolynomialRing(S, 'x')
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
