On Tue, Jun 3, 2008 at 4:39 PM, Robert Bradshaw <[EMAIL PROTECTED]> wrote: > > 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). > But I don't have elements, I have variables that represent elements. Maybe the solution here is to run an_element on each parent and then multiply them (and in fact I do this as a last case resort) and then get the parent of the result, but this is a pretty bad way to do things as it requires construction of elements during coercion. Furthermore, this isn't even implemented in some classes, the default is written in python, etc. Even if those issues were dealt with, having to multiply two elements to figure out where the result is a bad design.
> 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... No but special cases/writing my own fast coercion code seems to work significantly better then trying to use your system. This is definitely a bad situation, because we shouldn't need another set of coercion codes that deal with the cases where the main coercion code is too slow. Either coercion has to be designed to be fast, or symbolics is going to have to reach into the innards of the coercion framework to make it possible to deal with quickly. It would be even better if we could have symbolicring over RR or symbolicring over ZZ or what not, but this is 100% impossible unless the coercion framework is done 100% in cython, with special cases, with speed as a top priority instead of beauty. > >>>>>> 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 -~----------~----~----~----~------~----~------~--~---
