On Tue, Jun 3, 2008 at 7:21 PM, Robert Bradshaw <[EMAIL PROTECTED]> wrote: > > On Jun 3, 2008, at 4:36 PM, Gary Furnish wrote: >>> >>> 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. > > Ah, yes. We talked about this before, and I implemented the analyse > and explain functions which carefully avoid all Python: > > http://cython.org/coercion/hgwebdir.cgi/sage-coerce/rev/1a5c8ccfd0df > >> >>> 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. > > Writing a huge number of special cases is almost always going to be > faster, not doubt about it. The Sage coercion code needs to be > extremely generic as it handles all kinds of objects (and I'm excited > to have symbolics that respect this). > >> 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. > > Yes. > >> 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. > > Would it be 95% possible if it's 95% written in Cython, with only a > 5% performance hit :-). > > The best balance I see is you can hard code ZZ/RR/... for speed if > you want (you're worried about virtual function calls anyways), and > then call off to coercion in the generic cases. You're going to have > to do this a bit anyways, as the coercion model doesn't handle stuff > like "where is the sin(x) if x is in R?" which is handled via the > normal OO sense based on the type of x (and may depend on x). > > To help with collaboration, what you want out of the coercion model > is, given R and S (and an operation op), what will be the result of > op between elements of R and S, and you want this to be as fast as > possible (e.g. 100% Cython, no homsets, ...). > Correct
> - 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 -~----------~----~----~----~------~----~------~--~---
