[Octave-bug-tracker] [bug #63708] [octave forge] (optim) lsqnonlin cannot take x0 with arbitrary size

[Nicholas Jankowski]

URL:
  <https://savannah.gnu.org/bugs/?63708>

                 Summary: [octave forge] (optim) lsqnonlin cannot take x0 with
arbitrary size
                 Project: GNU Octave
               Submitter: nrjank
               Submitted: Wed 25 Jan 2023 05:50:47 PM EST
                Category: Octave Forge Package
                Severity: 2 - Minor
                Priority: 5 - Normal
              Item Group: Matlab Compatibility
                  Status: Confirmed
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
                 Release: other
         Discussion Lock: Any
        Operating System: Any
           Fixed Release: None
         Planned Release: None


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Wed 25 Jan 2023 05:50:47 PM EST By: Nicholas Jankowski <nrjank>
as initially reported over on stackoverflow [1], code that runs in Matlab's
lsqnonlin throws a nonconformant argument error in octave with optim 1.6.2. 
if the supplied function expects the input to be anything other than a column
vector, it will either error or produce erroneous outputs because internally
the variable is always passed as a column vector. This can cause functions
that assume either matrix operations or broadcasting to fail.

According to the current matlab help for lsqnonlin [2], it determines from the
supplied x0 what the shape of the input to F should be.  Have not checked, but
I suspect this is a change in matlab behavior. A quick search for an archived
older version of the help [3] shows it mandated a vector, and that F should be
a vector-valued function returning the same size vector, but doesn't mandate
orientation.


Not a minimal example, but example from stackoverflow (input data file 'hd'
attached):


pkg load optim
D = dlmread('hd', ';'); % raw data
bkg = D(1,2:end); % 4 sensors bkg
x = D(2:end,1); % input signal
Y = D(2:end,2:end); % 4 sensors reposnse
W = 1./Y; % weights
b0 = [7 .04 .01 .1 .5 2 1]; % educated guess for start the fit
%% model function
F = @(b) ((bkg + (b(1) - bkg).*(1-exp(-(b(2:5).*x).^b(6))).^b(7)) - Y) .* W;
opts = optimset("Display", "iter");
lb = [5 .001 .001 .001 .001 .01 1];
ub = [];
[b, resnorm, residual, exitflag, output, lambda, Jacob] =
lsqnonlin(F,b0,lb,ub,opts)


which results in:


>> [b, resnorm, residual, exitflag, output, lambda, Jacob] =
lsqnonlin(F,b0,lb,ub,opts)
error: product: nonconformant arguments (op1 is 4x1, op2 is 34x1)
error: called from
    @<anonymous> at line 1 column 72
    __maybe_limit_arg_count__>@<anonymous> at line 30 column 26
    __nonlin_residmin__ at line 310 column 9
    nonlin_residmin at line 99 column 25
    lsqnonlin at line 264 column 21


stepping through the functions, lsqnonlin line 195 recasts the input x0 as
x0(:), and later ___nonlin_residmin___ does call the supplied function with
that column vector. 

For compatibility it looks like we should change this, but it's unclear what
else if anything might have to change to accommodate arbitrary x0 shape.  At a
minumum if I just remove the (:) i then get an error: 

error: initial parameters must be either a structure or a column vector
error: called from
    __nonlin_residmin__ at line 102 column 7
    nonlin_residmin at line 99 column 25
    lsqnonlin at line 264 column 21

[1] https://stackoverflow.com/questions/75229081/non-linear-fit-gnu-octave

[2]
https://www.mathworks.com/help/optim/ug/lsqnonlin.html#buuhch7_sep_shared-x0

[3]
http://www.ece.northwestern.edu/local-apps/matlabhelp/toolbox/optim/lsqnonlin.html






    _______________________________________________________
File Attachments:


-------------------------------------------------------
Date: Wed 25 Jan 2023 05:50:47 PM EST  Name: hd  Size: 1KiB   By: nrjank
input data file (semicolon separated text) 
<http://savannah.gnu.org/bugs/download.php?file_id=54263>

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63708>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/