On Mar 1, 2009, at 9:26 AM, William Stein 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.
I think most of the kinks have been worked out, but as you mention, there's not a huge amount of coverage so far. > 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. Not sure why this isn't working, but as you mentioned, defining a reduce method does solve the problem. > 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) R.coerce(x) In general, the underscore methods are meant to be implemented, not called. > 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 think the main reasons are that I spent a lot of time last summer doing coercion, to the exclusion of getting other stuff done, so I haven't been working on it as consistently. Also, some of my patches have sat in trac for a long time (partially due to (1) below, but thanks to those of you who stepped up and looked at them). Also, due to (1), I don't think others have worked on it much. > I feel like if (1) there were good documentation and Hopefully I've somewhat resolved this > (2) no bugs (like the pickling issues I'm hitting), and I'll try to be quick in case any come up on this front > 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. I think another issue was that the coercion branch became the place for all experimental, invasive architectural changes to Sage (generators, categories, reworking the generic cmp, etc.) which exacerbated the nightmare of it not being evolutionary. > 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? Z, Q, R, and C (all models) are fully using the new coercion model. Univariate polynomial rings and number fields do as well. Also, fraction fields, and perhaps a couple of others. I'm in the process of doing finite fields. Would it be helpful if I did a couple of easy cases (that people could look to for examples) first? > 2. *Precisely* how much remains? I would say that aside from the above, what remains are mostly easy cases. The only really hard case I see is multi-variate polynomial rings. Also, it depends a lot on how old stuff is. Newer code converts over much nicer... Often, when I work on coercion, I end up fixing a lot of other cruft as well, or making it more flexible (e.g. embeddings) which makes it take longer. The sage-combinat group seems very informed about the new coercion, so I see that being completely off the old stuff soon. > 3. What's a list of 5 (say) parent structures where transitioning to > the new coercion model would be very easy? Modules should be relatively easy to do, for someone who understands the current code. (I didn't touch it because I've been hearing rumors of a rewrite for a while). sage/schemes/elliptic_curves/ monsky_washnitzer should be easy, as should sage/structure/ formal_sum. sage/rings/infinity should be trivial, as shold power series rings and laurent series (though I think Craig Citro has done a lot of improvement to those files lately, not sure if it's in yet). If we're not completely moved over by SD15, perhaps we could have a coercion evening where everyone picks their favorite Parent and moves it over. This could clean up a lot of the odds and ends. > 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 :-). Thanks. - Robert --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
