#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:13 nbruin]:
> Indeed, `x`, because that is already the default in sage anyway.
I don't know sage development structures and politics. Is this a personal
opinion, or does this come with enough authority to indicate this as the
direction to go?
> {{{
> sage: P.<x>=QQ[]
> sage: M=matrix(2,2,[x,1,1,x])
> sage: M.charpoly()
> x^2 - 2*x*x + x^2 - 1
> }}}
Personally, I'd consider this a bug.
> You'd have to come up with a naming solution that works across sage
structures, which sounds pretty hopeless to me.
How many rings are there? How many of them have elements which you can
name? While I agree that this might require considerable effort, I do have
hope and would consider such an endeavour worthwhile.
> I think choosing a non-conflicting name is too difficult and confusing
It seems our individual perceptions of how confusing the various
alternatives are differ quite a lot… Can you point out an example where
this confusion will actually cause harm?
> Conversion to other systems is indeed dangerous: don't do that :-).
This sounds both crucial and problematic to me. There is nothing to
prevent users from doing this, and checking every possible conversion
input for possible clashes sounds a lot more problematic than detecting
symbol names in all structures which can carry them. So users will do
this, and will get wrong results without a warning.
Besides, I was under the impression that the whole idea behind sage is
that users don't have to think about what backend does the actual work,
since it's all glued together nicely. Your statement sounds like a
conscious violation of that ideal.
One thing which I ''can'' do is this: adapt my patch to do ''only'' the
fix you quoted plus a few doctests. Then I would file another ticket for
the fixes to the `expression.polynomial` even though `charpoly` no longer
needs them, and yet another one for the broader question of choosing a
suitable variable name for `charpoly` (and similar situations if you can
think of some). There we could continue to discuss the pros and cons of
the two basic approaches: fixed but clashing vs. unpredictable unique.
That way, the discussion about the correct approach to that could continue
but would not block the required fix here. And if it were addressed
eventually, it could be addressed in a way suitable to ''all'' affected
structures. How does that sound?
--
Ticket URL: <http://trac.sagemath.org/ticket/14403#comment:14>
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.
