I'd like it if only `Atom`s had the extra data and all other Basics
computed assumptions from their leaves and potentially their class.
Is it possible to keep Symbol.assumptions stored in Symbol.args ? That way
we keep the simple tree structure. We'd need to be more careful about
is_Atom checks rather than relying on empty args.
On Sun, Apr 14, 2013 at 3:48 AM, Tom Bachmann <e_mc...@web.de> wrote:
> Just NB: the reason why I don't like Symbol('x', positive=True) to return
> PositiveObject(Symbol('x')) is that (a) it hides facts from the inference
> engine, and (b) for this to scale beyond Symbol and Dummy, every client
> will have to be prepared to strip the PositiveObject wrapper in order to
> deal with the wrapped object.
>
> Neither of these is a very strong argument - (a) just shows a shortcoming
> of the ask() implementation, and (b) would be does not really apply as long
> as we are just trying to emulate the old behaviour.
>
> Tom
>
>
> On 14.04.2013 00:13, Aaron Meurer wrote:
>
>> This looks very good so far. I have just some comments, which perhaps
>> should be forked into another one of your mini-threads
>>
>> - If you are planning on making any changes to the cache, you might
>> want to take a look at bin/test -C and see what sorts of issues
>> currently exist with it. There is also a caching label in the
>> tracker.
>>
>> - Regarding Symbol('x', positive=True), I think this requires some
>> thought. I am beginning to think that actually the best way to do this
>> is to keep doing it like we do it now (modulo some refactoring of the
>> Symbol class).
>>
>> I think perhaps there needs to be a separate set of global
>> assumptions, which are assumptions that never change. For example,
>> Q.positive(pi) (from my understanding this currently works by calling
>> .evalf(); we should see if it's faster to do that or to store a bunch
>> of Q.positive(pi) and so on explicitly, but anyway, not all custom
>> object assumptions can be generalized like this) never changes, and so
>> it should never be cleared, and additionally any facts resulting from
>> it should never be cleared.
>>
>> In general, we want to allow objects to define their own assumptions
>> about themselves, so that things can remain modular, and so that
>> objects in user-land can work as first-class citizens with the
>> assumptions. So, given that, I think that Symbol('x', positive=True)
>> should be no different. This "keeps the assumptions in the core", but
>> really, the issue is the inference code in the core. So I would just
>> leave Symbol('x', positive=True) alone for now, and refactor how it
>> works internally once we have a good API for how custom objects define
>> their own assumptions on themselves.
>>
>> - It occurs to me that another advantage of using the "switch" method
>> for switching over to the new assumptions is that it will become clear
>> exactly what sorts of behaviors we are going to have to deprecate or
>> completely remove, giving us an idea of the impact on users in the
>> next release.
>>
>> Aaron Meurer
>>
>>
>>
>> On Sat, Apr 13, 2013 at 4:18 PM, Tom Bachmann<e_mc...@web.de> wrote:
>>
>>> Hi,
>>>
>>> I have spent the last couple of days writing up a more coherent
>>> proposal. It
>>> is now in a readable state, see [1]. Any comments would be appreciated.
>>> (The
>>> proposal is still slightly rough, in particular there are a few TODO
>>> notes,
>>> and I haven't written anything yet about stretch goals.)
>>>
>>> Matthew:
>>> I have not forgotten your email from april 10,
>>>
>>> It might be nice to have a couple representative bugs/issues. What are
>>>> the sorts of problems that we're facing?
>>>>
>>>> What is a specific piece of code that would break?
>>>> What is an important routine that would run much more slowly?
>>>>
>>>
>>>
>>> I just have not had time do work out an answer, yet.
>>>
>>> Anyone else, if I have not addressed one of your concerns, please let me
>>> know.
>>>
>>> Thanks,
>>> Tom
>>>
>>> [1]
>>> https://github.com/sympy/**sympy/wiki/GSOC-2013-**
>>> Application-Tom-Bachmann:-**Removing-the-old-assumptions-**module<https://github.com/sympy/sympy/wiki/GSOC-2013-Application-Tom-Bachmann:-Removing-the-old-assumptions-module>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "sympy" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to
>>> sympy+unsubscribe@**googlegroups.com<sympy%2bunsubscr...@googlegroups.com>
>>> .
>>> To post to this group, send email to sympy@googlegroups.com.
>>> Visit this group at
>>> http://groups.google.com/**group/sympy?hl=en-US<http://groups.google.com/group/sympy?hl=en-US>
>>> .
>>> For more options, visit
>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>> .
>>>
>>>
>>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to
> sympy+unsubscribe@**googlegroups.com<sympy%2bunsubscr...@googlegroups.com>
> .
> To post to this group, send email to sympy@googlegroups.com.
> Visit this group at
> http://groups.google.com/**group/sympy?hl=en-US<http://groups.google.com/group/sympy?hl=en-US>
> .
> For more options, visit
> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
> .
>
>
>
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.
