>>> * Why is this new behaviour limited to Expr? Callability and >>> existence of arithmetic operations are orthogonal concepts. >> I did not understand the question. A possible answer if I understand >> would be: The idea is to have an identity between "1 + function(arg -> >> f(arg))" and "function(arg -> 1+f(arg))". It is a very frequent "abuse >> of notation". Admittedly, "abuses of notation" should rarely be >> implemented in CAS, however this does not interfere with the rest of >> sympy and it can be made rigorous by stating "arithmetics and function >> definition commute". As I already mentioned a precedent can be seen in >> "Functional Differential Geometry" by Sussman and Wisdom. > > I think what he's saying is that if we have this, it should go in > Basic, not Expr. > To me this seems related to the question of merging Basic and Expr. Please excuse me if there are obvious reasons against the merge, it is just that I do not know them for the moment. I propose that we put off this discussion for later.
>> >>> >>> * What about function arity? If f = Lambda(x, x) and >>> g = Lambda((x, y), x+y), what is 1 + f + g? >> Quite seriously I would answer "Why should we care?". It would be nice >> to have partial (lazy) evaluation, but even if we do not have it, this >> would be considered just an mis-formed expression that should not be >> created (I like more the partial evaluation possibility). Also, we >> have already discussed something like this during the argument about >> "symbolic lazy nsolve" https://github.com/sympy/sympy/pull/968 . I >> would very much like to continue the discussion about this pull >> request as I had some unanswered questions. The most important one was >> about the "infinitely evaluated" semantics used by Mathematica. I left >> a reference to some documentation on the subject but I did not get any >> answers. > > Partial evaluation (a.k.a. currying) is an interesting idea, but it's > probably better for this expression to just raise an error (it would > do so at call time, to avoid overhead in Add). > > What was the Mathematica thing? Can you give a link? > Two details about Mathematica (that maybe I misunderstand): - less importantly: it permits you to write nonsense: Integral[Manifold[Circle[InputFile[blah blah]]]] will not raise an error, it will just be left unevaluated because Integral does not know what to do with Manifold which does not know ... etc. - this leads us to "infinite evaluation system" reference.wolfram.com/legacy/v1/contents/4.2.7.pdf 2nd paragraph To quote: "In Mathematica the evaluation goes on until the result you get no longer change." Two examples how this is useful: - It permits the user to create AST with sympy expression that may not make sense for sympy, but that make sense in the formalism that the user implements. At the moment this is not always possible as sympy is rather draconian about raising errors and demanding that everything is Expr (not Basic). - The symbolic nsolve I was talking about. If there are too many free symbols nsolve can not change and thus it returns symbolic unevaluated version of itself. Obviously the parallels with Mathematica are flawed as this is a feature of the language that Python does not support and that we are only emulating. >> >>> >>> * 1 + Function('f') can't work anyway, because Function('f') is a >>> class, not a sympy object. >> This is a second time that you mention this argument. I have some >> questions about it. >> >> Actually Lambda has the same semantics as Function and it works >> perfectly with this (just because it subclasses Expr). I have some >> open questions about this on our recent discussion on the mailing list >> "why is Lambda not subclassing Applications". > > Does this also apply to 1 + sin? Personally I think we should change > how Function('f') works, if just for issue 1198. > It should apply but it does not because you can not write 1+sin because Add accepts only Expr. Ether Add should be less picky or sin (ugh... Function?) should subclass Expr. Also here we have much black magic and jumping through circles during the creation of sin(x) with what I consider an excessive use of metaclasses. However I may be very very wrong on this one (more than usual ;) > I can say, however, that if this worked that it would be extremely > useful. I can give examples if anyone wants convincing of that. > When you have the time some more examples will be useful for me, as I may be missing some of the details. -- 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.
