On Fri, Aug 19, 2011 at 2:25 PM, Nils Bruin <nbr...@sfu.ca> wrote: > On Aug 19, 12:26 pm, Jason Grout <jason-s...@creativetrax.com> wrote: >> On 8/19/11 1:45 PM, Robert Bradshaw wrote: >> >> > [a, b; c, d].change_ring(QQ) > > You'd have to take care that > > [1.000000000000000000000001, 1.0; 2.0, > 3.0].change_ring(RealField(100)) > > doesn't lose precision on the way, which suggests that "[;]" syntax > should result in a "matrix literal".
That would greatly complicate things, I'd rather the syntactic sugar stay simple. I don't see it as being any worse than sage: (x + 1.00000000000000000001).change_ring(RealField(100)) x + 1.0000000000000000000101643954 If one cares about the basering that much, use the normal matrix constructor. >> What if I want a 1-row matrix. Will this work? >> >> [a,b,c,d] > > In analogy to (a,) being a singleton, this should probably be > [a,b,c,d;] +1 >> But then what about: >> >> [1, 2, >> 3, 4] -1. I don't think we should treat newlines specially. >> From the previous messages (where newlines are treated like >> semicolons), that should be a square 2x2 matrix, but again, it is valid >> python syntax. > > Hence, I don't think a preparser based solution should support this. > Saving the "..." comes at the cost of having to type the ;s > > Also note that once we're doing this, we should probably also support > matrices over matrices, so > > [ [1,2;3,4] , [5,6;7,8]; [9,10;11,12], [13,14;15,16]] > > should also be supported (just because your grammar specification will > be a horribly ugly mess if you want to disallow this construct). > This basically means that the preparser actually has to parse its > input (http://en.wikipedia.org/wiki/ > Pumping_lemma_for_regular_languages can be used that parenthesis > matching cannot be done using regular languages, although some modern > "regex" implementation might have features for it). I don't see a compelling reason to support it. For better or for worse, "Un-preparsed sage" doesn't really have a grammar. It's more like the C preprocessor that does textual substitutions before the real parser takes effect. (Not that the C preprocessor isn't a horrendous hack, but writing C without it would be even worse. :-) That being said, counting brackets would suffice without needing to do a full parsing. (String literals are already stripped at this point.) > Matrices over matrices are weakly supported presently: > > sage: M=matrix(2,2,[1,2,3,4]) > sage: A=matrix(2,2,[M,M,M,M]) > sage: B=A^2 > sage: B[0,0] > [14 20] > [30 44] > sage: M*M+M*M #that's what the entry should be > [14 20] > [30 44] > > but pretty much anything else fails (including printing these objects, > because printing apparently needs hash(M)) > > Independent of the example above, nested matrix literals could happen > anyway: > > [ 1, 2; 3, det( [4,1;0,1]) ] > > -- > 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
