On Sep 2, 2010, at 11:57 PM, Rahul Siddharthan wrote:
> Aaron, Chris,
> Thanks for the replies!
>
> Aaron wrote:
>> This is great. SymPy code is *MUCH* easier to read than some lisp, in my
>> opinion.
>
> So far, yes and no. The main thing is that I needed to implement
> structured "tuples" as defined in SICM, and functions that take tuples
> as arguments, and derivatives/partial derivatives of those functions.
> I defined my own class for those things, but with higher-order
> functions (functions that return functions, which is done all the time
> in SICM) it gets a bit inelegant. Still, I think most of the
> infrastructure is done: I will put up what I have, and ask about
> prettyfication, shortly.
>
> Chris wrote:
>
>> what you could try doing is "masking" the derivatives--replace them
>> with symbols of your own
>
> That's exactly what I ended up doing, but in a much more longwinded
> way than what you wrote.
I think if cse() were fixed to use dummy Functions instead of dummy Symbols, it
would work, i.e., instead of replacing cos(x)*sin(y) with t0, replace it with
t0(x, y) (or more generally, Function("t0")(*sorted(expr.atoms())). The only
problem is that, while we have a Dummy class for Symbols that prevents using
the same symbol that is already in an expression, we don't have the same such
thing for Functions.
I think it shouldn't be too hard to implement
class DummyFunction(Dummy, Function):
See the issues I referenced in the previous email.
Aaron Meurer
>
> The other issue that came up is, I see from the archives, again a
> known problem: if I want to define multiplication for "tuples", a
> multiplication of a tuple by a scalar (on the left or the right) is
> the tuple of each component multiplied by the scalar. I define the
> __mul__ and __rmul__ methods, but __rmul__ fails to get called when
> the scalar is a sympy object, because scalar defines a __mul__ that
> can handle other sympy objects and I get, eg,
> r * (1,2)
> instead of
> (r, 2*r)
> (I am using the Basic class for my tuples). If I don't know that r is
> a scalar, of course, the first answer is right and the second need not
> be right. But even when r is a sympified number, it fails to expand:
>
> a = up(1,2) # (up and down are tuple-generating functions in my library)
> b = 3
> b*a
> (output)=> (3, 6) (desired answer)
> b = sympify(3)
> b*a
> (output)=> 3⋅(1, 2) (not the desired answer!)
>
> I am currently using the workaround of unsympifying all numbers...
>
> Rahul
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
