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//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<
#5 (comment)

.

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//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//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//issues/5#issuecomment-35014072
.

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