#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:10 nbruin]:
> The routine `polynomial` tries to recognize the thing as a polynomial in
whatever variables (hence the problems with `y^(1/2)`)
Not with my modification, but the speed difference remains. The reason why
I'd have considered `polynomial` to be potentially faster than the
approach based on `coefficient` is that the former has to traverse the
expression only once, whereas the latter has to do one pass per power.
> How about `do_not_use_this_name_in_a_matrix_youll_compute_a_charpol_of`
then? It saves you digging through all the variables occurring in the
matrix unnecessarily.
Possible for the computation, but we very certainly don't want this
variable occuring in the result. Since I still maintain that we have to
find a unique and readable name for the generator of the polynomial ring
for the result, would there be any win in always using this name for the
computation? Would this reduce memory leaks? I guess it might, so I'll
include this in my next patch, but I'll wait for some answers to questions
below first.
> For me, explicit is better than implicit: If I'm going to do something
with a charpol, I need to know in what variable it has been expressed, so
the system choosing a relatively unpredictable name is no good.
I disagree. The explicit approach is always possible, i.e. you can always
specify the variable name in the invocation. But if you only want to have
a look at the polynomial, it doesn't matter that much what the variable
is, as long as you can recognize it and can distinguish it from other
variables. And if you want to do some subsequent computation, chances are
that you don't care for the name of the variable at all, but only for the
list of coefficients.
> For one thing, one might expect that
> {{{
> charpol(A)*charpol(B) == charpol(block_diagonal(A,B))
> }}}
> but that's not necessarily the case if sage varies the default variable
name used.
I don't think I'd share that expectation. What I'd expect is
{{{
A.charpoly('t')*B.charpoly('t') == block_diagonal(A, B).charpoly('t')
}}}
i.e. if you explicitely name the variable, then the polynomials should
agree. If you don't name the variable, and the default name of `x` appears
in one of the matrices but not the other, then raising an error instead
would be acceptable to me, like what my patch would cause:
{{{
TypeError: unsupported operand parent(s) for '*': 'Univariate Polynomial
Ring in
x1 over Symbolic Ring' and 'Univariate Polynomial Ring in x over Symbolic
Ring'
}}}
What exactly is it you propose for the visible result of this method, when
called without a variable name?
* 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.
* If you want the `do_not_use…` name to leak into the result, reading the
polynomial directly would be a real pain.
* 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.
* 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.
--
Ticket URL: <http://trac.sagemath.org/ticket/14403#comment:11>
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.
