[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Need help for KSpread Maths
From:       Don Sanders <dsanders () cch ! com ! au>
Date:       1999-11-19 13:49:29
[Download RAW message or body]

On Sat, 20 Nov 1999, Leon Widdershoven wrote:
> Don Sanders wrote:
> 
> [SNIP] 
> 
> > "Hooke-Jeeves is slow, It is "wasteful". It is also robust
> > as all get-out. I prefer my program to run for 5 minutes
> > and converge to the minimum 100% of the time, than for it to
> > run for 30 seconds and converge to the minimum 75% of the time.
> > But that's just _my opinion_. Yours may differ."
> > 
> > (I doubt it will take five minutes for normal problems, this was written in
> > 1994 and assumes the function f to have a vector values domain, the hooke.c
> > example runs in a fraction of a second here).
> > 
> 
> Is it in any way possible to predict the time necessary for computations?
> Because I would say that 5 minutes solving time is not a problem, but 
> in that case a progress bar would be nice.
> If it is not possible to predict the number of iterations necessary (I 
> don't know if the size of the steps to convergence can be a measure)
> then there could be at least some signal going out of the routine saying
> "I already did 5 million steps!" or something like that. Which can be
> put in the status bar to let the user see its computing.

A progress bar would also be nice as it would allow you to cancel the operation
in progress. The number of iterations processed divided by the maximum number of
iterations allowed could be used as a progress indicator. This wouldn't be very
accurate though as the hooke.c contains a comment that says the algorithm
seldomly reaches the iteration limit.


> BTW: I do *not* mean to say that I do not agree with your opinion 

I was quoting the implementor Mark Johnson, those were not my words sorry for
the confusion.

> you'd rather wait 5 minutes for a solution that 30 seconds for 
> perhaps nothing. Computation time, in general, is neglegible compared
> to the time users need to find & type the formula.
> And nothing is as frustrating as knowing there is a solution but the 
> damned program can't find it:)  

Agreed. 

Please note that my test runs finished in a fraction of a second. I
think Mark Johnson is used to minimizing functions of many variables, a
comparatively computationally intensive task. Actually if it's only taking a
fraction of a second a progress bar doesn't make very good sense.

Take a look at hooke.c for more info. It's well documented and very small.
ftp://netlib2.cs.utk.edu/opt/hooke.c

BFN,
Don.

[prev in list] [next in list] [prev in thread] [next in thread]