ANN: NLsolve.jl

[Sébastien Villemot]

Hi,

As promised, I have created a package for solving systems of nonlinear
equations.

https://github.com/EconForge/NLsolve.jl

It is now in pretty good shape and quite usable. It has just been
accepted as an official Julia package, and should therefore be listed
soon on the Julia webpage.

If you have the time, please give it a try. I'll make the first numbered
release soon, possibly incorporating your feedback.

Happy new year!

--
Sébastien Villemot
Researcher in Economics
Dynare developer
http://www.dynare.org/sebastien

[Pablo Winant]

Thank you Sebastien (and happy new year to everybody)

I have been willing to play a bit with your code since you when you posted it. Overall it seems very neat and useful to me.

Do you think it would require a lot of architectural changes to have sparse Jacobian support ? One other thing that could possible fit into that package would be some simple complementarity solver.

I also have a few remarks about the code:

1/ I understand that you don't want to allocate memory unnecessarily but it is surprising at first to see that one cannot directly find the rooth of a simple function  `f(x) = sin(x)`, because the solver expects it to write its output in a second argument. I don't know how you could deal with that case, maybe by checking the function arity, or by having another convenience function to use instead of `nlsolve`, or maybe that particular complexity could be hidden in the `DifferentiableFunction` type.

2/ Speaking of which I like the fact that using a `DifferentiableFunction` object, you can deal with the various cases where the user has a function that computes the function and its derivative, together or separately. But it seems to me that the the most common cases one would encounter are (`f`), (`f` and `g`) or (`fg`). Maybe different subtypes would be good too so that a routine can optionally specialize on the more efficient call order.

3/ So the exclamation mark means inplace operations as in ruby. But what does it mean in `linesearch! = Optim.backtracking_linesearch!` ?

Best,

Pablo

[Sébastien Villemot]

Le jeudi 09 janvier 2014 à 06:54 -0800, Pablo Winant a écrit :

> I have been willing to play a bit with your code since you when you
> posted it. Overall it seems very neat and useful to me.

Thanks for your answer, and sorry for the delay.

> Do you think it would require a lot of architectural changes to have
> sparse Jacobian support ? One other thing that could possible fit into
> that package would be some simple complementarity solver.

I suggest that you open issues about these.

> I also have a few remarks about the code:
>
> 1/ I understand that you don't want to allocate memory unnecessarily
> but it is surprising at first to see that one cannot directly find the
> rooth of a simple function `f(x) = sin(x)`, because the solver
> expects it to write its output in a second argument. I don't know how
> you could deal with that case, maybe by checking the function arity,
> or by having another convenience function to use instead of `nlsolve`,
> or maybe that particular complexity could be hidden in the
> `DifferentiableFunction` type.

Again, please open an issue. I'm sure we can indeed improve on the
current interface.

> 2/ Speaking of which I like the fact that using a
> `DifferentiableFunction` object, you can deal with the various cases
> where the user has a function that computes the function and its
> derivative, together or separately. But it seems to me that the the
> most common cases one would encounter are (`f`), (`f` and `g`) or
> (`fg`). Maybe different subtypes would be good too so that a routine
> can optionally specialize on the more efficient call order.

Same answer.

> 3/ So the exclamation mark means inplace operations as in ruby. But
> what does it mean in `linesearch! = Optim.backtracking_linesearch!` ?

As you know, it's just a convention meaning that the function modifies
its arguments. linesearch! is a functional parameter of nlsolve(), and
it's expected to be a function that modifies its arguments, hence I put
the mark. And Optim.backtracking_linesearch! is a function from the
Optim package, and it happens to bear the mark because of the same
convention.

[Pablo Winant]

For the record here, I have opened the corresponding issues on Github.