On Thu, Jan 26, 2012 at 3:51 PM, Tom Boothby <tomas.boot...@gmail.com> wrote: > 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]?
We probably shouldn't go to extra effort to support it. > 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]] Yes, for sure. And [[1..10; 10..20].det() ; [2..12; 14..24].det()] - 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
