# Can the function "Taylor" process the input type "Function handle" directly?

1 view (last 30 days)

Commented: 祥宇 崔 on 27 Jun 2022
Like what I said, every time I use the "taylor" function, I need to convert the function to a symbolic equation, which isn't very convenient because sometims these two things can't be converted, eg:
Apparently, integ_func is a function handle. And this can't be converted because of the integral term.

John D'Errico on 26 Jun 2022
Edited: John D'Errico on 26 Jun 2022
Can taylor handle some completely general function handle? No. Why not?
A Taylor series is easy to compute, in theory. The coefficients of the terms are just derivatives, of increasing order for each power of x, so as long as you can symbolically differentiate what you give it, and do so for arbitrarily high orders of differentiation as needed by the number of terms in your Taylor series there is no problem.
The problem arises when you want to give the function taylor some general function handle. In this case, you have written a function handle that internally uses a call to integral, which does an ADAPTIVE numerical integration. Taylor cannot solve that problem. Sorry. In general, Taylor NEEDS a function it can symbolically differentiate. Even then, not all functions have Taylor series.
John D'Errico on 27 Jun 2022
Interesting question. I doubt it would work with VPA, because it was never written in that context. So some of the derivative approximations were actually written using linear algebra to generate them. In theory however, it could do so, and then the Richardson extrapolations could be quite high order, as long as the function is itself infintely differentiable. So, yes, it could work nicely then. It hs been a long time since I wrote that code, but I recall the general ideas pretty well.
Working in double precision, there is sort of a sweet spot that I needed to work with. For example, suppose you want to approximate a derivative. Derivest uses a sequence of function evals, approaching arbitrarily closely to the point in question. I'll use sin(x) as an example.
fun = @sin;
Now assume we want to compute the derivative of fun at x0==1. Generate a geometric sequence of points, increasing in distance away from x0.
format long g
x0 = 1;
xseq = x0 + logspace(-15,1,10)'
xseq = 10×1
1 1.00000000000006 1.00000000000359 1.00000000021544 1.0000000129155 1.00000077426368 1.00004641588834 1.00278255940221 1.16681005372001 11
The problem is, if fun is a black box, we don't really know much about the shape of fun. So it is not clear where we need to best sample the function to get a good estimate of the derivative.
fpapprox = (fun(xseq(2:end)) - fun(xseq(1)))./(xseq(2:end) - xseq(1))
fpapprox = 9×1
0.541509433962264 0.540327564894932 0.540302350077195 0.540302308791902 0.540301980167428 0.540282776862684 0.539130887896137 0.467779763398602 -0.18414611913586
Now, we know the derivative of fun at x==1, is just
cos(x0)
ans =
0.54030230586814
So in fact, the best approximation for the derivative of fun at x=x0 (for THIS particular low order approximation for the derivative) seems to arise when the increment dx is around 1e-8. The problem is that double precision is failing us. If a high precision arithmetic had been employed, then we would have no problems for an infinitessimally small dx.
In fact, had a higher precision arithmetic utility been used there, I could have avoided much of the crap I went through in derivest to find the best possible estimates.

### Categories

Find more on Calculus in Help Center and File Exchange

R2020b

### Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!