Add method for using PowerSeries to differentiate generic functions

[jverzani]

This isn't written as nicely as it could be, but wouldn't this kind of function be a useful alternative to polyder:

function D(f::Function, k::Int)
    @assert k > 0

    function(x)
        x = series(tuple(x, 1.0, ntuple(k-1, x->0.0)...)...)
        factorial(k) * f(x).(symbol(pop!(names(x)))) # or use polyder!
    end
end

[jwmerrill]

Yes, this seems useful. I think I will just make polyder take a second argument for order.

[jwmerrill]

Sorry, I didn't read this carefully enough. This is for taking derivatives of arbitrary functions, not for taking higher order derivatives of series.

I definitely think this is useful. I'm a little bit uneasy about overloading D this way, though. What if another package comes along and wants to implement a different algorithm for differentiating functions?

[jverzani]

Yes, that is the issue. Somewhere in base there needs to be functions like D, plot, ... that many packages will want to implement and so can be imported.

Perhaps there is a better name in the meantime, but D pops to mind first.

On Thu, Feb 13, 2014 at 12:43 PM, Jason Merrill notifications@github.comwrote:

Sorry, I didn't read this carefully enough. This is for taking derivatives of arbitrary functions, not for taking higher order derivatives of series.

I definitely think this is useful. I'm a little bit uneasy about overloading D this way, though. What if another package comes along and wants to implement a different algorithm for differentiating functions?

Reply to this email directly or view it on GitHubhttps://github.com/jwmerrill/PowerSeries.jl/issues/5#issuecomment-35004750 .

John Verzani Chair, Department of Mathematics College of Staten Island, CUNY verzani@math.csi.cuny.edu

[jwmerrill]

Having a method in base would solve half the issue, but you'd still want a way to dispatch to different algorithms. In your D case, both of the argument types are generic--there's nothing to dispatch on. Using a 3rd argument to specify the algorithm is a possibility.

In any case, I want to think about this one a little more.

On Thu, Feb 13, 2014 at 10:31 AM, john verzani notifications@github.comwrote:

Yes, that is the issue. Somewhere in base there needs to be functions like D, plot, ... that many packages will want to implement and so can be imported.

Perhaps there is a better name in the meantime, but D pops to mind first.

On Thu, Feb 13, 2014 at 12:43 PM, Jason Merrill <notifications@github.com

wrote:

Sorry, I didn't read this carefully enough. This is for taking derivatives of arbitrary functions, not for taking higher order derivatives of series.

I definitely think this is useful. I'm a little bit uneasy about overloading D this way, though. What if another package comes along and wants to implement a different algorithm for differentiating functions?

Reply to this email directly or view it on GitHub< https://github.com/jwmerrill/PowerSeries.jl/issues/5#issuecomment-35004750

.

John Verzani Chair, Department of Mathematics College of Staten Island, CUNY verzani@math.csi.cuny.edu

Reply to this email directly or view it on GitHubhttps://github.com/jwmerrill/PowerSeries.jl/issues/5#issuecomment-35009669 .

[jwmerrill]

I also suspect there will be performance problems with the implementation as given because the type of x is hard to infer. That issue can be worked around, but it's definitely worth benchmarking.

[jverzani]

I was hoping you would have a better implementation :)

This functionality is just a convenient way to get automatic differentiation of functions from R->R which is still fast for higher-order derivatives. (Is there some reason this caps at k=7?) The DualNumbers package doesn't offer this last part at all.

On Thu, Feb 13, 2014 at 1:45 PM, Jason Merrill notifications@github.comwrote:

I also suspect there will be performance problems with the implementation as given because the type of x is hard to infer. That issue can be worked around, but it's definitely worth benchmarking.

Reply to this email directly or view it on GitHubhttps://github.com/jwmerrill/PowerSeries.jl/issues/5#issuecomment-35011175 .

John Verzani Chair, Department of Mathematics College of Staten Island, CUNY verzani@math.csi.cuny.edu

[jwmerrill]

See PowerSeries.generate(order). There's an example at the end of the (long...) interactive session example in the README.

# PowerSeries comes with types defined for series up to order 7. By
default,# trying to construct a higher order series is a type
error.julia> series(0, 1, 2, 3, 4, 5, 6, 7, 8, 9)ERROR: no method
series(Int64, Int64, Int64, Int64, Int64, Int64, Int64, Int64, Int64,
Int64)
# If you want to work with higher order series, you can generate types
up# to a given order with PowerSeries.generate(order)julia>
PowerSeries.generate(9)julia> series(0, 1, 2, 3, 4, 5, 6, 7, 8,
9)Series9{Int64}(0,1,2,3,4,5,6,7,8,9)

The library currently works by generating different types for each series order. I'm not completely in love with that as a design, but it helps a lot with performance. My first prototype represented series as linked lists instead, and was 10x slower for first order series, and even worse for higher order series. There's a (small) cost to generating each type, and I wanted to balance usability with load time. 7th order seemed like a decent default tradeoff.

Many of the algorithms here are cubic in the order of the series, so computing with very high order series isn't practical. There are other algorithms that scale better, but I didn't want to try to implement those until I had a use case for high order series.

On Thu, Feb 13, 2014 at 10:51 AM, john verzani notifications@github.comwrote:

I was hoping you would have a better implementation :)

This functionality is just a convenient way to get automatic differentiation of functions from R->R which is still fast for higher-order derivatives. (Is there some reason this caps at k=7?) The DualNumbers package doesn't offer this last part at all.

[jverzani]

Oh yeah, I had read that at one time. Thanks for explaining. I don't really have a compelling use case for higher order derivatives beyond 7 so this seems like a reasonable trade off.

On Thu, Feb 13, 2014 at 2:12 PM, Jason Merrill notifications@github.comwrote:

See PowerSeries.generate(order). There's an example at the end of the (long...) interactive session example in the README.

# PowerSeries comes with types defined for series up to order 7. By
default,# trying to construct a higher order series is a type
error.julia> series(0, 1, 2, 3, 4, 5, 6, 7, 8, 9)ERROR: no method
series(Int64, Int64, Int64, Int64, Int64, Int64, Int64, Int64, Int64,
Int64)
# If you want to work with higher order series, you can generate types
up# to a given order with PowerSeries.generate(order)julia>
PowerSeries.generate(9)julia> series(0, 1, 2, 3, 4, 5, 6, 7, 8,
9)Series9{Int64}(0,1,2,3,4,5,6,7,8,9)

The library currently works by generating different types for each series order. I'm not completely in love with that as a design, but it helps a lot with performance. My first prototype represented series as linked lists instead, and was 10x slower for first order series, and even worse for higher order series. There's a (small) cost to generating each type, and I wanted to balance usability with load time. 7th order seemed like a decent default tradeoff.

Many of the algorithms here are cubic in the order of the series, so computing with very high order series isn't practical. There are other algorithms that scale better, but I didn't want to try to implement those until I had a use case for high order series.

On Thu, Feb 13, 2014 at 10:51 AM, john verzani <notifications@github.com

wrote:

I was hoping you would have a better implementation :)

This functionality is just a convenient way to get automatic differentiation of functions from R->R which is still fast for higher-order derivatives. (Is there some reason this caps at k=7?) The DualNumbers package doesn't offer this last part at all.

Reply to this email directly or view it on GitHubhttps://github.com/jwmerrill/PowerSeries.jl/issues/5#issuecomment-35014072 .

John Verzani Chair, Department of Mathematics College of Staten Island, CUNY verzani@math.csi.cuny.edu