(I have now added a subsection on this in my melange proposal; see
"summary of issues")
On 10.04.2013 20:52, Matthew Rocklin wrote:
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?
On Wed, Apr 10, 2013 at 2:47 PM, Tom Bachmann <e_mc...@web.de
<mailto:e_mc...@web.de>> wrote:
On 10.04.2013 20:27, Aaron Meurer wrote:
One thing that I think hasn't been mentioned yet is that we do still
want x.is_foo to work, and probably Symbol('x', foo=True) as well.
.is_foo is way easier to type than ask(Q.foo(x)), and there are tons
of lines of code that use this idiom, both in the SymPy library
and in
user code.
I was under the assumption that is_foo is expected to remain. Once
we have transitioned to new assumptions, this would simply turn into
a wrapper for ask(Q.is_foo(self)) [using only global assumptions],
wouldn't it.
For Symbol('x', real=True), we need to decide exactly how we are
going
to handle global assumptions.
Hm. I understand that for backwards compatiblity we will want this
to remain working, at least some time.
This seems reasonably easy to achieve with the new assumptions
system (at least in principle): Symbols keep storing these extra
assumptions, and equality-comparison remains as it is. The Symbol
constructor injects the assumptions into global_assumptions.
This way
Symbol('x') # no assumptions
Symbol('x', positive=True) # actually secretly a different object!
Symbol('x') == Symbol('x') # True
Symbol('x', positive=True) == Symbol('x', positive=True) # True
Symbol('x') != Symbol('x', positive=True) # True, as currently
Symbol('x', negative=True) # No contradictory global assumptions!
Of course, if we were to go with the .assumptions field, then this
is not really an issue.
But assuming this, why can't we just transition by making these two
things work in the new assumptions, then switching the flag in Basic
to use the new assumptions instead of the old ones. We will then
get a
ton of bugs and performance issues, which should then be fixed.
"the flag" - is there already one?
But more importantly, at what point *do* we fix the "ton of bugs and
performance issues"? Surely we do not want a broken master?
Aaron Meurer
On Wed, Apr 10, 2013 at 10:46 AM, Brian
Granger<elliso...@gmail.com <mailto:elliso...@gmail.com>> wrote:
I am strongly -1 on having the new assumption logic in
master but
disabled globally with flags.
On Wed, Apr 10, 2013 at 9:20 AM, Matthew
Rocklin<mrock...@gmail.com <mailto:mrock...@gmail.com>> wrote:
I think you would traverse the input expression tree
once to collect all
assumptions stored in that tree into a set. You would
then use that set
during the computation (maybe this goes into ask?).
Probably a tree would
cache its set of assumptions after the first traversal.
In what case would
facts change during a computation/query?
It doesn't strike me as the slow part of assumptions.
In any case it's
something that you could slowly remove as code developed
- fewer and fewer
bits of code would depend on the assumptions field.
But I don't like this idea anyway. I mostly don't like
the idea of adding
an extra field to Basic. It makes it substantially less
basic.
On Wed, Apr 10, 2013 at 11:01 AM, Tom
Bachmann<e_mc...@web.de <mailto:e_mc...@web.de>> wrote:
On 10.04.2013 16:56, Matthew Rocklin wrote:
Old and new assumptions differ in a few ways.
1. They store assumptions in different places
(this is the main issue
here I think)
2. They represent assumptions differently
3. They represent relations differently
4. They infer/compute differently
I don't particularly like this idea, but one
could consider a solution
that changes 2,3,4 but doesn't change 1.
Alongside the .args tuple,
Basic could also hold an .assumptions frozenset
as a field.
Computations that use assumptions could then
check both the global
collection and all assumptions in the expression
tree. This might be an
intermediate step in our development.
I thought about that, but it is not obvious how to
make it work. I suppose
you would need to take the transitive closure of all
assumptions. I.e.:
- take all facts, extract all symbols into a list L
-0append the symbols in the expression being queried
to L
-for every object in L, read out the assumptions
frozenset, and append it
to facts
- start over if the facts have changed
This seems potentially quite slow.
--
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
<mailto:sympy%2bunsubscr...@googlegroups.com>.
To post to this group, send email to
sympy@googlegroups.com <mailto: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
<mailto:sympy%2bunsubscr...@googlegroups.com>.
To post to this group, send email to
sympy@googlegroups.com <mailto: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>.
--
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgran...@calpoly.edu <mailto:bgran...@calpoly.edu> and
elliso...@gmail.com <mailto:elliso...@gmail.com>
--
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
<mailto:sympy%2bunsubscr...@googlegroups.com>.
To post to this group, send email to sympy@googlegroups.com
<mailto: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
<mailto:sympy%2bunsubscr...@googlegroups.com>.
To post to this group, send email to sympy@googlegroups.com
<mailto: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.
--
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.
