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. 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. > >> 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. 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.
