On Wednesday, June 17, 2015 at 7:48:15 AM UTC-7, Darij Grinberg wrote: > > Unfortunately, currently the ducktyping is not just in the matrix > constructor; it is split across the three stations I mentioned (matrix > constructor, matrix space, matrix class). Apparently every single of > our matrix classes has its own way of recognizing "scalar matrix" > input (that very matrix(n, n, c) syntax that has caused the present > discussion), apparently written by different people (since the error > messages differ). I suspect there is no way for sufficiently generic > code to sidestep all of the ducktyping at the present time, and this > is just bad. >
Unfortunately, this is invited by the design of sage: The "__call__" entry on a parent is the main interface to element construction and since this is "conversion", all kinds of wild input are allowed. Do we have a default place where a rigid-interfaced element constructor goes? Would providing one improve the situation? I suspect not, since that just adds another corridor to the maze. > Oddly enough, it's matrix(n,m,<callable>) that's the hard signature to > > recognize there. > > It is the harder one, but it is also the saner one in my opinion. > Nevertheless, there is nothing wrong with making it explicit as > Matrix.from_callable(n, m, <callable>) (or "from_function" or > "from_family", depending on how we want to call it). > Perhaps sane, but also hardly necessary. One can immediately rewrite matrix(n,m,f) -> matrix(n,m,[f(i,j) for i in range(n) for j in range(m)]) In principle, matrix(n,m,f) could be a little more efficient than the rewrite because it could avoid making the intermediate list, but in practice that's hardly a noticeable cost and currently the code doesn't take advantage of this. > > Once the basic constructors have been implemented, is there a way to > discourage people from using the ducktyped matrix constructor *in the > Sage library*? Some kind of warnings that appear only in doctest mode > and tell you what basic constructors should be used? > > > [1] matrix([ring],n,n,<scalar>) > > [2] matrix([ring],n,m,<callable>) > > [3] matrix([ring],[n,[m]],<iterable>) > > [4] matrix([ring],[n,[m]],<iterable producing iterables>) > > Also matrix([ring], n[, m]]) to return a zero matrix, and > matrix(various kinds of objects). And [3] involves some case analysis, > since the iterable can be a dictionary but can also be a flattened > list of entries. > Ah, correct. So there is a further one: [5] matrix([ring],[n,[m]],<mapping type>) which should take precedence over [3] and [4] Luckily polynomials, while allowing indexing, don't implement the full Mapping protocol, so at least they won't interfere with [5]. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
