On Sun, May 1, 2011 at 12:30 PM, Tom Bachmann <ness...@googlemail.com> wrote:
>
>
> On 30 Apr., 23:41, "Aaron S. Meurer" <asmeu...@gmail.com> wrote:
>> On Apr 30, 2011, at 1:24 PM, Ronan Lamy wrote:
>>
>>
>>
>> > Le samedi 30 avril 2011 à 13:36 -0400, Haz a écrit :
>> >> 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.
>>
>> > As I recall, the problems were that it was slow and broke a lot of
>> > things. Symbol(x, positive=True) is easy to hack back in.
>>
>> >> Vinzent:
>> >>> I think the only problem could be that ask() is much slower for
>> >>> trivial queries, needs to be verified. This should be not too hard to
>> >>> fix though.
>>
>> >> I don't think this is the case. Trivial queries (those that already
>> >> have obvious implications) are compiled into quick reference
>> >> dictionaries. In particular:
>> >> -https://github.com/sympy/sympy/blob/master/sympy/assumptions/ask.py#L114
>>
>> > I think that the problem is with non-trivial queries, for which that
>> > code does nothing.
>>
>> >> In the end, everything in the new assumption system is done with a
>> >> particular assumption context -- design decisions must be made on
>> >> which context is used in the ambiguous cases. There is also an issue
>> >> (feature request) that makes things more natural that will be worked
>> >> on after the assumptions shift has taken place -- things like the
>> >> following would be possible:
>>
>> >> with <some assumptions on variables>:
>> >> <do stuff>
>>
>> >> This gives the assumptions an explicit local scope. The branch from
>> >> last summer was mostly filled with fixing test cases so they used the
>> >> new assumption system (with the global assumptions), and then cleaned
>> >> up after themselves.
>>
>> >> It should also be emphasized that it isn't just a simple notion of
>> >> cleaning up assumptions after yourself -- the cache interacts in quite
>> >> an intertwined way. Under the right assumptions, expressions will be
>> >> simplified, and variables will be assigned certain values. If that's
>> >> stored in the cache, changing any related assumption will invalidate
>> >> the result. For this reason, I had to manually clear the cache on a
>> >> regular basis. I think that the cache is only really needed for
>> >> lengthy solve algorithms (so you don't recompute an expression over
>> >> and over), in which case we can probably wipe it after any sympy
>> >> command is invoked (i.e., only use the cache while sympy is computing
>> >> things, and then flush it just before returning the result). However,
>> >> the branches from last summer never made it this far.
>>
>> > The cache is the source of a lot of problems. We should try to use it as
>> > little as possible, even if it's not really possible to remove it at
>> > this time.
>>
>> If a specific algorithm is slow without the cache, I think it should be
>> rewritten to not do duplicate calculations.
>>
>
> Why? For example in gruntz, the performance depends quite a lot of
> caching mrv computations, limit computations, and order computations.
> Since these hardly arise in a controlled manner, the only way I can
> see to not recompute is to roll a separate cache - what would be the
> point of this?
>
> IMHO we should definitely keep the cache. When something breaks it, it
> is ill-designed.
Because the cache is a source of tons of our problems with sympy. Very
hard to debug problems. Designing an efficient and robust cache is a
highly nontrivial task.
So if gruntz needs it, then it should use it's own private cache,
until we figure out a better algorithm, that doesn't need it. The core
of sympy should not use any cache however.
Ondrej
--
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.
