On 8/18/11 12:29 AM, Robert Bradshaw wrote:
On Wed, Aug 17, 2011 at 8:15 PM, Jason Grout
<jason-s...@creativetrax.com> wrote:
On 8/17/11 10:02 PM, Nils Bruin wrote:
On Aug 17, 5:45 pm, Dan Drake<dr...@kaist.edu> wrote:
This is now #11699:http://trac.sagemath.org/sage_trac/ticket/11699
I agree with Rob; this probably should be in matrix(), and not in the
preparser.
Are you thinking of having matrix(s) [with s a string] being
equivalent to
matrix([[eval(a) for a in r.strip().split(" ")] for r in
s.split(";")])
or something like that? It probably needs some cleaning to be tolerant
of more types of whitespace (perhaps it should also accept commas?)
and perhaps it should handle a "\n" as a ";".
I've added example code to the ticket. Here is the current iteration:
# if a was the string passed in as the list of elements
a=a.replace(',', ' ').replace(';','\n') # or a.translate(s)
rows = a.split('\n')
# throw away empty rows
rows = [r for r in rows if r.strip()]
elements=[map(sage_eval, r.split()) for r in rows]
# now continue matrix processing with "elements" as the list of elements
Or if we could afford to initialize something at the module level, we'd
initialize this:
import string
s=string.maketrans(';,','\n ')
and replace the first line above with:
a=a.translate(s)
The bigger problem is: How do you convert the strings representing
matrix entries to sage? What is going to be the base ring of the
matrix? This determines what to use instead of the "eval" above. Such
problems do not arise in Matlab because of the more limited scope: the
only numerical type is a float (double probably). In Sage it is not so
easy.
This would be determined by the other arguments to matrix.
Yes, this code is already there.
I'm proposing
that the string would just take the place of the normal nested list of
entries, wherever it is, and would be interpreted as if they had typed in a
normal nested list of entries (using sage_eval). Thus, the string would be
converted to a nested list at the top of the matrix constructor function.
To throw my 2 cents in, I'm not opposed to expanding the preparser to
handling [a, b; c, d] as matrix literals. Accepting strings is nice,
but not as natural (e.g. one looses tab completion and errors are much
more indirect). Splitting on spaces is error prone (e.g. "1 + sin(x)")
and so is naively splitting on commas [1, 2; pi, f(3, 4)]."
Good point. It turns out to be much harder if we don't just assume
numbers. I guess one way to do it would be to construct a parse tree
using the python parsing, except, of course, that semicolons make [1 2
3; 4 5 6] not valid syntax, though I suppose we could replace semicolons
and newlines with "][" and then filter out empty lists. Spaces also
would be problem in constructing a parse tree, since [1 2] isn't valid
syntax.
So yeah, expanding the preparser for this very common situation (easily
creating a doubly-nested list) is starting to look more like a good idea.
If we expanded the preparser, would [1 2; 3 4] create a matrix or just a
doubly-nested list? I can see arguments both ways, and this is where
Nils point really hits home. Almost always, I want matrices over QQ,
but [1 2; 3 4] won't naturally create a matrix over QQ. On the other
hand, typing matrix(QQ, [1 2; 3 4]) seems to take the fun out of the
syntax, since it's not too much easier than matrix(QQ, [[1,2], [3,4]])
Jason
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
