On Jun 3, 2008, at 3:08 PM, Gary Furnish wrote: > > On Tue, Jun 3, 2008 at 2:48 PM, Robert Bradshaw > <[EMAIL PROTECTED]> wrote: >> >> When a new morphism is created it needs a parent, which is a Homset >> that may be looked up/created at that time. This is probably what you >> are talking about. However, this is a single (tiny) constant overhead >> over the entire runtime of Sage. I'm sure this could be further >> optimized, but creating all the homsets ZZ -> QQ -> RR -> CC, etc. >> will be done long before any symbolic code gets hit. >> > This is not what I'm talking about. What I'm talking about is you > can't access members of homset without leaving cython and using > python.
Of course homsets could be optimized, but once created they aren't used in the coercion itself. I don't know why you'd need to access the members of homset unless you were doing some very high-level programming. The domain and codomain are cdef attributes of Morphisms, which are in Cython (and that took a fair amount of work as they was a lot of MI going on with them until a year ago). >>> I consider homsets to be >>> a gigantic flaw in coercion that absolutely have to be fixed for >>> me to >>> consider using more of the coercion system in symbolics. >> >> Ironically, other people see it as a plus that coercion has been >> given a more categorical founding. >> > No, I consider categories to be good. I consider bad implementations > of categories to be bad. Implementations that make extensive use of > MI and are thus impossible to cythonize or access without py dict > lookups are not good implementations of categories. That depends on what they are being used for, but categories lend themselves very naturally to multiple inheritance because of what they are mathematically. I understand wanting, .e.g., arithmetic to be super fast, but I don't see the gain in hacks/code duplication to strip out multiple inheritance from and cythonize categories. Python is a beautiful language, but it comes with a cost (e.g. dict lookups). Other than initial homset creation, what would be faster (for you) if homsets and categories were written in Cython? > If coercion was implemented with 100% pure Cython code (with an eye > for speed where it is needed), The critical path for doing arithmetic between elements is 100% pure Cython code. The path for discovering coercions has Python in it, but until (if ever) all Parents are re-written in Cython this isn't going to be fully optimal anyways. And it only happens once (compared to the old model where it happened every single time a coercion was needed). Of course, much of the discover part could and should be optimized. But right now we've already got enough on our plate trying to get the changes we have pushed through. (Any help on this front would be greatly appreciated.) > I would be significantly less upset with it then I am now > where people tell me that if I need more speed I'm out of luck. That's not the message I'm trying to send--I'm sure there's room for improvement (though I have a strong distaste for hard-coding special cases in all over the place). I don't think "make everything Cython" is going to solve the problem... >>>>> I'm also -1 for hard-coding >>>>> knowledge and logic about ZZ,QQ, etc into the coercion model. I >>>>> am +1 >>>>> for hardcoding it into the elements of say, ZZ,QQ,RR and then >>>>> having >>>>> them call the coercion model only if those hardcodes can't figure >>>>> the >>>>> situation out. >>>> >>>> That sounds much better, though I'm still not a fan. >>>> >>> Sure, its kindof ugly, but it will give us the performance we need, >>> and I don't see a better way to allow us to use coercions all >>> over the >>> place without having performance drop to 0. >> >> One may be able to eek out a bit more performance by doing this, but >> it's not as if performance is awful in the current model. >> > For the things you do. There is no code that pushes the coercion > system anywhere near as much as symbolics in Sage does. >> - Robert >> >> >>> >> > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
