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)]." - Robert -- 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
