On Sun, Apr 1, 2012 at 9:08 PM, Ronan Lamy <[email protected]> wrote: > Le dimanche 01 avril 2012 à 18:54 +0300, Sergiu Ivanov a écrit : >> >> It should be possible to have operation-unaware classes for elements >> and operation-aware rings, and then define simple ring-aware wrappers >> for elements which will take care of making a*b and R.mul(a,b) >> equivalent. >> >> I'm not sure about how well Python inlines functions, but if does a >> decent job of this, the code a*b will be directly reduced to >> R.mul(a,b) and thus no run-time performance penalty will follow. > > Python doesn't inline functions. It's a rather fundamental part of its > semantics that makes tracebacks and debuggers possible. PyPy's JIT > compiler detects cases where inlining is possible without affecting the > behaviour of the program, but CPython (the standard implementation of > Python) doesn't have a JIT, so it never inlines.
Oh, I see. Thank you for the information! > Besides, how can a and b know which they belong to? This would require > having several different versions of e.g. sqrt(6): one in QQ[sqrt(6)], > one in QQ[sqrt(2), sqrt(3)], one in RR, one in CC, ... IIUC, Sage does > exactly that, but it feels profoundly wrong. > > It should clearly be the other way round: R.mul(a, b) should be defined as > a*b. > And since we'd like ring operations to be symbolic objects, we should > even have R.mul = Lambda((x, y), x*y). I am afraid this pertains to a particular case of what we are discussing in this thread. While QQ, RR, CC are indeed rings, we are not that interested in their *ring* structure when we are working with elements thereof. Moreover, multiplication in RR is a restriction of multiplication in CC, ditto for QQ. This makes a similar notation (*) for all three operations acceptable. Indeed, it would be odd to require the user to write QQ.mul(2, 3) instead of the clear and natural 2 * 3. However, it is very dangerous to make *any* ring multiplication look like (*), because it will compel the user to memorise which variables belong to which ring. The situation gets even worse should we consider two different rings over the same set of elements. Note that, as I suggested, should the usage of (*) be unambiguous in a piece of code, it is easy to create operation-aware element wrappers, or even to bind the operation to the elements for efficiency, as it happens now. In these cases the currently existing class Ring will certainly work nicely. However, I totally think that, for the general case, tying the operation to elements is a bad idea. Again, note that I don't promote the abolition of the current Ring class, but rather renaming it to RingDomain. In conclusion, I cannot see how my ideas fundamentally contradict the approaches evoked in this thread. Therefore, I will try to pose the dual question: do you think the current Ring class is well-suited for a future implementation of ring theory? I hope a definite answer to this question will be more reachable :-) Sergiu -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
