On 1 Mai, 05:24, Ronan Lamy <ronan.l...@gmail.com> wrote: > Le vendredi 30 avril 2010 à 19:59 -0600, Aaron S. Meurer a écrit : > > > > > 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,). >
That is right! how silly :-P I had to implement the ._eval_subs method to pass the tests, but that was of course not the proper fix. My first patch is correct in this regard. > > >>> 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]) Exactly, the SymTuple is used in the secondquant module to store upper and lower indices in AntiSymmetricTensor. I needed a way to substitute those indices, and it would not work with the indices stored in a regular tuple. > > > >> 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)). > > I think we should look at this the other way round: there are 2 > reasonable possibilities for the srepr value of SymTuple(Symtuple(x, y, > z)), either SymTuple(x, y, z), representing [x, y, z], just like > tuple(tuple([x, y, z])) is (x, y, z); or SymTuple(Symtuple(x, y, z)), > representing [[x, y, z]]. However, if we choose the first, there is no > easy way to represent [[x, y, z]], so we have to use the second one. And > since SymTuple is sympy's version of tuple, tuple objects and SymTuple > objects must be interchangeable within any sympy expression, so > SymTuple((x, y, z)) has to return SymTuple(SymTuple(x, y, z)). > > This wasn't the solution I favoured a priori, but I'm now convinced that > it's the only sensible one. To convert a tuple, we'll have to use > SymTuple(*a_tuple), though we could implement a classmethod > SymTuple.from_sequence to avoid the overhead caused by > unpacking/repacking the tuple. > > -- > 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 > athttp://groups.google.com/group/sympy-patches?hl=en. I think we have been confusing the tuple *object* with the tuple function which is more like a *cast*. The intended role of the SymTuple is to represent the tuple objects in a form that is also a Basic object, and the casting functionality is less important. This favours Ronans second alternative. To provide the cast functionality from tuple to SymTuple, it would make sense to just use sympify. It would match very well with how the builtin sequence types are converted, i.e. >>> list(SymTuple(1,2,3)) [1,2,3] >>> sympify([1,2,3]) SymTuple(1,2,3) Øyvind -- 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.
