Re: mapper functions vs. cell arrays

[John W. Eaton]

On  6-Sep-2006, David Bateman wrote:

| John W. Eaton wrote:
| 
| > Sorry for the delay.  Here are some comments.
| >
| >   * I think it would be (slightly) better to use
| >
| >       feval (fcn_ptr, args, nargout);
| >
| >     instead of
| >
| >       fcn_ptr->do_multi_index_op (nargout, args);
| >   
| Ok, but doesn't that add some overhead, relative to the
| do_multi_index_op call? Note the multi_index_op call was pre-existing in
| cellfin.cc

I think the overheadis very small.  It's not a major issue, it's just
that I think I would rather not spread do_multi_index_op calls very far.

| >   * Instead of setting the value of buffer_error_message, I think you
| >     should increment/decrement it and any changes to its value should
| >     be protected inside an unwind_protect block.as in
| >     src/pt-except.cc.
| >   
| I tried that. The problem is that buffer_error_message  must be
| decremented and then incremented in the same manner as pt-expect.cc as
| the try/catch blocks in assert.m will force the error messages to be
| printed otherwise if the reverse is done (I tried). So
| buffer_error_message then becomes a counter that only prints if the
| value is zero.
| 
| For this to make the most sense I'd propose renaming
| buffer_error_messages to no_buffer_error_messages, and reverse the
| increment/decrement in pt-except.cc, and then do the same in cellfun.cc
| 
| I had the unwind_protect code, but then thought it wasn't needed. Now
| that I think about an OCTAVE_QUIT in the user function, would make the
| unwind_protect necessary.

OK, if you will get the rest of the function working and at least
leave the code that sets and restores buffer_error_message variable, I
will take a look at adding the unwind_protect blocks and fixing it so
that incrementing/decrementing it works.  I don't think I understand
exactly what the issues are.  Can you provide an example that would
not work properly if the value is incremented/decremented instead of
being set?

| >   * Instead of exposing Vlast_error_message and Vlast_error_id, I
| >     think I would prefer to use the lasterr function.  I don't see a
| >     problem in calling it with feval.
| >   
| This implies a significant overhead. Can I propose a compromise. We
| might add the functions
| 
| std::string last_error_message (void) { return Vlast_error_message; }
| std::string last_error_id (void) { return Vlast_error_id; }
| 
| This will at least avoid the overhead of the feval.

I don't think there is much overhead to calling a built-in function,
and anyway this code is only used when there are errors, right?
Also, the only uses of Vlast_error_message and Vlast_error_id are in
statements like this:

  msg.assign ("identifier", Vlast_error_id);
  msg.assign ("message", Vlast_error_message);

Since we know that lasterr is a built-in function, I would be willing
to add a declaration for it to the error.h header file.  Then we could
use

  octave_value_list tmp = Flasterr (octave_value_list (), 2);

  msg.assign ("identifier", tmp(1));
  msg.assign ("message", tmp(0));

| I was trying to handle functions passed as strings rather than inline or
| function handles. The problem is with a call like cellfun("func", a), or
| the same with the ErrorHandler, there is no way of knowing how many
| input or output arguments there are. So for the case of strings I assume
| there is a single input and output argument. For multiple input/output
| arguments its much better to use function handles or inline functions. I
| suppose I should document this limitation.

Is it necesary to handle functions passed as strings?  Can we just
eliminte this case?

Thanks,

jwe