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
--
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.
--
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.
