Le jeudi 02 juin 2011 à 22:15 -0600, Aaron S. Meurer a écrit : > 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 <matt...@gmail.com> 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)). > A lot of time is wasted for the sake of a few keystrokes. To understand anything using "domains", you need to unpick all the levels of indirection (e.g. ZZ = ZZ_python = PythonIntegerRing which is a wrapper for PythonIntegerType = int) and understand of a lot of methods and syntactic shortcuts. It's much easier to understand 'isinstance(a, int_type)' than 'ZZ.of_type(a)', even if the latter is shorter.
> > > >>> > >>>> 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 sympy@googlegroups.com. > >>> To unsubscribe from this group, send email to > >>> sympy+unsubscr...@googlegroups.com. > >>> 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 sympy@googlegroups.com. > > To unsubscribe from this group, send email to > > sympy+unsubscr...@googlegroups.com. > > 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 sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.