pearu / sympycore

Automatically exported from code.google.com/p/sympycore
Other
11 stars 1 forks source link

At function - a better name? #33

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago

sympycore introduces At function to hold unevaluated
replace/substitute operation. The At function is needed
in situations where applying an operator to function
returns unevaluated result and one needs to evaluate
the result at some point. The typical example is

f = Function('f')
f.fdiff() -> FD(1)(f) -> FDerivative(f,(1,1))
f.fdiff()(2*x) -> At(Derivative(f(x_),(x_,1)), (x_, 2*x))

Does Mathematica have similar a function? Is `At` an appropiate
name here?

Original issue reported on code.google.com by pearu.peterson on 9 Dec 2007 at 1:45

GoogleCodeExporter commented 9 years ago
Yes, At is a nice idea. I don't know how Mathematica handles that.

Original comment by ondrej.c...@gmail.com on 9 Dec 2007 at 3:36

GoogleCodeExporter commented 9 years ago
In Mathematica everything is just an S-expression (like Lisp), and a function
application is represented by simply placing the function as the first element.
f'(2*x) is represented as (((Derivative, 1), f), 2*x).

Original comment by fredrik....@gmail.com on 9 Dec 2007 at 6:20

GoogleCodeExporter commented 9 years ago
Isn't this just "Apply"?

Original comment by fredrik....@gmail.com on 9 Dec 2007 at 6:20

GoogleCodeExporter commented 9 years ago
Indeed, it is closely related to "Apply". Apply was used to
apply functions to arguments but here we are dealing with
"double Apply" - applying operator to function and then
applying the result to arguments. Since we don't need Apply
for applying functions to arguments, then we could reintroduce
Apply to replace At.

Hmm, note that FDerivative(f,(1,1)) is a Function instance while
ideally it should be a Function subclass (as is f) - then we would
not need At or Apply at all. I'll see how difficult would be to
support this..

Original comment by pearu.peterson on 10 Dec 2007 at 7:02

GoogleCodeExporter commented 9 years ago
Regarding the comment #4:

Creating a type object seems to be about 60x slower than
creating a object with an attribute:
>>> class A(object): pass
... 
>>> %timeit a=object.__new__(A);a.attr={}
1000000 loops, best of 3: 561 ns per loop
>>> %timeit type.__new__(type,'a',(),{})
10000 loops, best of 3: 30.3 µs per loop

In applications that would create lots of
unevaluated functions via operators this
speed difference could (not sure if it will)
make a difference in performance compared
to using the Apply/At representation.

So, I am thinking of trying out both approaches
to compare the compexity/efficiency of the 
corresponding implementations.

Original comment by pearu.peterson on 15 Dec 2007 at 10:22

GoogleCodeExporter commented 9 years ago
Agree.

Original comment by ondrej.c...@gmail.com on 15 Dec 2007 at 11:33

GoogleCodeExporter commented 9 years ago
The issue is irrelevant now.

Original comment by pearu.peterson on 12 Feb 2008 at 10:01