On Sat, 2007-08-04 at 16:37 -0400, Andrew Clausen wrote:
> Hi Manuel,
>
> My multimin() wrapper will be merged into the Rgsl package. I expect that the
> wrapper doesn't do anything special (compared to the rest of Rgsl) to break
> the
> compilation -- you're just having trouble with my very cru
I don't have an example of that but that does not make it less
desirable. If one wants to use method 1, 2 or 3 then one can
use optim with a method= but if one wants to use methods 4
or 5 then one must use an entirely different function. Surely
it would be better to be consistent from the user's
Hi Manuel,
My multimin() wrapper will be merged into the Rgsl package. I expect that the
wrapper doesn't do anything special (compared to the rest of Rgsl) to break the
compilation -- you're just having trouble with my very crude and temporary
Makefile.
Does Rgsl work for you?
If it does, you c
Thanks for the functions!
I tried installing the multimin function. To get it to compile, I needed
to change the Makefile to reflect my path and by adding the flags fPIC
in response to the error: "/usr/bin/ld: vector.o: relocation R_X86_64_32
against `a local symbol' can not be used when making a
On 04/08/2007 2:53 PM, Gabor Grothendieck wrote:
> The example of generic functions.
Show me an example where we have a list of ways to do a calculation
passed as an argument (analogous to the method argument of optim), where
the user is allowed to add his own function to the list.
Duncan Murdo
The example of generic functions.
On 8/4/07, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
> On 04/08/2007 2:23 PM, Gabor Grothendieck wrote:
> > For the same reason that generic functions exist. They don't have
> > a lot of common code but it makes easier to use. Perhaps the argument
> > is not as
Hi,
In my earlier post I eluded to a situation where that would be useful.
In nlme, there is a choice of optimizers, minpack.lm has
Levenberg-Marquardt,
while nlminb has the port routines. For the same starting values,
different
optimizers will present different solutions, having a common interfac
On 04/08/2007 2:23 PM, Gabor Grothendieck wrote:
> For the same reason that generic functions exist. They don't have
> a lot of common code but it makes easier to use. Perhaps the argument
> is not as strong here since the class tends to be implicit whereas the
> method is explicit but it would s
For the same reason that generic functions exist. They don't have
a lot of common code but it makes easier to use. Perhaps the argument
is not as strong here since the class tends to be implicit whereas the
method is explicit but it would still be a convenience.
On 8/4/07, Duncan Murdoch <[EMAIL
On 04/08/2007 1:05 PM, Gabor Grothendieck wrote:
> I think it would be desirable for optim to have a dispatching mechanism
> that allows users to add their own optimization techniques to those
> provided without having to modify optim and without having to come
> up with a new visible function. Fo
I think it would be desirable for optim to have a dispatching mechanism
that allows users to add their own optimization techniques to those
provided without having to modify optim and without having to come
up with a new visible function. For example, if we call optim as
optim(...whatever..., meth
On 04/08/2007 10:30 AM, Andrew Clausen wrote:
> Hi Duncan,
>
> On Sat, Aug 04, 2007 at 09:25:39AM -0400, Duncan Murdoch wrote:
>> This is interesting work; thanks for doing it. Could I make a
>> suggestion? Why not put together a package containing those test
>> optimization problems, and offe
Hi Andrew,
I have been working quite a bit with optim and friends on automated
nonlinear fitting, mainly for calibration. All of the optimizers
seem to have trouble in the tricky situation of fitting a log-logistic
model when the upper asymptote is not well defined, and trying to
estimate a vari
Hi Duncan,
On Sat, Aug 04, 2007 at 09:25:39AM -0400, Duncan Murdoch wrote:
> This is interesting work; thanks for doing it. Could I make a
> suggestion? Why not put together a package containing those test
> optimization problems, and offer to include other interesting ones as
> they arise?
Hi Pat,
On Sat, Aug 04, 2007 at 09:59:57AM +0100, Patrick Burns wrote:
> Sounds like a good project.
Thanks :)
> How much extra overhead are you getting from the
> algorithm being in R?
On the Rosenbrock function (which is very quick to evaluate), here are the
system.time() results:
> system.t
On 04/08/2007 1:12 AM, Andrew Clausen wrote:
> Hi all,
>
> I've been working on improving R's optim() command, which does general purpose
> unconstrained optimization. Obviously, this is important for many statistics
> computations, such as maximum likelihood, method of moments, etc. I have
> fo
16 matches
Mail list logo
