On Sun, May 1, 2011 at 7:10 PM, Ronan Lamy <[email protected]> wrote: > Le dimanche 01 mai 2011 à 09:43 -0700, Ondrej Certik a écrit : >> On Sun, May 1, 2011 at 7:43 AM, Ronan Lamy <[email protected]> wrote: >> > Le samedi 30 avril 2011 à 23:47 -0700, Ondrej Certik a écrit : >> >> On Sat, Apr 30, 2011 at 10:36 AM, Haz <[email protected]> wrote: >> >> > So a few things to respond to... >> >> > Tom: >> >> >>Can you describe what went wrong with these branches? In particular, >> >> >>why can the following naive strategy not work: >> >> >> >> >> >>1. Make the new system at least as good as the old one. That is >> >> >>whenever I can write foo.is_bar I can write ask(foo, Q.bar) and I will >> >> >>get at least as good an answer. In particular Symbol('x', >> >> >>positive=True) should register automatically in the global assumptions >> >> >>that x > 0 (if I understand correctly how the new system works...). >> >> >>2. Replace all queries foo.is_bar by ask(foo, Q.bar). >> >> >>3. Remove all implementations of the is_bar properties. >> >> >>4. Remove all remaining remnants of the old system. >> >> > This is what was largely tried with a branch last summer: >> >> > - https://github.com/haz/sympy/tree/disconnect-assumptions-2 >> >> > There was push-back from the community since removing the Symbol('x', >> >> > positive=True) syntax was largely frowned upon. >> >> >> >> I am still very much convinced, that this disconnect-assumptions-2 is >> >> the simplest and easiest way to get rid of the old assumptions, so >> >> that we can start speeding up the core, and start using some other >> >> system for them. >> >> >> > BTW, isn't certik/remove_assumptions slightly more recent? Anyway, you >> >> I am not sure at the moment, but the branch I am referring to is the >> one that Christian worked for about a week during his GSoC. Then the >> discouragement from the community forced him to stop. >> >> > never explained why the old assumptions are slowing us down. Everything >> > I've seen so far points in the other direction. >> >> I claim that no assumptions are faster than assumptions. I claim that >> the core should not deal with assumptions by default, just like ginac >> (that Sage uses) doesn't deal with assumptions, and thus is fast. > > Sure, it's faster if you don't have assumptions than if you need to deal > with them. But we need them: how else could we simplify, for instance, > sqrt(x**2)?
Refine(sqrt(x**2), ctx) where you pass some Assumption context, or assumptions. > > I believe you think that we shouldn't simplify anything implicitly, but > in that case expressions get unwieldy very fast - you can't even assume > that Symbols are commutative. So you have to check for simplifications You should assume it. Non commutative symbols are just making things very complicated, and it was a mistake to add them into the core of sympy. They should start in sympy.quantum, and only after they are being used a lot, we should start thinking how to handle them properly. > all the time, which brings you back to dealing with assumptions all the > time, except you've traded a system that was optimised for that kind of > checking for one that isn't. We disagree here. I think that you should *not* deal with assumptions in the core. > >> > >> >> I would be interested in the community vote on this idea. I vote +1. I >> >> am aware that Ronan voted -1 last year. What do others think? >> > >> > What are you voting +1 on, concretely? Your branch is one year old, so >> >> I vote to continue on that branch, which passed almost all tests >> (rebase it/rework it to the latest master). >> >> > it would have to be updated. There were also many test failures >> >> Those need to be fixed, just like the ones in the core, that were already >> fixed. >> >> > remaining and it was unbearably slow for complex calculations, what's >> > your plan for that? >> >> As Christian remarked, it was slower if the caching was turned down. >> Caching is another problem, that needs to be addressed, as Christian >> remarked. My plan is that preferably the cache should be off by >> default, and/or flushing it the way Christian did it. If I remember >> well, it was not slower. > > Well, turning off the cache slows sympy so much that it's not a > realistic option at the moment. I disagree, as explained in the previous paragraph --- I don't think it was slower to use Christian's approach. Also, I know that the core can be very fast, as shown by the csympy, *without* caching. As such, when you can be both fast (faster than now) and not use cache, you should go for it. So my own vision has always been very clear: * get rid of assumptions in the core * use csympy (or use ideas from it) to speed up the core * use caching in other parts of sympy, that need it, e.g. limits, maybe integrals, I don't know * implement refine(), and other things, and use the new assumptions. Ondrej -- 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.
