#75 closed enhancement (fixed)
specify charpoly polynomial ring
Reported by: | was | Owned by: | somebody |
---|---|---|---|
Priority: | minor | Milestone: | sage-2.8.15 |
Component: | basic arithmetic | Keywords: | |
Cc: | Merged in: | ||
Authors: | Reviewers: | ||
Report Upstream: | Work issues: | ||
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description
Joe Wetherell's idea:
On Fri, 22 Sep 2006 00:51:17 -0700, Joseph L Wetherell <jlwether@…> wrote:
I really want to agree with you, but I also want to know: what do we
do in the situations I outlined before? For example, if you do
>> >> sage: M = Matrix(QQ, 2, 2, range(4)) >> sage: f = M.charpoly() >> sage: g = M.charpoly()
Now f and g have different parents, but you *can't* coerce g to the
parent of f (or vice versa), because you can't assume the generators
match up.
OK, so perhaps the problem is that charpoly needs another argument
-- namely the variable in which the characteristic polynomial
is to be expressed.
That's a great idea. Having an optional
f = M.charpoly(x)
and/or
f = M.charpoly(PolynomialRing(ZZ))
wouldn't break anything (it's optional), and would be easy
to implement, and really just makes sense. I like it.
Change History (6)
comment:1 Changed 10 years ago by was
comment:2 Changed 10 years ago by was
Say I'm doing some calculations in a power series ring with default precision = N. Then I call some subroutine that happens to do some power series ring calculations too. It's possible that the subroutine will change the precision for its own purposes. When it returns, my precision has mysteriously changed to M. This can lead to all kinds of subtle bugs. Basically it would mean that if you use the globalised ring, then you don't have any assurances that its precision won't change from one step to the next. Unless you mean to store a separate ring for each possible precision? Or maybe you mean to force the precision to remain constant for the globalised ring? Globalized rings should be immutable, so all defining properties such as default precision, variable print name, etc., should be fixed. SAGE currently doesn't have any mutability stuff for rings yet, but it should, exactly for this reason.
Default precision shouldn't be changeable anyways, though. (It is, but
it shouldn't be.)
It would suck if you call a function and suddenly the default precision
of your ring gets changed.
William
comment:3 Changed 9 years ago by mabshoff
- Milestone set to Sage-2.10
comment:4 Changed 8 years ago by was
- Resolution set to fixed
- Status changed from new to closed
comment:5 Changed 8 years ago by was
- Milestone changed from sage-2.10 to sage-2.8.15
comment:6 Changed 8 years ago by cwitty
In current Sage, you can already set the name of the variable (although not the ring). Also, the problem in the original description ("f and g have different parents") is no longer true; in current Sage, f and g have the same parent.
So we're closing this ticket.