On Sun, Mar 1, 2009 at 12:26 PM, William Stein <wst...@gmail.com> wrote: > On Fri, Feb 13, 2009 at 2:34 AM, Robert Bradshaw > <rober...@math.washington.edu> wrote: >> >> I have written up extensive documentation on the coercion model at >> http://wiki.sagemath.org/coercion . If you find coercion baffling, >> confusing, or unuseful, this is especially for you. I am sure there >> is lots of room for improvement, as what may be obvious to me can be >> far from obvious to those less familiar with the system. This is >> intended to be the guide to using coercion--for deeper implementation >> details see the docstrings in the coerce.pyx (100% coverage) and >> related files. >> >> Eventually, this should all be moved to the reference manual and/or >> programing guide, but I figured the wiki was the best place to put it >> at the moment. Comments welcome. >> >> - Robert > > I was just looking at this from the context of implementing quaternion > algebras (again) using this framework. It's actually striking how > most of the code in Sage does not use the new coercion framework. > The vast majority of rings and other objects in Sage still use the old > framework. E.g., there are 88 uses of the deprecated _coerce_impl and > there are only about 12 uses of the new _populate_coercion_list > replacement. Because it hasn't got used so much in Sage, maybe the > new coercion model implementation probably has a lot of kinks to be > worked out, and people will likely run into these when trying to > implement classes that use it. > > For example, I tried to get pickling of quaternion algebras to work -- > and it won't if I use > > self._populate_coercion_lists_(coerce_list=[base_ring]) > > in my code. It gave "weird errors" unless I comment it out, so I > checked around Sage (e.g., in free modules) for any other uses of this > pretty natural obvious use of populate_coercion_list in any deployed > code. There are 2 or 3 instances in all Sage of this. Not enough to > educate me. > > Just out of curiosity, given a parent R and an element x, how do I > even do what used to be > > R._coerce_impl(x) > > i.e., do canonical coercion or give an error? The simplest thing I > could come up with is: > > from sage.all import parent # horrid (since I'm lazy at the moment) > foo =R.convert_map_from(parent(x)) > if not foo: raise TypeError > return foo(x) > > Anyway the point of this email is that a cursory inspection suggests > that the new coercion model has only been pushed out to maybe 10% of > the parent structures in Sage. Is this true? Why isn't the rest > done? I feel like if (1) there were good documentation and (2) no > bugs (like the pickling issues I'm hitting), then it would be very > easy to push the new coercion model as you've designed it all over in > Sage. It was hell on earth last year to do that because people tried > to do everything at once. But given your superb evolutionary > approach, I think now it should be easy. > > SUMMARY: I want coercion to get pushed throughout Sage, but I feel > like you need to write a very clear honest status report about what > the situation is now. > > 1. *Precisely* how much of the new coercion model has actually been > transitioned to in Sage now? > > 2. *Precisely* how much remains? > > 3. What's a list of 5 (say) parent structures where transitioning to > the new coercion model would be very easy?
In case the tone of my post is unclear, after working with the new coercion system that you implemented, I have to say that it is really *really* beautiful, and the main reason I'm complaining about it being pushed out much more throughout Sage is that I like it so much and want to see it used everywhere :-). William --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
