0.7.1 hanging on sub of DeferredVector
Matthew Brett
On my snow leopard machine:
from sympy import Symbol, DeferredVector
x = Symbol('x')
newt = DeferredVector("t")
res = x.subs(x, newt)
results in a long hang. On 0.7.0 and 0.6.6 it's very quick. Ctrl-C
on the 0.7.1 branch running the code above (as ``hanging.py``) ends
with a traceback:
File "hanging.py", line 5, in <module>
res = x.subs(x, newt)
File "/Users/mb312/.virtualenvs/sympy-0.7.1/lib/python2.6/site-packages/sympy/core/basic.py",
line 752, in subs
return self._subs_old_new(old, new)
File "/Users/mb312/.virtualenvs/sympy-0.7.1/lib/python2.6/site-packages/sympy/core/cache.py",
line 101, in wrapper
func_cache_it_cache[k] = r = func(*args, **kw_args)
File "/Users/mb312/.virtualenvs/sympy-0.7.1/lib/python2.6/site-packages/sympy/core/basic.py",
line 760, in _subs_old_new
new = sympify(new)
File "/Users/mb312/.virtualenvs/sympy-0.7.1/lib/python2.6/site-packages/sympy/core/sympify.py",
line 134, in sympify
rational=rational) for x in a])
File "/Users/mb312/.virtualenvs/sympy-0.7.1/lib/python2.6/site-packages/sympy/matrices/matrices.py",
line 62, in __getitem__
return Symbol(component_name)
File "/Users/mb312/.virtualenvs/sympy-0.7.1/lib/python2.6/site-packages/sympy/core/symbol.py",
line 54, in __new__
return Symbol.__xnew_cached_(cls, name, commutative, **assumptions)
File "/Users/mb312/.virtualenvs/sympy-0.7.1/lib/python2.6/site-packages/sympy/core/cache.py",
line 101, in wrapper
func_cache_it_cache[k] = r = func(*args, **kw_args)
File "/Users/mb312/.virtualenvs/sympy-0.7.1/lib/python2.6/site-packages/sympy/core/symbol.py",
line 58, in __new_stage2__
obj = Expr.__new__(cls, **assumptions)
File "/Users/mb312/.virtualenvs/sympy-0.7.1/lib/python2.6/site-packages/sympy/core/basic.py",
line 83, in __new__
obj = object.__new__(cls)
KeyboardInterrupt
I got a little scared at the point. Can I help with the debugging?
Best,
Matthew
Aaron Meurer
commit f95d0146f59fd9160fe867561fb6620c3a035ad1
Author: Chris Smith <smi...@gmail.com>
Date: Wed Jun 15 22:15:17 2011 -0500
use ordered_iter and iterable
This reverts commit 654cb9bc6d3bdab45d45a8ec2b41df358b5aa440
and adds a few more use cases.
The problem is that sympify(newt) checks if it is an iterable using
the iterable() function, and it thinks it is because it is indexable,
but if you do, for example, list(newt), it just hangs, because it is
trying to create [t[0], t[1], t[2], ...].
So iterable() needs to be fixed here, I think.
Aaron Meurer
> --
> You received this message because you are subscribed to the Google Groups "sympy" group.
> To post to this group, send email to sy...@googlegroups.com.
> To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
>
>
Matthew Brett
On Tue, Jul 26, 2011 at 1:02 AM, Aaron Meurer <asme...@gmail.com> wrote:
> I bisected this to
>
> commit f95d0146f59fd9160fe867561fb6620c3a035ad1
> Author: Chris Smith <smi...@gmail.com>
> Date: Wed Jun 15 22:15:17 2011 -0500
>
> use ordered_iter and iterable
>
> This reverts commit 654cb9bc6d3bdab45d45a8ec2b41df358b5aa440
> and adds a few more use cases.
>
> The problem is that sympify(newt) checks if it is an iterable using
> the iterable() function, and it thinks it is because it is indexable,
> but if you do, for example, list(newt), it just hangs, because it is
> trying to create [t[0], t[1], t[2], ...].
>
> So iterable() needs to be fixed here, I think.
Thanks very much for tracking that down.
Best,
Matthew
Aaron Meurer
properly fix this. Any objects that iterates infinitely would have
this problem.
Aaron Meurer
Chris Smith
> Tracking it down was easy. The thing I'm not sure about is how to
> properly fix this. Any objects that iterates infinitely would have
> this problem.
>
I can't look into this too deeply now, but is there an exclude flag on
the iterable() function that can be used to exclude the object in
question?
Aaron Meurer
or give it a _sympy_ method so that sympify() knows how to convert it
without resorting to trying to iterate over it.
Actually, I see now that DeferredVector is a generator of Symbol
objects. So expr.subs(x, newt) makes about as much sense as
expr.subs(x, cos) (that's not a typo).
I think this previously only worked because sympify converted the
string value into a Symbol (converting string values is sympify()'s
last resort). If you had given it some string name that wasn't an
allowable Python variable name, or something strange like
DeferredVector('cos(x)'), it would have behaved much different.
In [1]: x.subs(x, DeferredVector('cos(x)'))
Out[1]: cos(x)
In [2]: x.subs(x, DeferredVector('cos(x)')).subs(x, pi)
Out[2]: -1
Aaron Meurer
Matthew Brett
On Mon, Jul 25, 2011 at 8:49 PM, Aaron Meurer <asme...@gmail.com> wrote:
> I think the proper fix is to either make DeferredVector an Expr object
> or give it a _sympy_ method so that sympify() knows how to convert it
> without resorting to trying to iterate over it.
>
> Actually, I see now that DeferredVector is a generator of Symbol
> objects. So expr.subs(x, newt) makes about as much sense as
> expr.subs(x, cos) (that's not a typo).
Yes, you're right, the DeferredVector doesn't make sense there.
Luckily, in our production code, we'd removed it some time ago, so the
behavior of 0.7.1 won't be a significant direct problem for us
(nipy.org).
Do you think it is worth trying to make the subs give a more specific
error though?
Best,
Matthew
Aaron Meurer
Well, what needs to be fixed is sympify(DeferredVector('t')). What do
you think this should return? To me, DeferredVector should already be
a SymPy object, in which case it would return itself.
If that is fixed, then either it will automatically have a better
error or it will just work, depending on what you make sympify return.
Because, right now, the problem is in sympify(), not subs().
Aaron Meurer
P.S., why do you have your docs on sourceforge and your code on
GitHub? Have you heard of gh-pages?
P.S.S., feel free to send in a patch fixing the above.
Matthew Brett
On Tue, Jul 26, 2011 at 6:48 PM, Aaron Meurer <asme...@gmail.com> wrote:
> On Tue, Jul 26, 2011 at 5:25 PM, Matthew Brett <matthe...@gmail.com> wrote:
>> Hi,
>>
>> On Mon, Jul 25, 2011 at 8:49 PM, Aaron Meurer <asme...@gmail.com> wrote:
>>> I think the proper fix is to either make DeferredVector an Expr object
>>> or give it a _sympy_ method so that sympify() knows how to convert it
>>> without resorting to trying to iterate over it.
>>>
>>> Actually, I see now that DeferredVector is a generator of Symbol
>>> objects. So expr.subs(x, newt) makes about as much sense as
>>> expr.subs(x, cos) (that's not a typo).
>>
>> Yes, you're right, the DeferredVector doesn't make sense there.
>> Luckily, in our production code, we'd removed it some time ago, so the
>> behavior of 0.7.1 won't be a significant direct problem for us
>> (nipy.org).
>>
>> Do you think it is worth trying to make the subs give a more specific
>> error though?
>>
>> Best,
>>
>> Matthew
>>
>
> Well, what needs to be fixed is sympify(DeferredVector('t')). What do
> you think this should return? To me, DeferredVector should already be
> a SymPy object, in which case it would return itself.
Yes, that seems reasonable.
> If that is fixed, then either it will automatically have a better
> error or it will just work, depending on what you make sympify return.
> Because, right now, the problem is in sympify(), not subs().
>
> Aaron Meurer
>
> P.S., why do you have your docs on sourceforge and your code on
> GitHub? Have you heard of gh-pages?
We have :) Our situation is a little complicated by having several
sub-projects with different coders and schedules; it's still easier
for us to publish docs to the various sub-directories with rsync.
> P.S.S., feel free to send in a patch fixing the above.
Yes, you're right - I should increase my code / email ratio - I will
give it a go tomorrow,
Thanks,
Matthew