#15348: "R.<a> =" syntactic sugar incorrect for EquationOrder
-------------------------------------+-------------------------------------
Reporter: emassop | Owner:
Type: defect | Status: needs_review
Priority: major | Milestone: sage-7.0
Component: number fields | Resolution:
Keywords: | Merged in:
Authors: Jeroen Demeyer | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/jdemeyer/ticket/15348 | 64618f5c8b5ac24ccc688ac718ee2b43e42d0328
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by emassop):
Some comments on the docstring of `_defining_names`:
* There is a test for orders, which have this method overridden, so I
think it would be better to move this test.
* I'm not sure about the example "For vector spaces and free modules, we
get a basis", given that submodules normalize the basis they are given as
input, so that `_defining_names` does not necessarily return the basis
that the submodule was defined with. For instance
{{{
V = ZZ^3
vectors = [(0,1,0), (1,3/2,0)]
M = V.span(vectors)
print M.basis()
}}}
prints
{{{
[
(1, 1/2, 0),
(0, 1, 0)
]
}}}
Could you mention something like this as a caveat for this method? Or
perhaps get rid of this example, given that this method really only is
interesting for things defined by some explicitly named elements?
* Please get rid of "generator" and perhaps mention the `names` argument
used by `R.<...> =`
Otherwise, this all looks good to me.
--
Ticket URL: <http://trac.sagemath.org/ticket/15348#comment:42>
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 https://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
