bugGNU Octave - Bugs: bug #36686, Saving and loading function...

 
 

bug #36686: Saving and loading function handles that point to subfunctions is not working correctly

Submitted by:  Giulio Mancuso <giuliosssup>
Submitted on:  Tue 19 Jun 2012 07:20:23 PM UTC  
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  dev Operating System:  Any

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Thu 14 May 2020 08:41:20 PM UTC, comment #8: 

I've been working on improving function handles.  See this mailing list thread:

https://lists.gnu.org/archive/html/octave-maintainers/2020-05/msg00066.html

Saving and loading handles to functions is kind of a weird thing to do, especially so for functions that are private in some way (subfunctions, local functions, private functions) or that carry additional info with them (nested functions) or that depend class data to work (class methods).  In any case, maybe we can make some of these features work.

In my recent changes, Octave now creates a proper scopedfunction function handle object that contains a reference to the scoped fucntion, the name of the file where the function is found, and parent function info.  This should allow us to correctly save and load handles to subfunctions, local functions, and private functions and make them available on loading even after "clear functions" or in a new Octave session.

If I understand correctly, we need to do something like the following after loading the function handle from the file:

  • check the currently loaded functions to see whether the referenced function is already loaded.
  • If it is, add a reference to it to the newly loaded handle object.
  • If not, attempt to load the primary parent function, then search for the appropriate subfunction.

Determining whether the function is already loaded is a bit tricky because of possible changes in the load path.  It's not entirely clear how to do this in a 100% reliable way.  It seem there could be many ways to end up referencing the wrong function.

John W. Eaton <jwe>
Project Administrator
Mon 21 Nov 2016 09:31:17 PM UTC, comment #7: 

Alright, now I got the point. This behavior IS still present in Octave 4.2.0.

Here is what I did to reproduce it (to maybe make it easier to reproduce for others):

  • create a file "create_func.m" with this content:

    function [model] = create_func
    model.odefun = @gas_phase_ODE;
    end

    function dxdt = gas_phase_ODE(x,t)
      k_ = 0.16;
      v = [-2 1];
      r = k_*x(1)^2;
      dxdt = v'*r;
    end

  • create a second file "main.m" with this content:

    clear all

    model = create_func;
    model.odefun([2 3],0)

    save -binary handle_saved.dat model
    clear model

    load handle_saved.dat
    model.odefun([2 3],0)

Running main.m then gives me this result:

>> main

ans =

  -1.28000
   0.64000

ans =

  scalar structure containing the fields:

    odefun = @gas_phase_ODE

Hartmut <hardy>
Mon 21 Nov 2016 05:38:39 AM UTC, comment #6: 

I think the problem is still present.  Unlike Harmut, I did not create a file gas_phase_ODE.m, which creates a primary function of that name.  When I load the structure back in and query it I get

 model
model =

  scalar structure containing the fields:

    odefun = @gas_phase_ODE

Octave knows that it is a function handle to gas_phase_ODE, but it doesn't know where to fnd that function since there is no m-file of that name.  It seems that in this case it really should store something like

odefun = @create_func>gas_phase_ODE

That is the syntax that dbstop uses for subfunctions.

dbstop create_func>gas_phase_ODE
ans =  10

Rik <rik5>
Project Administrator
Mon 21 Nov 2016 03:44:55 AM UTC, comment #5: 

The bug summary specifically says "function handles that point to subfunctions", so I think that's what it's about. If this symptom only arises because of how "clear all" works, then maybe it can be marked as a duplicate.

But what about exiting Octave (or Matlab) and loading a file that contains a handle to a subfunction? Is that not expected to work? If so, then that has nothing to do with whether "clear all" was called, right?

Mike Miller <mtmiller>
Project Administrator
Sun 20 Nov 2016 07:28:09 PM UTC, comment #4: 

Maybe I'm missing the point here, but when I call the main script from comment #0, (just skipping the clc command for clarity here), I always get the following result with Octave 4.2.0:

>> main
ans =

  -1.28000
   0.64000

ans =

  -1.28000
   0.64000

>> main
ans =

  -1.28000
   0.64000

ans =

  -1.28000
   0.64000

>> model.odefun([2 3],0)
ans =

  -1.28000
   0.64000

>>

I have created two separate m-files in the current directory, called create_func.m and gas_phase_ODE.m, one for each function defintion. Maybe that's what I did different?

@Rik: Or did you define those two functions as subfunctions in your main.m? In this case you migh only see Octave's "clear all bug", bug #35881. (Currently "clear all" in Octave also clears subfunction definitions, Matlab doesn't.)

So if I think this isssue is either solved as fixed, or might just be a duplicate of bug #35881.

Hartmut <hardy>
Sun 20 Nov 2016 03:39:22 PM UTC, comment #3: 

When I run main.m, the second time the output is

model.odefun([2 3], 0)
ans =

  scalar structure containing the fields:

    odefun = @gas_phase_ODE

So Octave is saving the function handle name, but it is not connecting the function handle to the actual function.

Rik <rik5>
Project Administrator
Sat 19 Nov 2016 10:16:21 PM UTC, comment #2: 

I think this is now FIXED in Octave 4.2.0.

When running the demo script from comment #0 (including the two function definitions in separate files) than I get twice the same result.

Hartmut <hardy>
Mon 06 Jan 2014 06:03:49 AM UTC, comment #1: 

Bug is still present with release 3.8.0.

Rik <rik5>
Project Administrator
Tue 19 Jun 2012 07:20:23 PM UTC, original submission:  

I found a strange behavior using function handles in Octave.

Here is what I'm trying to do:

1) Create a function handle in a structure like:

    model.odefun = @plant_ODE

2) Save the handle

    save stored_model.mat model

3) when I try to call the function:

    load stored_model.mat;
    model.odefun(0,[2 4]);

octave does not recognize "model.odefun" as an handle anymore.

Actually the problem is a little bit more complex. Attached is a small example. It works in Matlab but it doesnt in Octave.

clear all
close all
clc

model = create_func;
model.odefun([2 3],0)

save -binary handle_saved.dat model
clear all

load handle_saved.dat
model.odefun([2 3],0)

function [model] = create_func

model.odefun = @gas_phase_ODE;

end


function dxdt = gas_phase_ODE(x,t)
  k_ = 0.16;
  v = [-2 1];
  r = k_*x(1)^2;
  dxdt = v'*r;
end

Giulio Mancuso <giuliosssup>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #26064:  main.m added by giuliosssup (161B - text/x-objcsrc)
file #26065:  create_func.m added by giuliosssup (178B - text/x-objcsrc)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by hardy (Posted a comment)
  • -email is unavailable- added by rik5 (Updated the item)
  • -email is unavailable- added by giuliosssup (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-05-14 mtmiller Carbon-CopyRemoved 80942 => -
    2015-07-09 mtmiller Dependencies- => bugs #45503 is dependent
    2015-06-04 mtmiller Release3.6.1 => dev
        Operating SystemGNU/Linux => Any
    2014-01-06 rik5 StatusNone => Confirmed
    2013-10-24 rik5 Item GroupBuild Failure => Matlab Compatibility
    2012-06-19 giuliosssup Attached File- => Added main.m, #26064
        Attached File- => Added create_func.m, #26065

    Back to the top


    Powered by Savane 3.5