On Thu, Jan 26, 2012 at 2:36 PM, Robert Bradshaw <rober...@math.washington.edu> wrote: > On Thu, Jan 26, 2012 at 1:51 PM, Michael Orlitzky <mich...@orlitzky.com> > wrote: >> On 01/26/12 16:36, William Stein wrote: >>>> >>>> Why *not* use it? >>> >>> The standard argument against preparser stuff like this is that you >>> have to be careful to not use it when writing .py code for the Sage >>> core library. But at least this matrix notation will always result >>> in a SyntaxError if used in Python code. >> >> A better reason is that, once implemented, someone has to maintain it >> forever. >> >> This is a fairly invasive preparse, and will likely cause more than a >> few bugs (see implicit multiplication for examples). > > I'd say it's a fairly simple preparse. The only tricky part is > multi-line handling in the face of iPython (where each line needs to > be pre-parsed individually, and that IMHO should be handled better at > a higher level where we buffer lines until we have a complete > statement and then preparse them as a whole). In any case, I'm willing > to maintain it for the next 5 years (which I expect will be trivial). > >> It also risks suggesting that sage matrices behave like Matlab ones, which >> could cause confusion. > > Or suggest they behave like Pari matrices which use the same syntax, > but I don't think that's any more of an issue than say integers or > division in Matlab vs Sage. > >> Furthermore, some preparses are mutually exclusive: if you implement >> this one now, and Mathematica comes out with a killer feature a year >> from now using similar syntax ([do; my; homework; for; me;]), you can't >> preparse that. > > If we found such a feature useful, we probably wouldn't try to embed > it into our syntax. > >> Some preparses are worth it, obviously; I wouldn't throw them both out >> because they might conflict with one another. But the bar for inclusion >> should be pretty high. > > I totally agree with you here, the bar for adding to the preparser > should be high. I think it's a good candidate here because (1) It's > easy to understand what it means (2) it's illegal Python syntax, and > (3) Python doesn't even have the notion of matrices, so it's doubly > clear (perhaps once you get the SyntaxError) that it's a Sage-only > feature. > > > > On Thu, Jan 26, 2012 at 12:30 PM, Tom Boothby <tomas.boot...@gmail.com> wrote: >> On Thu, Jan 26, 2012 at 12:09 PM, Jason Grout >> <jason-s...@creativetrax.com> wrote: >> >>> Another option would be: >>> >>> [QQ: 1,2,3; 4,5,6] >> >> QQ:1 is a slice... >> >>> or, as Robert suggests: >>> >>> [1,2,3; 4,5,6, base_ring=QQ] -- but then it looks like base_ring=QQ is >>> another element. >> >> assignments aren't literals... but I don't like this. >> >> My thought for R[1,2,3;4,5,6] is that just as we preparse >> >> '[1..2]' to 'ellipsis_range(Integer(1),Ellipsis,Integer(2))', we'd preparse >> >> '[1,2,3;4,5,6]' to 'matrix_literal((1,2,3),(4,5,6))' >> >> where >> >> Ring.__getitem__(self, x) >> >> could have a fast option for matrix literals -> matrices. > > Interesting idea, but then we'd have to detect whether the brackets > were creating a list vs. acting as an index operator and prepares > differently in the two situations lest we have R[...;...] -> > R[matrix_literal(...)] forcing [...;...] -> [matrix_literal(...)], a > list of one item.
Yeah, I had my doubts about that, too. Perhaps R[[...;...]] would be better, but I'm not really happy with this either. > One also has [a, b; c, d].change_ring(R). The exact notation for > specifying the basering can be deferred, though it does highlight the > importance of choosing a default according to the "principle of least > surprise." I'd like whatever notation we arrive at to be efficient. If we preparse RDF[1,2,3;4,5,6] -> Matrix(RDF,[[Integer(1),Integer(2),...]]) or use [...;...].change_ring(R) then we're gonna waste a lot of time, creating useless Integers and / or computing a common parent. What of a new keyword, [1,2...;...] over R -> Matrix(R,[[R(1),R(2)...],[...]]) or perhaps something like [R$1,2,3;4,5,6] or [1,2,3;4,5,6]@R I'm not particularly attached to any idea. > > - 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 -- 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
