On Jun 2, 2011, at 10:09 PM, Ronan Lamy wrote: > Le jeudi 02 juin 2011 à 21:28 -0600, Aaron S. Meurer a écrit : >> On Jun 2, 2011, at 9:21 PM, Ronan Lamy wrote: >> >>> Le jeudi 02 juin 2011 à 17:07 -0600, Aaron S. Meurer a écrit : >>>> On May 31, 2011, at 11:11 AM, Ronan Lamy wrote: >>>> >>>>> Le mardi 31 mai 2011 à 09:43 -0700, Vinzent Steinberg a écrit : >>>>>> On May 30, 9:52 pm, Mateusz Paprocki <[email protected]> wrote: >>>>>>> That could work: >>>>>>> >>>>>>> ZZ.sum([1, 2, 3]) -> sum([1, 2, 3]) >>>>>>> RR.sum([1.0, 2.0]) -> mpmath.fsum([1.0, 2.0]) >>>>>>> EX.sum([x, y, z]) -> Add(*[x, y, z]) >>>>>>> >>>>>>> etc. >>>>>> >>>>>> This is exactly what I have been thinking of. >>>>> >>>>> But do we really need lots of different sum() functions? Is there a >>>>> difference between ZZ.sum([1, 2, 3]) and EX.sum([1, 2, 3])? >>>> >>>> Yes. You can sum integers perfectly efficiently just by passing them >>>> to the built-in sum() (also remember that ZZ(1) != S(1) in general >>>> because of the ground types, but EX(1) == S(1) always). >>> >>> ZZ(1) != S(1), but only some times, is rather counter-intuitive. I don't >>> understand what ZZ is really supposed to mean anyway. If it's the ring >>> of integers, why can its value change? And why is it instantiable? >> >> ZZ(1) means 1 in the current ground type. If the ground type is Python, >> it returns int(1). If it's gmpy, it returns mpz(1). Actually, ZZ(1) >> == S(1) only if you manually choose the sympy ground types. Note that >> I am using "==" here to mean actually something more like "is". I >> should really have said "type(ZZ(1)) != type(S(1))". __eq__ itself >> works as expected regardless of the underlying type. >> > OK. So "ZZ" means "integer type". That's what I find counter-intuitive > then. > >> In general, ZZ stands for the domain of integers, and you can pass it >> to Poly under the domain option (you can also do stuff like ZZ[x] to >> create the domain of polynomials in x with integer coefficients). >> ZZ(1) is just syntactic sugar that makes it easy to coerce elements to >> that domain. > > OK. By domain, you mean type, right? (That 'ZZ[x]' is a rather confusing > bit of syntactic sugar that seems to suggest a mathematical meaning it > doesn't really have and looks weird when you replace ZZ with any of its > possible values)
Yeah, ZZ, QQ, etc. are all just about syntactic sugar that makes things much shorter to type. You can do all of the stuff equivalently in much longer forms. And by the way, the ZZ[x] syntax just exists because that's the mathematical notation (the square brackets). The real confusing thing is that ZZ(x) is not the field of rational functions in x with integer coefficients (for that you need ZZ.frac_field(x)). > >>> >>>> But something >>>> like Add(*(x, -x, x, x, -x)) is almost two times faster than sum((x, >>>> -x, x, x, -x)): >>> >>> That's rather an implementation detail, and using Add(*[...]) is wrong >>> anyway, if we want to allow extensions of sympy. Besides, it doesn't >>> explain why EX.sum([n, -n, n, n]) should be different from ZZ.sum([n, >>> -n, n, n]). >> >> Do you mean that n is symbolic? If so, then ZZ.sum([n, -n, n, n]) >> doesn't make sense. >> > It would make sense if 'ZZ' meant 'the ring of integers'. Actually, even > though that's not the case, it works anyway because ZZ.sum is always > just sum. That depends on if type checking happens on this level or not (and if it does work, it's only by accident). Aaron Meurer > >> Aaron Meurer >> >>> >>>> >>>> In [1]: Add(*(x, -x, x, x, -x)) >>>> Out[1]: x >>>> >>>> In [2]: %timeit Add(*(x, -x, x, x, -x)) >>>> 1000 loops, best of 3: 170 us per loop >>>> >>>> In [3]: sum((x, -x, x, x, -x)) >>>> Out[3]: x >>>> >>>> In [4]: %timeit sum((x, -x, x, x, -x)) >>>> 1000 loops, best of 3: 313 us per loop >>>> >>>> In [16]: b = map(S, range(100)) >>>> >>>> In [24]: %timeit Add(*b) >>>> 1000 loops, best of 3: 546 us per loop >>>> >>>> In [25]: %timeit sum(b) >>>> 1000 loops, best of 3: 268 us per loop >>>> >>>> (all run without the cache, as suggested above). Note that [16] >>>> ensures that sum(b) goes through Add. Otherwise, you get >>>> >>>> In [26]: %timeit Add(*range(100)) >>>> 1000 loops, best of 3: 1.45 ms per loop >>>> >>>> In [27]: %timeit sum(range(100)) >>>> 100000 loops, best of 3: 2.7 us per loop >>>> >>>> which just proves what we already know, which is that Python ints are >>>> (apparently 10x) faster than SymPy Integers. >>>> >>>> Aaron Meurer >>>> >>> >>> >>> -- >>> 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. >>> >> > > > -- > 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. > -- 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.
