Fri 03 May 2013 12:52:08 PM UTC, comment #9:
Yes, the original problem with fminsearch looks fixed to me now, thanks!
|
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.
|
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.
|
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.
|
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.
|
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:
Attached zip contains the above files as well as a script that runs the commands I've shown in the session above.
(file #27992)
|
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):
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.
|
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
with
minfun = nmsmax
funfun = @sin
So why is fminsearch called here at all, and why is it not taken from the package?
|
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:
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.
|
Tue 09 Apr 2013 08:38:13 PM UTC, original submission:
When doing
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.
|