I updated the log in my github. It just removes an explicit call to .expand() and instead just calls ._eval_expand_multinomial. It should make things a little faster.
~Luke On Sep 2, 4:00 pm, Ondrej Certik <ond...@certik.cz> wrote: > The tests pass for me too. Could you explain a bit in the log what the > advantage of your patch is against the previous way? the current log > is: > > " > Modified _eval_expand_multinomial to call _eval_expand_multinomial > instead of .expand() > " > > but no tests were changed, sp does it implement some new fuctionality, > or makes it faster, or something else? > > Ondrej > > On Wed, Sep 2, 2009 at 2:58 PM, Luke<hazelnu...@gmail.com> wrote: > > > It has been a while since I looked at this, but I went ahead and > > implemented what Ronan suggested. The branch is on my git hub: > >http://github.com/hazelnusse/sympy/tree/expand_neg_int_powers > > > It passes all tests on my machine. > > > Let me know what you think. > > > ~Luke > > > On Aug 9, 7:24 pm, "Aaron S. Meurer" <asmeu...@gmail.com> wrote: > >> On Aug 9, 2009, at 8:07 PM, Ronan Lamy wrote: > > >> > Le dimanche 09 août 2009 à 16:34 -0700, Luke a écrit : > > >> >>> * This line suggests that it would be helpful to create an 'inverse' > >> >>> property - less work is needed to create this inverse than for a > >> >>> generic > >> >>> Pow instance. > > >> >> Could you elaborate on what you mean here? Do you mean an inverse > >> >> property to Pow instances which have a integer exponent? Perhaps > >> >> 'reciprocal' instead of 'inverse'? > >> > Yes, I guess 'reciprocal' is better. I mean a class property defined > >> > for > >> > all instances that would look like: > >> > @property > >> > def reciprocal(self): > >> > if self.exp == -1: > >> > return self.base > >> > else: > >> > return Basic.__new__(self.__class__, self.base, -self.exp) > > >> >>> *I don't see the point of the third test: it's only testing that (x > >> >>> +y)**2*(x+y)**-4 == (x+y)**-2 which isn't related to expand. > > >> >> Yes, you are right, it isn't testing expand but I guess it probably > >> >> doesn't hurt to keep it in either. > >> > No, it doesn't hurt much, but each unneeded test makes running the > >> > full > >> > test suite a tiny bit more painful. > > >> Maybe we should replace it with something that doesn't have > >> automatically combining exponents, such as: > > >> (x + y)**(2 + x)*(x + y)**(-x - 4) > > >> Then it at least checks to see if multinomial is being called after > >> power_exp. Actually this isn't guarantied, because expand hints are > >> applied in arbitrary order. See the expand docstring. So I am not > >> sure if this will even work, and if so if it will on every machine > >> (with different hash values and thus different orders in the hints > >> dict). I forget how the expand functions are structured if > >> expand_power_exp will call expand_multinomial afterwords or not (with > >> the deep option set to True). > > >> Otherwise I agree. It is highly unlikely that we are ever going to > >> change the fundamental automatic simplification of (x + y)**2*(x + > >> y)**(-4) to (x + y)**(-2), which is the same sort of thing as x*x == > >> x**2. And if it is broken, there are plenty of other tests that will > >> break instead (such as the specifically structured > >> test_Mul_doesnt_expand_exp() and others in test_arit.py. > > >> Aaron Meurer > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sympy-patches" group. To post to this group, send email to sympy-patches@googlegroups.com To unsubscribe from this group, send email to sympy-patches+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sympy-patches?hl=en -~----------~----~----~----~------~----~------~--~---
