#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
comment:2 Changed 10 years ago by
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
- Milestone set to Sage-2.10
comment:4 Changed 9 years ago by
- Resolution set to fixed
- Status changed from new to closed
comment:5 Changed 9 years ago by
- Milestone changed from sage-2.10 to sage-2.8.15
comment:6 Changed 9 years ago by
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.