Sage: Ticket #14403: Symbolic charpoly broken
https://trac.sagemath.org/ticket/14403
<p>
see <a class="ext-link" href="https://groups.google.com/group/sage-devel/browse_thread/thread/71d76cd072fe17eb?hl=en"><span class="icon"></span>sage-devel</a>.
Not good:
</p>
<pre class="wiki">sage: a=matrix([[x,0,0,0],[0,1,0,0],[0,0,1,0],[0,0,0,1]])
sage: charpoly(a)
0
</pre><p>
Also not good
</p>
<pre class="wiki">sage: var('y')
sage: b=matrix([[y^(1/2),0,0,0],[0,1,0,0],[0,0,1,0],[0,0,0,1]])
sage: charpoly(b)
Error
</pre><p>
Both can be solved by doing something more along the lines of
</p>
<pre class="wiki">V=SR('crazy_varname')
cp=self._maxima_(maxima).charpoly('crazy_varname')._sage_().expand()
SR[var](list(cp.coefficient(V,i) for i in range(self.nrows()+1)))
</pre><p>
in <code>a.charpoly</code>.
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/14403
Trac 1.1.6eviatarbachWed, 24 Apr 2013 17:58:46 GMTcc set
https://trac.sagemath.org/ticket/14403#comment:1
https://trac.sagemath.org/ticket/14403#comment:1
<ul>
<li><strong>cc</strong>
<em>eviatarbach</em> added
</li>
</ul>
TicketgagernTue, 23 Jul 2013 09:30:53 GMTattachment set
https://trac.sagemath.org/ticket/14403
https://trac.sagemath.org/ticket/14403
<ul>
<li><strong>attachment</strong>
set to <em>trac_14403_symbolic_charpoly.patch</em>
</li>
</ul>
TicketgagernTue, 23 Jul 2013 09:40:52 GMT
https://trac.sagemath.org/ticket/14403#comment:2
https://trac.sagemath.org/ticket/14403#comment:2
<p>
OK, here is an attempt to address this.
</p>
<p>
I modified the <code>charpoly</code> method to always use a unique variable name. I found no ready-to-use utility function to achieve this, but I expect there might be, so if you know one please let me know and I'll update my code. So far I simply append numbers to the letter <code>x</code> until the resulting string is not among the list of variable names used inside the matrix. The resulting variable name will <em>always</em> be used for the cached polynomial, and will <em>by default</em> be used for the returned polynomial.
</p>
<p>
If the caller overrides the variable name, there is no check to ensure that this name does not conflict with the names used in the matrix. I'm unsure myself whether I'd consider this behavior a bug or a feature, i.e. what intended behavior for that case should be. If you want I can add a piece of code to perform that check before the <code>change_variable_name</code> call, and throw an error on conflicting variable names.
</p>
<p>
I've kept the <code>expression.polynomial(None, ring=SR[var])</code> approach, and not used the <code>expression.coefficient(var, i)</code> version suggested in the ticket report. Instead, I adjusted the conversion of expressions to polynomials to only treat those variable powers as possible monomials where the variable itself corresponds to one of the variables from the target ring. All other expressions are treated as coefficients, even if they are powers of a symbolic variable. This avoids the conversion to integers for these cases, and hence the error mentioned in the ticket. This fix might be useful to other applications as well.
</p>
TicketgagernTue, 23 Jul 2013 09:41:05 GMTcc changed
https://trac.sagemath.org/ticket/14403#comment:3
https://trac.sagemath.org/ticket/14403#comment:3
<ul>
<li><strong>cc</strong>
<em>gagern</em> added
</li>
</ul>
TicketppurkaTue, 23 Jul 2013 12:02:58 GMTcc changed
https://trac.sagemath.org/ticket/14403#comment:4
https://trac.sagemath.org/ticket/14403#comment:4
<ul>
<li><strong>cc</strong>
<em>ppurka</em> added
</li>
</ul>
TicketeviatarbachWed, 24 Jul 2013 05:11:22 GMT
https://trac.sagemath.org/ticket/14403#comment:5
https://trac.sagemath.org/ticket/14403#comment:5
<p>
Thanks for taking on this ticket! It's a big problem.
</p>
<p>
There is in fact a way to generate unique variable names; just call <code>SR.symbol()</code>. This will ensure that there are no collisions.
</p>
TicketppurkaWed, 24 Jul 2013 05:48:16 GMT
https://trac.sagemath.org/ticket/14403#comment:6
https://trac.sagemath.org/ticket/14403#comment:6
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/14403#comment:5" title="Comment 5">eviatarbach</a>:
</p>
<blockquote class="citation">
<p>
Thanks for taking on this ticket! It's a big problem.
</p>
<p>
There is in fact a way to generate unique variable names; just call <code>SR.symbol()</code>. This will ensure that there are no collisions.
</p>
</blockquote>
<p>
That's true, but that generates ugly symbol names, which might be confusing to read in a long characteristic polynomial. I like the solution proposed in the patch a little better. For example, here is what I get from <code>SR.symbol()</code>
</p>
<pre class="wiki">sage: SR.symbol()
symbol160
sage: SR.symbol()
symbol163
sage: SR.symbol()
symbol166
</pre><p>
Is there some general way of asking for the "next" symbol given some pattern? Essentially, emulating what a part of this patch does. Something which behaves like this:
</p>
<pre class="wiki">sage: SR.next_variable('x') # suppose x, x0, x1 are already defined
x2
sage: SR.next_variable('x2')
x3
sage: SR.next_variable('x0y') # suppose that x0y is not yet defined.
x0y
</pre>
TicketnbruinWed, 24 Jul 2013 06:17:12 GMT
https://trac.sagemath.org/ticket/14403#comment:7
https://trac.sagemath.org/ticket/14403#comment:7
<p>
Please look at the sage-devel thread referenced. Part of the problem here is the use of the routine "polynomial", which is dodgy for examples like:
<code>matrix([[y^(1/2),0,0,0],[0,1,0,0],[0,0,1,0],[0,0,0,1]]) </code>
You know that the expression returned by maxima's charpol is already presented as a polynomial in the (better unique!) variable used to do the expansion. The code proposed in the ticket is both more robust and faster.
</p>
TicketppurkaWed, 24 Jul 2013 06:33:09 GMT
https://trac.sagemath.org/ticket/14403#comment:8
https://trac.sagemath.org/ticket/14403#comment:8
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/14403#comment:7" title="Comment 7">nbruin</a>:
</p>
<blockquote class="citation">
<p>
Please look at the sage-devel thread referenced. Part of the problem here is the use of the routine "polynomial", which is dodgy for examples like:
<code>matrix([[y^(1/2),0,0,0],[0,1,0,0],[0,0,1,0],[0,0,0,1]]) </code>
You know that the expression returned by maxima's charpol is already presented as a polynomial in the (better unique!) variable used to do the expansion. The code proposed in the ticket is both more robust and faster.
</p>
</blockquote>
<p>
Ok. I see. The main concern is this it seems (quoted from the sage-devel ML):
</p>
<p>
<em>
(You really don't want to let 'crazy_varname' leak out of charpoly,
otherwise you'll have trouble if someone decides to make a matrix of
characteristic polynomials and determine the charpoly of that. You
also don't want to generate a fresh variable every time, since the
management of variables in maxima/our interface would create a memory
leak)
</em>
</p>
<p>
@gagern: can you try converting the code in the ticket description into a patch (along with a doctest)?
</p>
TicketgagernWed, 24 Jul 2013 11:14:14 GMT
https://trac.sagemath.org/ticket/14403#comment:9
https://trac.sagemath.org/ticket/14403#comment:9
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/14403#comment:7" title="Comment 7">nbruin</a>:
</p>
<blockquote class="citation">
<p>
the use of the routine "polynomial" […] is dodgy […]
The code proposed in the ticket is both more robust and faster.
</p>
</blockquote>
<p>
I must confess I don't understand the difference. In my understanding, both the approach via <code>coefficients</code> and the one via <code>expression.polynomial</code> are intended to turn an expression representation of a polynomial into an element of the polynomial ring. I don't see <em>why</em> 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.
</p>
<p>
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.
</p>
<p>
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 <code>['x', 'y', 'z', 't', 'mu']</code>, but decided against it for now since it doesn't seem worth the effort.
</p>
<p>
There is no strong reason to use the same name in the maxima computation and for the symbolic ring. The original ticket used <code>'crazy_varname'</code> for one and <code>var</code> for the other. On the other hand, I don't feel like relying on the fact that <code>'crazy_varname'</code> 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, <em>always</em> using <code>x</code> as the variable name by default feels plain wrong if the matrix itself does contain an <code>x</code>. That kind of overloading is bound to cause confusion.
</p>
<p>
My patch keeps the improvements for the <code>expression.polynomial(…)</code> method. Even if <code>charpoly</code> 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.
</p>
TicketgagernWed, 24 Jul 2013 11:14:45 GMTattachment set
https://trac.sagemath.org/ticket/14403
https://trac.sagemath.org/ticket/14403
<ul>
<li><strong>attachment</strong>
set to <em>trac_14403_symbolic_charpoly_v2.patch</em>
</li>
</ul>
TicketnbruinWed, 24 Jul 2013 21:50:43 GMT
https://trac.sagemath.org/ticket/14403#comment:10
https://trac.sagemath.org/ticket/14403#comment:10
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/14403#comment:9" title="Comment 9">gagern</a>:
</p>
<blockquote class="citation">
<p>
I must confess I don't understand the difference. In my understanding, both the approach via <code>coefficients</code> and the one via <code>expression.polynomial</code> are intended to turn an expression representation of a polynomial into an element of the polynomial ring.
</p>
</blockquote>
<p>
Just look up the source code of <code>expression.polynomial</code>; you'll quickly see it's not a routine you want to call unless you really have to. The difference is that we already know with respect to which variable we want to collect the terms. The routine <code>polynomial</code> tries to recognize the thing as a polynomial in whatever variables (hence the problems with <code>y^(1/2)</code>)
</p>
<blockquote class="citation">
<blockquote>
<p>
Sounds like there were a central store of assigned variables, which I hadn't anticipated. Haven't looked at the SR sources yet.
</p>
</blockquote>
</blockquote>
<p>
Correct. This is the case in both maxima and in SR and necessarily permanently so in the translation layer between them (we cannot monitor the lifetime in both simultaneously)
</p>
<blockquote class="citation">
<p>
There is no strong reason to use the same name in the maxima computation and for the symbolic ring. The original ticket used <code>'crazy_varname'</code> for one and <code>var</code> for the other. On the other hand, I don't feel like relying on the fact that <code>'crazy_varname'</code> will be unlikely to occur in the matrix.
</p>
</blockquote>
<p>
How about <code>do_not_use_this_name_in_a_matrix_youll_compute_a_charpol_of</code> then? It saves you digging through all the variables occurring in the matrix unnecessarily.
</p>
<blockquote class="citation">
<p>
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, <em>always</em> using <code>x</code> as the variable name by default feels plain wrong if the matrix itself does contain an <code>x</code>. That kind of overloading is bound to cause confusion.
</p>
</blockquote>
<p>
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.
</p>
<p>
For one thing, one might expect that
</p>
<pre class="wiki">charpol(A)*charpol(B) == charpol(block_diagonal(A,B))
</pre><p>
but that's not necessarily the case if sage varies the default variable name used.
</p>
TicketgagernThu, 25 Jul 2013 07:55:38 GMT
https://trac.sagemath.org/ticket/14403#comment:11
https://trac.sagemath.org/ticket/14403#comment:11
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/14403#comment:10" title="Comment 10">nbruin</a>:
</p>
<blockquote class="citation">
<p>
The routine <code>polynomial</code> tries to recognize the thing as a polynomial in whatever variables (hence the problems with <code>y^(1/2)</code>)
</p>
</blockquote>
<p>
Not with my modification, but the speed difference remains. The reason why I'd have considered <code>polynomial</code> to be potentially faster than the approach based on <code>coefficient</code> is that the former has to traverse the expression only once, whereas the latter has to do one pass per power.
</p>
<blockquote class="citation">
<p>
How about <code>do_not_use_this_name_in_a_matrix_youll_compute_a_charpol_of</code> then? It saves you digging through all the variables occurring in the matrix unnecessarily.
</p>
</blockquote>
<p>
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.
</p>
<blockquote class="citation">
<p>
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.
</p>
</blockquote>
<p>
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.
</p>
<blockquote class="citation">
<p>
For one thing, one might expect that
</p>
<pre class="wiki">charpol(A)*charpol(B) == charpol(block_diagonal(A,B))
</pre><p>
but that's not necessarily the case if sage varies the default variable name used.
</p>
</blockquote>
<p>
I don't think I'd share that expectation. What I'd expect is
</p>
<pre class="wiki">A.charpoly('t')*B.charpoly('t') == block_diagonal(A, B).charpoly('t')
</pre><p>
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 <code>x</code> 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:
</p>
<pre class="wiki">TypeError: unsupported operand parent(s) for '*': 'Univariate Polynomial Ring in
x1 over Symbolic Ring' and 'Univariate Polynomial Ring in x over Symbolic Ring'
</pre><p>
What exactly is it you propose for the visible result of this method, when called without a variable name?
</p>
<ul><li>If you want a default of <code>x</code> in all cases, then you accept strange cases where the printed result will contain two flavors of <code>x</code>, 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.
</li><li>If you want the <code>do_not_use…</code> name to leak into the result, reading the polynomial directly would be a real pain.
</li><li>If you want to raise an exception whenever <code>x</code> occurs in the matrix, I'd consider this unneccessarily annoying. Particularly for cases where the user didn't call <code>charpoly</code> directly, but some other computation uses it.
</li><li>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.
</li></ul>
TicketgagernThu, 25 Jul 2013 09:10:59 GMT
https://trac.sagemath.org/ticket/14403#comment:12
https://trac.sagemath.org/ticket/14403#comment:12
<p>
I just noticed that <code>charpoly</code> the function unconditionally passes its variable name to the method. Changed that, will be included in my next patch, once we have reached consensus on what the variable name in the default case should be. Of course if we were to agree that it should always be <code>x</code> then that part would be superfluous, but I don't see me agreeing to that unless I see a really strong argument for it.
</p>
TicketnbruinThu, 25 Jul 2013 14:00:16 GMT
https://trac.sagemath.org/ticket/14403#comment:13
https://trac.sagemath.org/ticket/14403#comment:13
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/14403#comment:11" title="Comment 11">gagern</a>:
</p>
<blockquote class="citation">
<p>
What exactly is it you propose for the visible result of this method, when called without a variable name?
</p>
</blockquote>
<p>
Indeed, <code>x</code>, because that is already the default in sage anyway.
</p>
<pre class="wiki">sage: P.<x>=QQ[]
sage: M=matrix(2,2,[x,1,1,x])
sage: M.charpoly()
x^2 - 2*x*x + x^2 - 1
</pre><blockquote class="citation">
<ul><li>If you want a default of <code>x</code> in all cases, then you accept strange cases where the printed result will contain two flavors of <code>x</code>, 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.
</li></ul></blockquote>
<p>
You'd have to come up with a naming solution that works across sage structures, which sounds pretty hopeless to me.
</p>
<blockquote class="citation">
<ul><li>If you want the <code>do_not_use…</code> name to leak into the result, reading the polynomial directly would be a real pain.
</li></ul></blockquote>
<p>
It should definitely not leak! Then it can find its way back into a matrix and cause real havoc.
</p>
<blockquote class="citation">
<ul><li>If you want to raise an exception whenever <code>x</code> occurs in the matrix, I'd consider this unneccessarily annoying. Particularly for cases where the user didn't call <code>charpoly</code> directly, but some other computation uses it.
</li></ul></blockquote>
<p>
Exactly. I agree.
</p>
<blockquote class="citation">
<ul><li>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.
</li></ul></blockquote>
<p>
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 :-).
</p>
TicketgagernThu, 25 Jul 2013 16:04:28 GMT
https://trac.sagemath.org/ticket/14403#comment:14
https://trac.sagemath.org/ticket/14403#comment:14
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/14403#comment:13" title="Comment 13">nbruin</a>:
</p>
<blockquote class="citation">
<p>
Indeed, <code>x</code>, because that is already the default in sage anyway.
</p>
</blockquote>
<p>
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?
</p>
<blockquote class="citation">
<pre class="wiki">sage: P.<x>=QQ[]
sage: M=matrix(2,2,[x,1,1,x])
sage: M.charpoly()
x^2 - 2*x*x + x^2 - 1
</pre></blockquote>
<p>
Personally, I'd consider this a bug.
</p>
<blockquote class="citation">
<p>
You'd have to come up with a naming solution that works across sage structures, which sounds pretty hopeless to me.
</p>
</blockquote>
<p>
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.
</p>
<blockquote class="citation">
<p>
I think choosing a non-conflicting name is too difficult and confusing
</p>
</blockquote>
<p>
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?
</p>
<blockquote class="citation">
<p>
Conversion to other systems is indeed dangerous: don't do that :-).
</p>
</blockquote>
<p>
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.
</p>
<p>
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.
</p>
<p>
One thing which I <em>can</em> do is this: adapt my patch to do <em>only</em> the fix you quoted plus a few doctests. Then I would file another ticket for the fixes to the <code>expression.polynomial</code> even though <code>charpoly</code> no longer needs them, and yet another one for the broader question of choosing a suitable variable name for <code>charpoly</code> (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 <em>all</em> affected structures. How does that sound?
</p>
TicketnbruinThu, 25 Jul 2013 18:01:09 GMT
https://trac.sagemath.org/ticket/14403#comment:15
https://trac.sagemath.org/ticket/14403#comment:15
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/14403#comment:14" title="Comment 14">gagern</a>:
</p>
<blockquote class="citation">
<p>
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?
</p>
</blockquote>
<p>
As far as I'm concerned it's common sense. I won't claim authority for my own opinion concerning sage, though.
</p>
<blockquote class="citation">
<blockquote class="citation">
<pre class="wiki">sage: P.<x>=QQ[]
sage: M=matrix(2,2,[x,1,1,x])
sage: M.charpoly()
x^2 - 2*x*x + x^2 - 1
</pre></blockquote>
<p>
Personally, I'd consider this a bug.
</p>
</blockquote>
<p>
I agree it's nasty, but it's there. The problem is that you can have arbitrarily nastily nested structures: <code>QQ['s']['x']['u']['y']</code>. People could even name their number field generators or finite field generators <code>x</code>.
</p>
<blockquote class="citation">
<p>
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.
</p>
</blockquote>
<p>
It has to be low-cost, though. You're competing with choosing <code>x</code> just blindly.
</p>
<blockquote class="citation">
<p>
One thing which I <em>can</em> do is this: adapt my patch to do <em>only</em> the fix you quoted plus a few doctests. Then I would file another ticket for the fixes to the <code>expression.polynomial</code> even though <code>charpoly</code> no longer needs them,
</p>
</blockquote>
<p>
You might as well fix polynomial.
</p>
<blockquote class="citation">
<p>
and yet another one for the broader question of choosing a suitable variable name for <code>charpoly</code> (and similar situations if you can think of some).
</p>
</blockquote>
<p>
Yes, because I think it's not clear yet how to solve this properly and it's something that is a wider problem than just SR.
</p>
TicketgagernThu, 25 Jul 2013 19:30:31 GMT
https://trac.sagemath.org/ticket/14403#comment:16
https://trac.sagemath.org/ticket/14403#comment:16
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/14403#comment:15" title="Comment 15">nbruin</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/14403#comment:14" title="Comment 14">gagern</a>:
</p>
<blockquote class="citation">
<p>
and yet another one for the broader question of choosing a suitable variable name for <code>charpoly</code> (and similar situations if you can think of some).
</p>
</blockquote>
<p>
Yes, because I think it's not clear yet how to solve this properly and it's something that is a wider problem than just SR.
</p>
</blockquote>
<p>
Filed <a class="new ticket" href="https://trac.sagemath.org/ticket/14972" title="defect: charpoly name clashes with matrix content (new)">#14972</a> for this. Will attach a patch for the rest shortly.
</p>
TicketburcinThu, 25 Jul 2013 19:49:44 GMT
https://trac.sagemath.org/ticket/14403#comment:17
https://trac.sagemath.org/ticket/14403#comment:17
<p>
FWIW, I agree with Nils that it is""common sense" to use a standard variable name. There is no need to complicate the implementation by searching for variables.
</p>
<p>
If we decide to use a new variable name, the procedure to do this should be constant time. Enumerating variables in a matrix/ring and finding a new name is too complicated. Pick a prefix and increase a counter whenever you need a new variable. On the other hand, it would also be confusing to get different variables when you call <code>charpoly()</code> twice.
</p>
TicketgagernThu, 25 Jul 2013 20:18:59 GMTattachment set
https://trac.sagemath.org/ticket/14403
https://trac.sagemath.org/ticket/14403
<ul>
<li><strong>attachment</strong>
set to <em>trac_14403_symbolic_charpoly_v3.patch</em>
</li>
</ul>
TicketgagernThu, 25 Jul 2013 20:19:27 GMTattachment set
https://trac.sagemath.org/ticket/14403
https://trac.sagemath.org/ticket/14403
<ul>
<li><strong>attachment</strong>
set to <em>trac_14403_expression_polynomial.patch</em>
</li>
</ul>
TicketgagernMon, 29 Jul 2013 11:53:20 GMTstatus changed
https://trac.sagemath.org/ticket/14403#comment:18
https://trac.sagemath.org/ticket/14403#comment:18
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
</ul>
TicketnbruinMon, 29 Jul 2013 19:48:01 GMT
https://trac.sagemath.org/ticket/14403#comment:19
https://trac.sagemath.org/ticket/14403#comment:19
<p>
testbot apply trac_14403_symbolic_charpoly_v3.patch trac_14403_expression_polynomial.patch
</p>
TicketjdemeyerTue, 13 Aug 2013 15:35:53 GMTmilestone changed
https://trac.sagemath.org/ticket/14403#comment:20
https://trac.sagemath.org/ticket/14403#comment:20
<ul>
<li><strong>milestone</strong>
changed from <em>sage-5.11</em> to <em>sage-5.12</em>
</li>
</ul>
TicketegourgoulhonMon, 07 Oct 2013 14:08:06 GMTcc changed
https://trac.sagemath.org/ticket/14403#comment:21
https://trac.sagemath.org/ticket/14403#comment:21
<ul>
<li><strong>cc</strong>
<em>egourgoulhon</em> added
</li>
</ul>
Ticketvbraun_spamThu, 30 Jan 2014 21:20:52 GMTmilestone changed
https://trac.sagemath.org/ticket/14403#comment:22
https://trac.sagemath.org/ticket/14403#comment:22
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.1</em> to <em>sage-6.2</em>
</li>
</ul>
TicketrwsTue, 18 Feb 2014 11:02:47 GMT
https://trac.sagemath.org/ticket/14403#comment:23
https://trac.sagemath.org/ticket/14403#comment:23
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/14403#comment:6" title="Comment 6">ppurka</a>:
</p>
<blockquote class="citation">
<p>
Is there some general way of asking for the "next" symbol given some pattern? Essentially, emulating what a part of this patch does. Something which behaves like this:
</p>
<pre class="wiki">sage: SR.next_variable('x') # suppose x, x0, x1 are already defined
x2
sage: SR.next_variable('x2')
x3
sage: SR.next_variable('x0y') # suppose that x0y is not yet defined.
x0y
</pre></blockquote>
<p>
I have opened <a class="new ticket" href="https://trac.sagemath.org/ticket/15831" title="enhancement: implement SR.next_variable() (new)">#15831</a> for this. Also, below is the patch, adapted to base it on 6.0.
</p>
TicketrwsTue, 18 Feb 2014 14:42:31 GMTchangetime, time changed; branch set
https://trac.sagemath.org/ticket/14403#comment:24
https://trac.sagemath.org/ticket/14403#comment:24
<ul>
<li><strong>changetime</strong>
changed from <em>02/18/14 11:02:47</em> to <em>02/18/14 11:02:47</em>
</li>
<li><strong>branch</strong>
set to <em>u/rws/ticket/14403</em>
</li>
<li><strong>time</strong>
changed from <em>04/03/13 05:15:26</em> to <em>04/03/13 05:15:26</em>
</li>
</ul>
TicketgitThu, 20 Feb 2014 17:32:22 GMTcommit set
https://trac.sagemath.org/ticket/14403#comment:25
https://trac.sagemath.org/ticket/14403#comment:25
<ul>
<li><strong>commit</strong>
set to <em>0434e05e991250f7eb0a19326be1a128a0baccce</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=0434e05e991250f7eb0a19326be1a128a0baccce"><span class="icon"></span>0434e05</a></td><td><code>Merge branch 'develop' into ticket/14403</code>
</td></tr></table>
TicketrwsSat, 22 Feb 2014 09:59:31 GMTstatus changed
https://trac.sagemath.org/ticket/14403#comment:26
https://trac.sagemath.org/ticket/14403#comment:26
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
</ul>
<p>
The code looks good, matrix/ symbolics/ and misc/ long tests pass, sage -docbuild works. So I think I'll set positive.
</p>
TicketvbraunSat, 22 Feb 2014 21:30:21 GMT
https://trac.sagemath.org/ticket/14403#comment:27
https://trac.sagemath.org/ticket/14403#comment:27
<p>
please fill in authors/reviewers.
</p>
TicketrwsSun, 23 Feb 2014 04:39:40 GMTreviewer, author set
https://trac.sagemath.org/ticket/14403#comment:28
https://trac.sagemath.org/ticket/14403#comment:28
<ul>
<li><strong>reviewer</strong>
set to <em>Ralf Stephan</em>
</li>
<li><strong>author</strong>
set to <em>Martin von Gagern</em>
</li>
</ul>
TicketvbraunWed, 05 Mar 2014 09:36:24 GMTstatus, branch changed; resolution set
https://trac.sagemath.org/ticket/14403#comment:29
https://trac.sagemath.org/ticket/14403#comment:29
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
<li><strong>branch</strong>
changed from <em>u/rws/ticket/14403</em> to <em>0434e05e991250f7eb0a19326be1a128a0baccce</em>
</li>
</ul>
Ticket