On Tue, Jun 3, 2008 at 2:48 PM, Robert Bradshaw <[EMAIL PROTECTED]> wrote: > > On Jun 3, 2008, at 11:17 AM, Gary Furnish wrote: > >> On Tue, Jun 3, 2008 at 12:11 PM, Robert Bradshaw >> <[EMAIL PROTECTED]> wrote: >>> >>> On Jun 3, 2008, at 11:06 AM, Gary Furnish wrote: >>> >>>> I think we had a discussion on irc about how homsets still got used >>>> for determining the result of something in parent1 op something in >>>> parent2 (maybe it was with someone else?) >>> >>> I sure hope not. If so, that needs to change (but I'm pretty sure it >>> isn't). >>> >> Well allegedly there is some function that computes what parent >> something is in if you have parent1 op parentt2 that is new in this >> system (but I can't find said function). Allegedly said function has >> to use Homsets, so performance is going to be horrible(and this makes >> sense, because its what I have to use now). > > 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. >> 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. If coercion was implemented with 100% pure Cython code (with an eye for speed where it is needed), 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. >> >>>> 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 -~----------~----~----~----~------~----~------~--~---
