[scilab-Users] Report of potential problems with the nelder-mead series of functions

Sébastien Bihorel pomchip at free.fr
Fri Dec 25 17:14:11 CET 2009


Hi Micheal,

Sorry for the late reply

About issue #1: the purpose was to replaced multiple calls by a single one,
which I believe should in most case make any code faster...

About issue #3: the line of interest was line 497  (or 492 in the beta
version).... but I realize now that I was really tired when I wrote this
email, because of the typo and the lack of rationale of this #3 issue. Sorry
about that!

Sebastien

On Thu, Dec 17, 2009 at 5:25 AM, Michaël Baudin
<michael.baudin at scilab.org>wrote:

> Hi Sébastien,
>
> 1- I do not clearly understand the purpose of the fix you suggest.
> The only effect that I see is to initialize all the points in the simplex
> instead
> of just the first point. Since these datas are overwritten in the other
> loop,
> this is useless to me. I do not see your point here.
>
> 2- You are right. I created the bug report #5669:
> http://bugzilla.scilab.org/show_bug.cgi?id=5669
> fixed the bug and added a unit test in the v5.2 branch.
> (This was a minor problem, though.)
>
> 3- I do not find any such line "newobj$nbve <- n + 1"
> What is the line number that you are interested in ?
>
> Best regards,
>
> Michaël
>
> PS
> Do not hesitate to create bug reports by yourself if you find
> other problems. Whatever the problem, we closely look at them.
>
>
> --
> Michaël Baudin
> Ingénieur de développement
> michael.baudin at scilab.org
> -------------------------
> Consortium Scilab - Digiteo
> Domaine de Voluceau - Rocquencourt
> B.P. 105 - 78153 Le Chesnay Cedex
> Tel. : 01 39 63 56 87 - Fax : 01 39 63 55 94
>
>
>
> Sébastien Bihorel a écrit :
>
>> Thank Michael,
>>
>> A follow-up report concerning the optimsimplex_pfeffer and
>> optimsimplex_randbounds functions:
>> 1- In optimsimplex_pfeffer function, could the following code
>>
>>  //
>>  // Set 1st point
>>  //
>>  newobj.x ( 1 , 1:n ) = x0 (1,1:n)
>>  //
>>  // Set points #2 to #n+1
>>  //
>>  for j = 2 : newobj.n+1
>>    newobj.x ( j,1:n ) = x0 (1:n)
>>    if ( x0( j-1 ) == 0.0 ) then
>>      newobj.x ( j , j-1 ) = deltazero
>>    else
>>      newobj.x ( j , j-1 ) = newobj.x ( j , j-1 ) + deltausual * x0( j-1 )
>>    end
>>  end
>>
>> be replaced by
>>
>>  //
>>  // Set 1st point
>>  //
>>  newobj.x ( 1:newobj.nbve , : ) = x0 (1:n) .*. ones(newobj.nbve ,1);
>>  //
>>  // Set points #2 to #n+1
>>  //
>>  for j = 2 :newobj.nbve
>>    if ( x0( j-1 ) == 0.0 ) then
>>      newobj.x ( j , j-1 ) = deltazero
>>    else
>>      newobj.x ( j , j-1 ) = newobj.x ( j , j-1 ) + deltausual * x0( j-1 )
>>    end
>>  end
>>
>> 2- in optimsimplex_randbounds, there is no check that boundsmin and
>> boundsmax have at least n elements before those calls are made
>>    bminmat = boundsmin( 1,1:n ) .*. ones(nbve-1,1);
>>    bmaxmat = boundsmax( 1,1:n ) .*. ones(nbve-1,1);
>>
>> also, should the line
>>
>> newobj$nbve <- n + 1
>>
>> not be
>>
>> newobj$nbve <- nbve
>>
>> ?
>>
>> Sebastien
>>
>> On Thu, Dec 10, 2009 at 12:02 PM, Michaël Baudin <
>> michael.baudin at scilab.org <mailto:michael.baudin at scilab.org>> wrote:
>>
>>    Hi,
>>
>>    I agree on both points : I will commit a bug fix in branch 5.2
>>    tomorrow.
>>
>>    Best regards,
>>
>>    Michaël
>>
>>    Sébastien Bihorel a écrit :
>>
>>        Hi,
>>
>>        I was reading through the code of the fminsearch function and
>>        its wealth of related functions, and was wondering if there
>>        could be a problem with the optimsimplex.axes function. At
>>        this point, I honestly don't know what it is doing but I think
>>        there might be something wrong with the code:
>>        1- xlen1 is defined but never used. The check that is directly
>>        following its definition is probably supposed to use it but
>>        doesn't
>>           xlen1 = size(len,1)
>>           if size(x0,1)<>1 then
>>             errmsg = msprintf(gettext("%s: The len vector is expected
>>        to be a row matrix, but current shape is %d x
>>        %d"),"optimsimplex_axes",size(len,1),size(len,2));
>>             error(errmsg);
>>           end
>>
>>        2- nothing seems to prevent this call to crash, the dimensions
>>        of xlen and the matrix newobj.x(,) are not cross-checked
>>         newobj.x ( 2:nv , : ) = newobj.x ( 2:nv , : ) + diag(xlen);
>>
>>        HIH
>>
>>        Sebastien
>>
>>
>>
>>    --    Michaël Baudin
>>    Ingénieur de développement
>>    michael.baudin at scilab.org <mailto:michael.baudin at scilab.org>
>>
>>    -------------------------
>>    Consortium Scilab - Digiteo
>>    Domaine de Voluceau - Rocquencourt
>>    B.P. 105 - 78153 Le Chesnay Cedex
>>    Tel. : 01 39 63 56 87 - Fax : 01 39 63 55 94
>>
>>
>>
>>
>>
>> On Fri, Dec 11, 2009 at 6:12 AM, Michaël Baudin <
>> michael.baudin at scilab.org <mailto:michael.baudin at scilab.org>> wrote:
>>
>>    Hi,
>>
>>    I created a bug report :
>>    http://bugzilla.scilab.org/show_bug.cgi?id=5604
>>    and fixed the source code in v5.2 branch :
>>
>> http://gitweb.priv.scilab.org/?p=scilab.git;a=commitdiff;h=8e6a14e2189dde039afc67aaeef3e18aeb0cf869
>>
>>    Before, we had :
>>    -->function y = rosenbrock (x)
>>    -->  y = 100*(x(2)-x(1)^2)^2 + (1-x(1))^2;
>>    -->endfunction
>>    -->newobj = optimsimplex_new ( "axes" , [1 2] , rosenbrock , [1 2
>>    3] );
>>    !--error 8
>>    Inconsistent addition.
>>    at line      39 of function optimsimplex_axes called by : at line
>>         34 of function optimsimplex_new called by : newobj =
>>    optimsimplex_new ( "axes" , [1 2] , rosenbrock , [1 2 3] );
>>
>>    Now, you get the message :
>>    optimsimplex_axes: The len vector is not consistent with the x0
>>    point. Current shape of x0 is 1 x 2 while current shape of len is
>>    1 x 3.
>>    which is much clearer.
>>    By the way, I improved the error messages of other scripts.
>>    Thank you for reporting that problem.
>>
>>
>>    Best regards,
>>
>>    Michaël
>>
>>    Sébastien Bihorel a écrit :
>>
>>        Hi,
>>
>>
>>        I was reading through the code of the fminsearch function and
>>        its wealth of related functions, and was wondering if there
>>        could be a problem with the optimsimplex.axes function. At
>>        this point, I honestly don't know what it is doing but I think
>>        there might be something wrong with the code:
>>        1- xlen1 is defined but never used. The check that is directly
>>        following its definition is probably supposed to use it but
>>        doesn't
>>           xlen1 = size(len,1)
>>           if size(x0,1)<>1 then
>>             errmsg = msprintf(gettext("%s: The len vector is expected
>>        to be a row matrix, but current shape is %d x
>>        %d"),"optimsimplex_axes",size(len,1),size(len,2));
>>             error(errmsg);
>>           end
>>
>>        2- nothing seems to prevent this call to crash, the dimensions
>>        of xlen and the matrix newobj.x(,) are not cross-checked
>>         newobj.x ( 2:nv , : ) = newobj.x ( 2:nv , : ) + diag(xlen);
>>
>>        HIH
>>
>>        Sebastien
>>
>>
>>
>>    --    Michaël Baudin
>>    Ingénieur de développement
>>    michael.baudin at scilab.org <mailto:michael.baudin at scilab.org>
>>
>>    -------------------------
>>    Consortium Scilab - Digiteo
>>    Domaine de Voluceau - Rocquencourt
>>    B.P. 105 - 78153 Le Chesnay Cedex
>>    Tel. : 01 39 63 56 87 - Fax : 01 39 63 55 94
>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20091225/f9faae65/attachment.htm>


More information about the users mailing list