#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 nbruin):
Replying to [comment:11 gagern]:
> What exactly is it you propose for the visible result of this method,
when called without a variable name?
Indeed, `x`, because that is already the default in sage anyway.
{{{
sage: P.<x>=QQ[]
sage: M=matrix(2,2,[x,1,1,x])
sage: M.charpoly()
x^2 - 2*x*x + x^2 - 1
}}}
> * If you want a default of `x` in all cases, then you accept strange
cases where the printed result will contain two flavors of `x`, one the
generator of the polynomial and the other a variable from the symbolic
ring. I consider this highly confusing. And it might cause even more
trouble later on, particularly if this polynomial would get passed to some
other system in text form, where the distinction would get lost.
You'd have to come up with a naming solution that works across sage
structures, which sounds pretty hopeless to me.
> * If you want the `do_not_use…` name to leak into the result, reading
the polynomial directly would be a real pain.
It should definitely not leak! Then it can find its way back into a matrix
and cause real havoc.
> * If you want to raise an exception whenever `x` occurs in the matrix,
I'd consider this unneccessarily annoying. Particularly for cases where
the user didn't call `charpoly` directly, but some other computation uses
it.
Exactly. I agree.
> * If you want to have an automatically chosen and non-conflicting name,
then this would be something along the lines I proposed, so any important
difference in what you have in mind to what I did should be made more
explicit.
I think choosing a non-conflicting name is too difficult and confusing
(since the problem is not confined to just SR), so I'd accept a default
that likely clashes as the best compromise. Conversion to other systems is
indeed dangerous: don't do that :-).
--
Ticket URL: <http://trac.sagemath.org/ticket/14403#comment:13>
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.
