>>> The absence of test failures only shows that a feature that didn't exist
>>> wasn't used. As for special cases, I already mentioned the Expr vs Basic
>>> thing (why is this implemented only for Expr, when callability is
>>> unrelated to the concept of Expr?), but the special handling of Symbol
>>> is also a problem and the complicated implementation of Expr.__call__
>>> probably makes assumptions that can be broken. Also, if any Expr
>>> subclass with a Lambda in its args will cause problems.
>
> I agree that could be an issue. Perhaps this could be an argument for
> not putting it in Basic, that a Basic (but not Expr) object is more
> likely to have some Lambda somewhere in its args that doesn't expect
> to be recursively called.
>
> Do we have any classes in SymPy with Lambda in their .args?
I know of TransformationSet and RootSum, but we could certainly create
more and users can too.
>>>
>> Yes, I agree. These should be discussed further, however I do not
>> think that these are show-stoppers. I would prefer to finish with the
>> examples from Aaron before proceeding on this.
>
>
> Most of my examples are syntactic sugar (but I guess this whole thing
> is just syntactic sugar). A nice example would be replace. You could
> do expr.replace(sin**2 + cos**2, 1). Right now you'd either have to
> do expr.replace(Lambda(x, sin(x)**2 + cos(x)**2), 1) or
> expr.replace(sin(a)**2 + cos(a)**2, 1), where a = Wild('a').
Well, this can't work without solving issue 1688, but even then, this would
be a very implicit syntax that could easily do too much or too little, just
like expr.subs(exp(x), ...) which you've repeatedly complained about.
>
> But actually it would be more useful than even just that. Anywhere
> where you would use Lambda or .subs(x, y) (or defining a simple Python
> function that returns an expression), you could just use this instead.
> So instead of something like
>
> def my_expr(x):
> return some_SymPy_expression_in_terms_of_x
>
> you could just have the expression itself, as a function.
f(x) isn't the same thing as f, so I guess that what you mean isn't the
expression itself, but another one that involves only functions, but not x.
This can get confusing quickly if the expression is complicated.
> This is somewhat related to my previous discussion about replacing
> f(x, y) with an expression evaluated at x and y (see
> https://groups.google.com/forum/?hl=en_US&fromgroups#!searchin/sympy/evaluate/sympy/TsRxB8HnUuI/moOq251RBpcJ).
> If this were implemented I could just do expr.subs(psi,
> z**Id[1]*exp(-I*omega(z)*Id[2]) (this is also why we need a more
> powerful identity function, as I noted on the issue).
I find expr.subs(psi, Lambda([x, y], z**x*exp(-I*omega(z)*y))) easier to
understand.
> I know that Lambdas can be used to do a lot of these things, but
> Lambda is inherently crippled in that if you want to mainpulate the
> expression in the Lambda at all, you have to peel off the Lambda
> first. With this, you don't have to do any of that. You can even use
> Lambdas if you want, though if you do, you can run into the issue
> where some part of an expression is "stuck" in the Lambda (like
> Lambda(x, x + 1) - 1).
>
> As another example, if I have an iterative function, like
>
> f(xn) = x_(n - 1)*(x_(n - 1) - 1)
>
> You can compute something like,
>
> f = Lambda(x, x*(x - 1)) # or Id*(Id - 1)
> f2 = f(f)
> f3 = f2(f)
>
> and then f, f2, and f3 are all callables, for which you can just say
> f(0.3), f2(0.3), f3(0.3) and get numbers back.
I find this quite confusing. Is f2 equal to f o f? As for f3, I don't
understand
it at all. I'm not sure that it's even possible for a mathematical function
(with specified domain and range) to belong to its own domain of definition.
> In short, you eliminate the need for named dummy variables with this,
> because they aren't there at all.
OK, avoiding dummy variables can sometimes be advantageous.
> I can attest from my personal experience that this sort of thing would
> be very useful. I use these patterns quite often, especially the
> .subs(x, y) pattern, and I've often felt that if I could define the
> whole expression as a function directly that it would make things much
> easier. I've done the def my_expr(x): ... thing, and (when I remember
> that it exists) created a Lambda, but those are both limited in that
> the expression is "stuck" inside the function or Lambda (at least with
> Lambda you can see what it is and get it out if you want, though). If
> I want to perform any kind of simplification or modify the expression
> at all I have to recreate the function or Lambda.
>
> Aaron Meurer
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> 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 sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
