On Thu, Jan 26, 2012 at 3:08 PM, Tom Boothby <tomas.boot...@gmail.com> wrote: > 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.
I'm not extremely concerned about efficiency. These are literal matrices after all, so presumably someone's typing them in by hand. (If they're programmatically generated, construct the matrix directly or vai a better constructor if you're worried about efficiency. Conversion of ZZ to QQ is much faster than the parsing or even str -> ZZ in the first place). But if the basering can be worked into the original constructor, that's a plus. It'd be nice to be able to pass arbitrary keywords into the constructor for the same reason. > 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. It's much simpler (technically and conceptually) to pick out the ring if it lies entirely in the brackets. I'd go for a colon over # or @. - 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
