On Thu, Jan 26, 2012 at 3:21 PM, Robert Bradshaw <rober...@math.washington.edu> wrote: > 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.
Fair enough. > (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 @. Another issue: do we allow [1..10; 10..20]? I can't seem to construct matrices with matrix entries (this is not absurd) -- but should the preparser grok it? [[1..10; 10..20] ; [2..12; 14..24]] > > - 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
