Your message dated Mon, 29 Sep 2008 19:13:28 -0500
with message-id <[email protected]>
has caused the report #500521,
regarding fminimizer nmsimplex unnecessary size calculation
to be marked as having been forwarded to the upstream software
author(s) Brian Gough <[email protected]>
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Re: Bug#500521: fminimizer nmsimplex unnecessary size calculation
Mon, 29 Sep 2008 19:13:28 -0500
Ian: Ack, and thanks for the bug report. It is an upstream issue, so I am
passing this on. Did you by chance consider the current 1.11 sources?
Brian: See the description below, as well as the follow-up patch at
http://bugs.debian.org/500521 Comments, esp on the patch, would be
appreciated. I guess this may come back to the oft-discussed issue of
simplicity and clarity of interfaces and usage versus performance.
On 29 September 2008 at 02:21, Ian Jackson wrote:
| Package: gsl
| Version: 1.8-2
| Tags: patch
| Severity: wishlist
| The minimiser
| always computes the simplex size for each step. This is done using
| gsl_blas_dnrm2 which is quite careful. This computation involves
| around n^2 divisions (where n is the problem dimensionality).
| For high-dimensionality problems this can easily dominate useful work.
| The caller might try to work around this by calling
| gsl_multimin_fminimizer_size less often but this is ineffective
| because the size calculation is actually done each time the simplex is
| modified by _iterate or _set.
| The attached patch arranges to
| * not calculate the size unless it is requested
| * cache the returned value so that existing programs are no slower
| Unfortunately this requires us to drop the `const' from the prototype
| of gsl_multimin_fminimizer_size. But I think this is still a good
| An alternative option would be to always call ->get_size and not
| bother caching. That would make slower any existing programs that
| call _fminimizer_size but wouldn't need a change of prototype. That
| might be acceptable given that the performance properties of _size
| are not spelled out.
Three out of two people have difficulties with fractions.
--- End Message ---