bugGNU Octave - Bugs: bug #38691, optim package conflicting with...

 
 

bug #38691: optim package conflicting with octave's optimization

Submitter:  Muhali <muhali>
Submitted:  Tue 09 Apr 2013 08:38:13 PM UTC
   
 
Category:  Octave Package Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 03 May 2013 12:52:08 PM UTC, comment #9: 

Yes, the original problem with fminsearch looks fixed to me now, thanks!

Mike Miller <mtmiller>
Group Member
Fri 03 May 2013 05:22:47 AM UTC, comment #8: 

I checked in the following changeset:

http://hg.savannah.gnu.org/hgweb/octave/rev/2f8fb02a6c31

If this fixes the original problem for you and doesn't create any new trouble, please close this report.

John W. Eaton <jwe>
Group administrator
Thu 02 May 2013 10:59:21 PM UTC, comment #7: 

OK, this bug reminded me how confusing the symbol table code is (gotta fix that some day) and took way too long to come up with a reasonable solution, but I think I have one.  It's too big for the margin of this text box, though, so I'll have to check it in later.

John W. Eaton <jwe>
Group administrator
Thu 02 May 2013 09:22:50 AM UTC, comment #6: 

Hmm, my attempts to fix this problem have uncovered some memory management issues in the symbol table classes.

John W. Eaton <jwe>
Group administrator
Thu 02 May 2013 04:40:37 AM UTC, comment #5: 

The subfunctions defined in dir1/func1 are somehow being used when dir2/func2 is called.  I think it is happening because subfunctions are not being cleared properly when the path changes, but I'm not sure yet.  I'll have to do a little more digging.

John W. Eaton <jwe>
Group administrator
Thu 02 May 2013 03:31:27 AM UTC, comment #4: 

This took a while but I have a standalone test that demonstrates the problem in the function resolution being seen here. As a workaround, "clear -f" makes fminsearch work again after the optim package has been added to the path.

I don't have an idea where occurs yet, but I've started reading into the symbol table classes. Of course input from someone else more familiar with the symbol table would be welcome.

Example follows:


$ ls -R dir*
dir1:
func1.m

dir2:
func1.m  func2.m  func3.m
$ octave -qf
octave:1> addpath ("dir1")
octave:2> func1 (0)
dir1/func1 (0)
dir1/func2 (0)
dir1/func3 (0)
ans = 0
octave:3> addpath ("dir2")
octave:4> func1 (0)
dir2/func1 (0)
dir2/func2 (0)
dir1/func3 (0)
ans = 0
octave:5> clear -f
octave:6> func1 (0)
dir2/func1 (0)
dir2/func2 (0)
dir2/func3 (0)
ans =  3.1416


Attached zip contains the above files as well as a script that runs the commands I've shown in the session above.

(file #27992)

Mike Miller <mtmiller>
Group Member
Wed 10 Apr 2013 01:11:33 PM UTC, comment #3: 

I see now. Here is the stack at the time of the error (setting debug_on_error followed by dbstack):


stopped in:

  -->              print_usage at line 88 [/opt/gnu/octave/share/octave/3.7.2+/m/help/print_usage.m]
                      optimget at line 32 [/opt/gnu/octave/share/octave/3.7.2+/m/optimization/optimget.m]
      fminsearch>parse_options at line 126 [/opt/gnu/octave/share/octave/3.7.2+/m/optimization/fminsearch.m]
             fminsearch>nmsmax at line 159 [/opt/gnu/octave/share/octave/3.7.2+/m/optimization/fminsearch.m]
                         fmins at line 77 [/home/mike/octave/optim-1.2.2/fmins.m]
                    fminsearch at line 33 [/home/mike/octave/optim-1.2.2/fminsearch.m]
debug> which nmsmax
'nmsmax' is a function from the file /home/mike/octave/optim-1.2.2/nmsmax.m


So the nmsmax private function in Octave's fminsearch.m is taking precedence over the public nmsmax in the optim package, even though that copy of fminsearch was not called.

Mike Miller <mtmiller>
Group Member
Wed 10 Apr 2013 06:11:13 AM UTC, comment #2: 

the question is why in these lines



error: /usr/local/octave-dev/share/octave/3.7.2+/m/optimization/fminsearch.m at line 159, column 41
error: /usr/local/octave-dev/share/octave/packages/optim-1.2.2/fmins.m at line 77, column 10
error: /usr/local/octave-dev/share/octave/packages/optim-1.2.2/fminsearch.m at line 33, column 6



fminsearch is first taken from the package (3rd line) and then from octave (1st line). Note the order is reversed in this error report. Or in other words, why is fminsearch called a second time here (1st line)? line 77 of fmins.m is


    ret = feval(minfun, funfun,  X0, stopit, [], varargin{:});


with

minfun = nmsmax
funfun = @sin

So why is fminsearch called here at all, and why is it not taken from the package?

Muhali <muhali>
Wed 10 Apr 2013 12:53:46 AM UTC, comment #1: 

You have changed the path by loading the optim package. Or do you mean changing the working directory?

Here's what I get:


octave:1> which fminsearch
'fminsearch' is a function from the file /opt/gnu/octave/share/octave/3.7.2+/m/optimization/fminsearch.m
octave:2> pkg load optim
warning: function /home/mike/octave/optim-1.2.2/fminsearch.m shadows a core library function
octave:3> which fminsearch
'fminsearch' is a function from the file /home/mike/octave/optim-1.2.2/fminsearch.m


Does the warning message address the problem that you are reporting?

I notice the warning does not show if I use ./run-octave in the build directory.

Mike Miller <mtmiller>
Group Member
Tue 09 Apr 2013 08:38:13 PM UTC, original submission:  

When doing


fminsearch(@sin, 0)
pkg load optim
fminsearch(@sin, 0)


one gets the interesting result



ans = -1.57
error: Invalid call to optimget.  Correct usage is:

 -- Function File:  optimget (OPTIONS, PARNAME)
 -- Function File:  optimget (OPTIONS, PARNAME, DEFAULT)
 
error: called from:
error:   /usr/local/octave-dev/share/octave/3.7.2+/m/help/print_usage.m at line 88, column 5
error:   /usr/local/octave-dev/share/octave/3.7.2+/m/optimization/optimget.m at line 32, column 5
error:   /usr/local/octave-dev/share/octave/3.7.2+/m/optimization/fminsearch.m at line 126, column 14
error:   /usr/local/octave-dev/share/octave/3.7.2+/m/optimization/fminsearch.m at line 159, column 41
error:   /usr/local/octave-dev/share/octave/packages/optim-1.2.2/fmins.m at line 77, column 10
error:   /usr/local/octave-dev/share/octave/packages/optim-1.2.2/fminsearch.m at line 33, column 6



Note the two different calls to fminsearch without ever changing the path.

Muhali <muhali>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #27992:  subfuncpaths.zip added by mtmiller (1KiB - application/zip)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by muhali (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-05-03 mtmiller StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2013-05-02 mtmiller Attached File- Added subfuncpaths.zip, #27992
    2013-04-10 mtmiller StatusNeed Info Confirmed
    2013-04-10 mtmiller StatusNone Need Info
        Operating SystemGNU/Linux Any

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code