Le dimanche 01 mai 2011 à 23:37 -0700, Ondrej Certik a écrit : > 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. > Obviously, this deal with assumptions, but it's explicit. Which is exactly the case I discussed in the followingparagraph. > > > > 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.
I agree on this. Non-commutative Symbols don't make a lot of sense. If we didn't have them (and severed the inheritance from Boolean), we could say that Symbols are complex variables. Instead, we have a murky definition. Anyway, is_commutative is just an extreme example. Most .__new__() and .eval() methods check one assumption or other. We'd have to throw all that code away and rewrite it from scratch. > > 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. And I'm saying that no matter what you think we should do, we can't avoid dealing with them, unless, perhaps, we do a complete rewrite as Fredrik suggests. > >> >> 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 Sympy is most certainly much slower in your branch than in master with cache on. Just try "bin/test sympy/solvers" in both. > can be very fast, as shown by the csympy, *without* caching. > What's csympy? And can it do the same things as sympy? Otherwise, you're comparing apples to oranges. > 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. The problem I see with that plan is that you break sympy at step 1, and fix it at step 4. -- 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.
