#14403: Symbolic charpoly broken
-----------------------------+--------------------------
Reporter: nbruin | Owner: burcin
Type: defect | Status: new
Priority: major | Milestone: sage-5.11
Component: symbolics | Resolution:
Keywords: | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Dependencies:
Stopgaps: |
-----------------------------+--------------------------
Comment (by gagern):
Replying to [comment:7 nbruin]:
> the use of the routine "polynomial" […] is dodgy […]
> The code proposed in the ticket is both more robust and faster.
I must confess I don't understand the difference. In my understanding,
both the approach via `coefficients` and the one via
`expression.polynomial` are intended to turn an expression representation
of a polynomial into an element of the polynomial ring. I don't see
''why'' there is a difference in performance or robustness, but I can at
least confirm a quite significant difference in performance. So I updated
my patch accordingly, will attach that in a moment.
I did a mix of my old patch and the code mentioned in the ticket itself.
In particular, I still use my own way to generate a unique variable. That
way, chances are that different matrices using the same set of variables
will use the same variable for the characteristic polynomial as well,
which should avoid the memory leak scenario mentioned above although I
don't fully understand that one either. Someone who does please confirm my
assumption. Sounds like there were a central store of assigned variables,
which I hadn't anticipated. Haven't looked at the SR sources yet.
In my setup, the variable name only depends on the matrix itself, not on
any symbols used in other parts of the code, and more importantly not on
the order in which characteristic polynomials are computed. I thought of
trying a list of well-known symbol names first, like `['x', 'y', 'z', 't',
'mu']`, but decided against it for now since it doesn't seem worth the
effort.
There is no strong reason to use the same name in the maxima computation
and for the symbolic ring. The original ticket used `'crazy_varname'` for
one and `var` for the other. On the other hand, I don't feel like relying
on the fact that `'crazy_varname'` will be unlikely to occur in the
matrix. I feel safer using a variable name which is certainly unique. And
if I do the work to find such a vriable name, I might as well use the same
for the computation in maxima and for the presentation as a polynomial.
After all, ''always'' using `x` as the variable name by default feels
plain wrong if the matrix itself does contain an `x`. That kind of
overloading is bound to cause confusion.
My patch keeps the improvements for the `expression.polynomial(…)` method.
Even if `charpoly` does not depend on it, being able to correctly convert
a larger number of use cases seems worthwhile. If you'd prefer that as a
separate commit, please let me know.
--
Ticket URL: <http://trac.sagemath.org/ticket/14403#comment:9>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/groups/opt_out.