Sage: Ticket #16261: Default behaviour of AdditiveAbelianGroup(a_tuple)
https://trac.sagemath.org/ticket/16261
<p>
This ticket follows the conversation on
<a class="ext-link" href="https://groups.google.com/forum/#!topic/sage-support/yexpjig9BSg"><span class="icon"></span>https://groups.google.com/forum/#!topic/sage-support/yexpjig9BSg</a>
</p>
<pre class="wiki">sage: H = AdditiveAbelianGroup([0,2])
sage: H((2,0))
(0, 0)
sage: H(vector((2,0)))
(2, 0)
sage: H((1,0)).order()
2
sage: H(vector((1,0))).order()
+Infinity
</pre><p>
With this branch there is no need to wrap a tuple into a vector to avoid the "if isinstance(x,(tuple,list))" and what should be the default behaviour IS the default behaviour. And it barely breaks doctests once one replaced the old <code>[G([1,2])</code> by <code>G.linear_combination_of_smith_form_gens([1,2])</code>
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/16261
Trac 1.1.6ncohenMon, 28 Apr 2014 16:12:04 GMTcommit, branch set
https://trac.sagemath.org/ticket/16261#comment:1
https://trac.sagemath.org/ticket/16261#comment:1
<ul>
<li><strong>commit</strong>
set to <em>270545adf1dfc9e7554cb2f78700402f787a56b4</em>
</li>
<li><strong>branch</strong>
set to <em>u/ncohen/16261</em>
</li>
</ul>
<p>
New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=270545adf1dfc9e7554cb2f78700402f787a56b4"><span class="icon"></span>270545a</a></td><td><code>trac #16261: Default behaviour of AdditiveAbelianGroup(a_tuple)</code>
</td></tr></table>
TicketgitMon, 28 Apr 2014 16:42:15 GMTcommit changed
https://trac.sagemath.org/ticket/16261#comment:2
https://trac.sagemath.org/ticket/16261#comment:2
<ul>
<li><strong>commit</strong>
changed from <em>270545adf1dfc9e7554cb2f78700402f787a56b4</em> to <em>cdecd43022a6c78f40655374c3eb804b810483e9</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=cdecd43022a6c78f40655374c3eb804b810483e9"><span class="icon"></span>cdecd43</a></td><td><code>trac #16261: Default behaviour of AdditiveAbelianGroup(a_tuple)</code>
</td></tr></table>
TicketncohenMon, 28 Apr 2014 16:42:28 GMTstatus changed
https://trac.sagemath.org/ticket/16261#comment:3
https://trac.sagemath.org/ticket/16261#comment:3
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
</ul>
TicketvbraunMon, 28 Apr 2014 16:48:59 GMTstatus changed
https://trac.sagemath.org/ticket/16261#comment:4
https://trac.sagemath.org/ticket/16261#comment:4
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
You didn't implement <code>linear_combination_of_gens</code>, leaving no way to do that without tripping the warning. Also, you should obviously run the whole testsuite.
</p>
TicketncohenMon, 28 Apr 2014 16:51:04 GMT
https://trac.sagemath.org/ticket/16261#comment:5
https://trac.sagemath.org/ticket/16261#comment:5
<p>
I do not think it is bad to always generate this warning, and I find <code>linear_combination_of_gens</code> far too extreme. I am pretty sure that nobody who really uses this only had inputs in smith form, or he would have given up already.
</p>
<p>
I am running all the tests right now (it found something in ellipti curves already) but it takes times.. And well, we used to have patchbots for this <code>:-P</code>
</p>
<p>
Nathann
</p>
TicketncohenMon, 28 Apr 2014 16:57:27 GMT
https://trac.sagemath.org/ticket/16261#comment:6
https://trac.sagemath.org/ticket/16261#comment:6
<p>
by the way : anybody who used the syntax on purpose will move to <code>.linear_sum_of_smith_generators</code>, and those who wanted the normal sum wrapped everything with "vectors" and will not even see the warning <code>:-P</code>
</p>
TicketgitMon, 28 Apr 2014 18:38:23 GMTcommit changed
https://trac.sagemath.org/ticket/16261#comment:7
https://trac.sagemath.org/ticket/16261#comment:7
<ul>
<li><strong>commit</strong>
changed from <em>cdecd43022a6c78f40655374c3eb804b810483e9</em> to <em>04683ed9d981b1a561163867eee8f63044733fc9</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=04683ed9d981b1a561163867eee8f63044733fc9"><span class="icon"></span>04683ed</a></td><td><code>trac #16261: Default behaviour of AdditiveAbelianGroup(a_tuple)</code>
</td></tr></table>
TicketncohenMon, 28 Apr 2014 18:38:45 GMT
https://trac.sagemath.org/ticket/16261#comment:8
https://trac.sagemath.org/ticket/16261#comment:8
<p>
Now passes all tests except one, see discussion on the sage-support thread.
</p>
<p>
Nathann
</p>
TicketgitMon, 28 Apr 2014 18:45:05 GMTcommit changed
https://trac.sagemath.org/ticket/16261#comment:9
https://trac.sagemath.org/ticket/16261#comment:9
<ul>
<li><strong>commit</strong>
changed from <em>04683ed9d981b1a561163867eee8f63044733fc9</em> to <em>fe241f151b7652552560d0867803309bc3e2f8e0</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=fe241f151b7652552560d0867803309bc3e2f8e0"><span class="icon"></span>fe241f1</a></td><td><code>trac #16261: Default behaviour of AdditiveAbelianGroup(a_tuple)</code>
</td></tr></table>
TicketncohenMon, 28 Apr 2014 18:45:24 GMT
https://trac.sagemath.org/ticket/16261#comment:10
https://trac.sagemath.org/ticket/16261#comment:10
<p>
(all doctests pass !)
</p>
TicketgitMon, 28 Apr 2014 18:46:26 GMTcommit changed
https://trac.sagemath.org/ticket/16261#comment:11
https://trac.sagemath.org/ticket/16261#comment:11
<ul>
<li><strong>commit</strong>
changed from <em>fe241f151b7652552560d0867803309bc3e2f8e0</em> to <em>5d78cfc86f64819c0427941c882015dd2e3df73e</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=5d78cfc86f64819c0427941c882015dd2e3df73e"><span class="icon"></span>5d78cfc</a></td><td><code>trac #16261: Default behaviour of AdditiveAbelianGroup(a_tuple)</code>
</td></tr></table>
TicketncohenMon, 28 Apr 2014 18:46:44 GMTstatus changed
https://trac.sagemath.org/ticket/16261#comment:12
https://trac.sagemath.org/ticket/16261#comment:12
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
TicketnbruinMon, 28 Apr 2014 19:02:48 GMT
https://trac.sagemath.org/ticket/16261#comment:13
https://trac.sagemath.org/ticket/16261#comment:13
<p>
The problem is not quite introduced by this change, but this change does make the problem a little more visible: Why are you singling out <code>Z/2Z x Z/3Z</code> as a group that can be explicitly represented and not
<code>Z^2/ span( [1,1],[-1,5])</code>, with generators the classes of the standard basis?
</p>
TicketncohenMon, 28 Apr 2014 19:54:22 GMT
https://trac.sagemath.org/ticket/16261#comment:14
https://trac.sagemath.org/ticket/16261#comment:14
<p>
Yooooooooo !
</p>
<blockquote class="citation">
<p>
The problem is not quite introduced by this change, but this change does make the problem a little more visible: Why are you singling out <code>Z/2Z x Z/3Z</code> as a group that can be explicitly represented and not
<code>Z^2/ span( [1,1],[-1,5])</code>, with generators the classes of the standard basis?
</p>
</blockquote>
<p>
Do I misunderstand your question or are you saying that you would like to use any base you like instead of (1,0),(0,1), or the smith form ?
</p>
<p>
I just need this new form for a couple of things I am implementing... But I am afraid of having to touch these files myself, because I have a good idea of what I forgot about groups since I began a PhD in graph theory... and it scares me <code>:-D</code>
</p>
<p>
Nathann
</p>
TicketnbruinTue, 29 Apr 2014 00:17:19 GMT
https://trac.sagemath.org/ticket/16261#comment:15
https://trac.sagemath.org/ticket/16261#comment:15
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/16261#comment:14" title="Comment 14">ncohen</a>:
</p>
<blockquote class="citation">
<p>
Do I misunderstand your question or are you saying that you would like to use any base you like instead of (1,0),(0,1), or the smith form ?
</p>
</blockquote>
<p>
Basically, yes. The problem is that presently, <a class="missing wiki">AdditiveAbelianGroup?</a> is a little too lax in what it accepts as "invariants". In the classification of (finite) abelian groups, the "invariants" <code>[a1,a2,...,ar]</code> are subject to the additional condition that <code>ai</code> divides <code>a(i+1)</code>. Otherwise they aren't really invariants.
</p>
<p>
If you're going to allow abelian groups to be specified in forms different from smith normal form, I think it's a little strange to just limit to these "diagonal" forms. In general, you specify a finitely generated abelian group using generators and relations, i.e., <code>ZZ^r</code> modulo some submodule. Since the underlying machinery is that of ZZ-modules anyway, why not do it properly?
</p>
TicketncohenTue, 29 Apr 2014 06:55:25 GMT
https://trac.sagemath.org/ticket/16261#comment:16
https://trac.sagemath.org/ticket/16261#comment:16
<p>
Yoooooooooooo !
</p>
<blockquote class="citation">
<p>
If you're going to allow abelian groups to be specified in forms different from smith normal form, I think it's a little strange to just limit to these "diagonal" forms. In general, you specify a finitely generated abelian group using generators and relations, i.e., <code>ZZ^r</code> modulo some submodule. Since the underlying machinery is that of ZZ-modules anyway, why not do it properly?
</p>
</blockquote>
<p>
Ahahaah. Very simple : I have no idea how. I already said that I didn't feel at ease editing group code, so if you want anything more general than what is in the branch, I'm sorry to say that you will have to write the code yourself <code>:-)</code>
</p>
<p>
And I agree with you that more bases should be allowed indeed.
</p>
<p>
Oh, and if you have any idea of how to make Sage see <code>G = GF(8,'x').cartesian_product(GF(5))</code> as a group, it would be cool by the way.
</p>
<pre class="wiki">sage: G([1,1])+G([1,1])
TypeError: unsupported operand type(s) for +: 'CartesianProduct_with_category.element_class' and 'CartesianProduct_with_category.element_class'
</pre><p>
God.. These things are SO broken :
</p>
<pre class="wiki">sage: list(G)
AttributeError: 'CartesianProduct_with_category' object has no attribute 'list'
</pre><p>
Perhaps this is the problem :
</p>
<pre class="wiki">sage: g=GF(8,'x')
sage: g.category()
Category of finite fields
sage: gg=g.cartesian_product(g)
sage: gg.category()
Category of Cartesian products of monoids
</pre><p>
This <code>gg</code> should be a product of groups I guess...
</p>
<p>
Nathann
</p>
Ticketvbraun_spamTue, 06 May 2014 15:20:58 GMTmilestone changed
https://trac.sagemath.org/ticket/16261#comment:17
https://trac.sagemath.org/ticket/16261#comment:17
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.2</em> to <em>sage-6.3</em>
</li>
</ul>
TicketrwsSun, 18 May 2014 16:46:54 GMTwork_issues set
https://trac.sagemath.org/ticket/16261#comment:18
https://trac.sagemath.org/ticket/16261#comment:18
<ul>
<li><strong>work_issues</strong>
set to <em>merge conflict</em>
</li>
</ul>
TicketgitSun, 18 May 2014 18:36:04 GMTcommit changed
https://trac.sagemath.org/ticket/16261#comment:19
https://trac.sagemath.org/ticket/16261#comment:19
<ul>
<li><strong>commit</strong>
changed from <em>5d78cfc86f64819c0427941c882015dd2e3df73e</em> to <em>c1858741b33741bac325cf96a8166712273151bf</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=c1858741b33741bac325cf96a8166712273151bf"><span class="icon"></span>c185874</a></td><td><code>trac #16261: Merged with 6.3.beta1</code>
</td></tr></table>
TicketncohenSun, 18 May 2014 18:36:22 GMTwork_issues deleted
https://trac.sagemath.org/ticket/16261#comment:20
https://trac.sagemath.org/ticket/16261#comment:20
<ul>
<li><strong>work_issues</strong>
<em>merge conflict</em> deleted
</li>
</ul>
<p>
Fixed.
</p>
<p>
Nathann
</p>
TicketrwsMon, 19 May 2014 06:03:24 GMTstatus changed
https://trac.sagemath.org/ticket/16261#comment:21
https://trac.sagemath.org/ticket/16261#comment:21
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<pre class="wiki">sage -t --long src/sage/combinat/designs/database.py # 4 doctests failed
sage -t --long src/sage/combinat/designs/orthogonal_arrays.py # 2 doctests failed
</pre>
TicketncohenMon, 19 May 2014 07:59:21 GMT
https://trac.sagemath.org/ticket/16261#comment:22
https://trac.sagemath.org/ticket/16261#comment:22
<p>
Not on my computer.... Can you tell me which doctests fail ?
</p>
<p>
Nathann
</p>
TicketrwsMon, 19 May 2014 08:47:32 GMTattachment set
https://trac.sagemath.org/ticket/16261
https://trac.sagemath.org/ticket/16261
<ul>
<li><strong>attachment</strong>
set to <em>doctest.txt</em>
</li>
</ul>
<p>
log of doctest fails
</p>
TicketrwsMon, 19 May 2014 08:48:34 GMT
https://trac.sagemath.org/ticket/16261#comment:23
https://trac.sagemath.org/ticket/16261#comment:23
<p>
Log is attached. Hope you tested 6.3.beta1.
</p>
TicketncohenMon, 19 May 2014 09:01:09 GMTstatus changed
https://trac.sagemath.org/ticket/16261#comment:24
https://trac.sagemath.org/ticket/16261#comment:24
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
Sorry, the reason was more stupid than that : I had forgotten to recompile.
</p>
<p>
Btw, do you plan on reviewing all the tickets you set to <code>needs_work</code> ?
</p>
<p>
Nathann
</p>
TicketgitMon, 19 May 2014 09:01:59 GMTcommit changed
https://trac.sagemath.org/ticket/16261#comment:25
https://trac.sagemath.org/ticket/16261#comment:25
<ul>
<li><strong>commit</strong>
changed from <em>c1858741b33741bac325cf96a8166712273151bf</em> to <em>890c448ad9ea547feb778b5f8e69f6bbac452f1d</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=890c448ad9ea547feb778b5f8e69f6bbac452f1d"><span class="icon"></span>890c448</a></td><td><code>trac #16261: Broken doctests</code>
</td></tr></table>
TicketrwsMon, 19 May 2014 09:06:20 GMT
https://trac.sagemath.org/ticket/16261#comment:26
https://trac.sagemath.org/ticket/16261#comment:26
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/16261#comment:24" title="Comment 24">ncohen</a>:
</p>
<blockquote class="citation">
<p>
Btw, do you plan on reviewing all the tickets you set to <code>needs_work</code> ?
</p>
</blockquote>
<p>
No.
</p>
Ticketvbraun_spamSun, 10 Aug 2014 16:51:03 GMTmilestone changed
https://trac.sagemath.org/ticket/16261#comment:27
https://trac.sagemath.org/ticket/16261#comment:27
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.3</em> to <em>sage-6.4</em>
</li>
</ul>
TicketncohenSat, 16 Aug 2014 13:49:59 GMTcc changed
https://trac.sagemath.org/ticket/16261#comment:28
https://trac.sagemath.org/ticket/16261#comment:28
<ul>
<li><strong>cc</strong>
<em>tscrim</em> added
</li>
</ul>
<p>
Yo Travis ! Now it is my turn <code>:-)</code>
</p>
<p>
Nathann
</p>
TickettscrimSat, 16 Aug 2014 17:41:30 GMTbranch, commit changed; reviewer set
https://trac.sagemath.org/ticket/16261#comment:29
https://trac.sagemath.org/ticket/16261#comment:29
<ul>
<li><strong>reviewer</strong>
set to <em>Travis Scrimshaw</em>
</li>
<li><strong>branch</strong>
changed from <em>u/ncohen/16261</em> to <em>public/groups/additive_abelian_groups_tuples-16261</em>
</li>
<li><strong>commit</strong>
changed from <em>890c448ad9ea547feb778b5f8e69f6bbac452f1d</em> to <em>36cf5008dd7712178b5b96ef38b9eb8518c7ddfb</em>
</li>
</ul>
<p>
Hey Nathann,
</p>
<p>
I gave the <code>short_repr</code> more functional-type and cleaner (IMO) implementation. I've also made some lines shorter and made line breaks at more logical positions.
</p>
<p>
As for finding the orders of the original cyclic groups in <code>short_repr</code>, I think the current implementation is okay for now. You could make this data into a (cached) method, but IDK if this is worthwhile or useful for anyone. A "better" fix would be to pass this data from the factory function to the class, but you should deal with handling old pickles which don't (a priori) contain this part of the class's input.
</p>
<p>
So in the end, if you're okay with my changes, then positive review.
</p>
<hr />
<p>
New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=aa17e43fe1097a6d9e2ef504544a81bb78e92b1a"><span class="icon"></span>aa17e43</a></td><td><code>Merge branch 'u/ncohen/16261' of trac.sagemath.org:sage into public/groups/additive_abelian_groups-16261</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=36cf5008dd7712178b5b96ef38b9eb8518c7ddfb"><span class="icon"></span>36cf500</a></td><td><code>Better IMO short_repr method and made some lines shorter/logically line broken.</code>
</td></tr></table>
TicketncohenSat, 16 Aug 2014 19:11:14 GMTstatus changed
https://trac.sagemath.org/ticket/16261#comment:30
https://trac.sagemath.org/ticket/16261#comment:30
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
</ul>
<p>
Looks good ! Thank you for that. It is risky to touch combinat/designs/database.py these days but hopefully this won't conflict with anything as you only modify function at the middle of the code <code>:-P</code>
</p>
<p>
Thanks for your help !
</p>
<p>
Nathann
</p>
TicketvbraunMon, 18 Aug 2014 14:54:20 GMTstatus, branch changed; resolution set
https://trac.sagemath.org/ticket/16261#comment:31
https://trac.sagemath.org/ticket/16261#comment:31
<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>public/groups/additive_abelian_groups_tuples-16261</em> to <em>36cf5008dd7712178b5b96ef38b9eb8518c7ddfb</em>
</li>
</ul>
TicketjhpalmieriWed, 27 Aug 2014 18:18:20 GMTcommit deleted
https://trac.sagemath.org/ticket/16261#comment:32
https://trac.sagemath.org/ticket/16261#comment:32
<ul>
<li><strong>commit</strong>
<em>36cf5008dd7712178b5b96ef38b9eb8518c7ddfb</em> deleted
</li>
</ul>
<p>
A question: with the old behavior, I could do
</p>
<pre class="wiki">G = AdditiveAbelianGroup([0,0])
G(a)
</pre><p>
and have it return something sensible (and the <em>same</em> thing) whether <code>a</code> was a vector, a list, a tuple, or an element of <code>G</code>. This now gives a deprecation warning if <code>a</code> is a list or tuple. On the other hand
</p>
<pre class="wiki">G.linear_combination_of_smith_form_gens(a)
</pre><p>
gives an outright error if <code>a</code> is an element of <code>G</code>. Should I do
</p>
<pre class="wiki">G(vector(a))
</pre><p>
to recover this behavior?
</p>
TicketvbraunWed, 27 Aug 2014 18:32:13 GMT
https://trac.sagemath.org/ticket/16261#comment:33
https://trac.sagemath.org/ticket/16261#comment:33
<p>
I think you only got the <em>same</em> thing by coincidence, the Smith form generators happened to be chosen equal to the given basis. But we didn't make any guarantees that this was so, and for more complicated groups you'd be in for a surprise.
</p>
TicketjhpalmieriWed, 27 Aug 2014 18:48:14 GMT
https://trac.sagemath.org/ticket/16261#comment:34
https://trac.sagemath.org/ticket/16261#comment:34
<p>
So if I'm working with free abelian groups, there is no way to guarantee that <code>G(a)</code> will return the same thing if <code>a</code> is the tuple (1,2), the list [1,2], the vector (1,2), or the group element (1,2)?
</p>
TicketvbraunWed, 27 Aug 2014 19:27:38 GMT
https://trac.sagemath.org/ticket/16261#comment:35
https://trac.sagemath.org/ticket/16261#comment:35
<p>
<code>G(vector(a))</code> should work, I think. Do you want linear combinations of Smith form generators or linear combinations of given generators (if the group doesn't happen to be free)?
</p>
TicketjhpalmieriWed, 27 Aug 2014 19:56:56 GMT
https://trac.sagemath.org/ticket/16261#comment:36
https://trac.sagemath.org/ticket/16261#comment:36
<p>
For my particular uses, I only want to work with free groups. If I happened to have a non-free group, I think I would want linear combinations of given generators.
</p>
TicketrbeezerWed, 20 May 2015 19:57:18 GMT
https://trac.sagemath.org/ticket/16261#comment:37
https://trac.sagemath.org/ticket/16261#comment:37
<p>
I bumped into this doctesting Judson's Abstract Algebra book.
</p>
<pre class="wiki">G = AdditiveAbelianGroup([14])
b = G([2])
</pre><p>
was fine for the novices, but <code>b = G(vector([2]))</code> looks more complicated than necessary.
</p>
<p>
Anybody on this ticket have a better idea? I mean besides me ever getting my act together on <a class="needs_info ticket" href="https://trac.sagemath.org/ticket/9773" title="enhancement: Abelian groups (needs_info)">#9773</a>.
</p>
TicketncohenWed, 20 May 2015 20:00:14 GMT
https://trac.sagemath.org/ticket/16261#comment:38
https://trac.sagemath.org/ticket/16261#comment:38
<blockquote class="citation">
<p>
was fine for the novices, but <code>b = G(vector([2]))</code> looks more complicated than necessary.
</p>
</blockquote>
<p>
What do you mean? <code>G([2])</code> works in the latest release, and it will stay this way: we will only remove the *warning* in several months.
</p>
<p>
The meaning of the command changed, but the command itsels will remain available.
</p>
<p>
Nathann
</p>
TicketrbeezerWed, 20 May 2015 21:06:33 GMT
https://trac.sagemath.org/ticket/16261#comment:39
https://trac.sagemath.org/ticket/16261#comment:39
<p>
OK, I understood the warning to mean behavior was changing and students were going to need to do some sort of linear combination drill. (Yes, I did skim through this ticket.) And of course the warning gets in the way for doctesting, but I know how to work around that cleanly.
</p>
<p>
Thanks very much for the quick and helpful reply, Nathann.
</p>
<p>
Rob
</p>
Ticket