On Friday, June 19, 2015 at 9:10:41 AM UTC-7, Darij Grinberg wrote: > > > 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. > > I think this is the main design mistake here. > > > 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. > > I am used to such constructors being implemented in methods that begin > with "from_" (such as "from_permutation", "from_scalar", etc.). > Probably not really standardized, but still better than everything > heaped together in one method. >
But that would be a design that could work, right? Have constructors with well-defined signatures on the parent and have the generic "__call__" dispatch over them using heuristics and guessing and whatnot. "matrix" on top of that would have, in addition, heuristics for constructing the appropriate parent to dispatch to. We'd still need to document better (and more accurately!) what the heuristics are that the conversions and "matrix" use, and in what precedence, but then we'd have both: a clean way of generating elements without any guessing as to what the entries mean *and* a convenience method that, contrary to the Zen of Python, guesses whenever it can. > > 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)]) > > One can, but does one want to? > We need the second one, since using this transformation the other way around really is less efficient. The interface gets cluttered by supporting both, is there is a gain by supporting only one. By that argument, I would say "yes". If you're coming from LISP or functional languages, the form matrix(n,m,f) looks natural and concise. The reality is that in Python, list comprehensions and iterators/generator expressions are much better supported. So the second form, or properly using iterators: matrix(n,m,(f(i,j) for i in range(n) for j in range(m))) would be preferable. Especially because most of the time, the expression that gets wrapped in "f" is a one-off "lambda" expression. The "lambda" can be omitted in the generator expression and will execute much more efficiently (since function calls in python are very expensive). That said, I would not advocate actually removing the option to specify the entries via a callable. I don't think it really gets in the way. I would not particularly advertise its use, though. What is the full Mapping protocol? Is it this? > https://docs.python.org/2/library/collections.html#collections.Mapping > The doc doesn't make me much wiser. What Sage types implement this > protocol, or claim to? Yes, I had trouble finding a proper definition too. The code defining collections.Mapping helps a little, but it would be nice to see explicitly listed what constitutes the Mapping protocol. In practice, you can get Python's view of things by asking isinstance(...,collections.Mapping) > Also, I don't think we can assume that elements of a ring don't > implement some protocol, whatever the protocol is. Free module > elements, for example, are fairly good at pretending to be vectors > and/or dictionaries. So... perhaps we should first define behaviour in terms of actual typechecks and classes we can do on sage types and only rely on behaviour dependent on protocols once we've found nothing applies. In practice we can still speed certain common things up by shortcutting when we find that something really has type "list" or "tuple" (but I guess not subtypes of those, since for those in principle the sage type information could take precedence). -- 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.
