On Apr 30, 2010, at 5:26 PM, Ronan Lamy wrote:

> Le vendredi 30 avril 2010 à 16:06 -0700, Ondrej Certik a écrit :
>> On Fri, Apr 30, 2010 at 3:04 PM, Ronan Lamy <ronan.l...@gmail.com> wrote:
>>> Le vendredi 30 avril 2010 à 14:23 -0700, Ondrej Certik a écrit :
>>>> On Fri, Apr 30, 2010 at 6:26 AM, jegerjensen <jensen.oyv...@gmail.com> 
>>>> wrote:
>>>>>> Also, shouldn't this go into sympy.core?
>>>>>> 
>>>>>> Ondrej
>>>>>> """
>>>>> 
>>>>> That is probably a good idea.  Where should we put the decorator
>>>>> _tuple_wrapper? Or should the decorator be removed?  We could instead
>>>>> let sympify() wrap the tuples.
>>>> 
>>>> So this patch is +1 from me. Do you think you can upload it into
>>>> github? I'll try to merge it using github tools, just to learn it.
>>>> 
>>>> We can move it into the core in some other package. What is the idea
>>>> behind SymTuple? Why is it needed? Can this be added into it's class
>>>> docstring, together with some example?
>>> 
>>> Wait. From what I understand, this patch defeats the purpose of having a
>>> Tuple type, which is to avoid encountering a non-sympy type such as
>>> tuple when walking an expression tree. This makes SymTuple(a_tuple).args
>>> = (a_tuple,).
>>> 
>>> There are 2 fundamental invariants that all instances of Basic should
>>> obey: obj.func(*obj.args) == obj and all(isinstance(x, Basic) for x in
>>> obj.args). The fact that some objects (Integral, etc.) break this is a
>>> serious annoyance and SymTuple should be part of the solution.
>> 
>> Ah, I think I can see the motivation --- it would be used inside the
>> integral, so that you can do:
>> 
>> obj.func(*obj.args)
>> 
>> ? Very nice!
> 
> You can already do that. What would become possible is something like
> obj.func(*[arg.subs(x,y) for arg in obj.args])
> 
>> 
>> This should be well documented. As to your "Wait." --- is there any
>> problem with the current patch?
> 
> Yes, the problem is that SymTuple((x, y, z)).args should be (x, y, z),
> but this patch makes it ((x, y, z),)
> 
I see what Ronan is saying.  So I actually agree with him that the args should 
be (x, y, z) then, because even though it is inconsistent with tuple(), we need 
all .args to be Basic. Actually, we can make SymTuple((x, y, z)) return the 
same thing as SymTuple(x, y, z) can't we, that is, there is no reason why 
something should not be able to accept more than *.args, though the actual 
.args created will be different?  Or would this be too confusing?  Maybe 
SymTuple((x, y, z)) should actually return SymTuple(SymTuple(x, y, z)).

Aaron Meurer

-- 
You received this message because you are subscribed to the Google Groups 
"sympy-patches" group.
To post to this group, send email to sympy-patc...@googlegroups.com.
To unsubscribe from this group, send email to 
sympy-patches+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy-patches?hl=en.

Reply via email to