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, ...). - 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 -~----------~----~----~----~------~----~------~--~---
