Re: uniform random variable in oct file?

[michael . creel]

I agree that the potential effect of a change in the way the random
number is generated is limited here, what I meant by overhead. But if
feval is very costly, it could be having a big effect, since it is
used by "celleval" every time the objective function is evaluated. If
there is some way to call an objective function, the name of which is
not known a priori to samin or bfgsmin, avoiding feval, I'm very
interested to know about it. That could give a dramatic speedup.
M.

On 9/9/06, Paul Kienzle <address@hidden> wrote:
> On Sep 8, 2006, at 8:45 AM, Michael Creel wrote:
>
> > I'm using this in the samin.cc code. I have switched to the liboctave
> > version. The samin_example.m code (in o-f) took about 6.5 seconds to
> > run on the machine I'm working at, using the old method, and it now
> > takes about 5.25 seconds (timings are inherently random here). So I'm
> > guessing that the fact that the call is made many times, and that
> > caching is working, plus the effect of other overhead, mean that the
> > speedup in this case is not so high as the theoretical speedup for a
> > single call. But it is faster and the code is nicer to read. Thanks,
> > M.
>
> I suspect the objective function is taking a lot of time.
>
> If the random number generator was only taking a fifth of the time
> before then speeding it up can only speed up the whole process by a
> fifth at best.
>
> Even an oct-file objective function won't solve all your problems since
> you will still need to translate values to and from octave values. With
> a bit of work you could send a pointer to the underlying C++ function
> through octave to the optimizer, but still have the function callable
> directly from octave.  I did this in Python without too much
> difficulty.
>
> - Paul