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. 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." - 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
