Re: mapper functions vs. cell arrays

[David Bateman]

John W. Eaton wrote:
> On  3-Sep-2006, David Bateman wrote:
>
> | David Bateman wrote:
> | 
> | > Ok, then what about something like the attached patch. The only thing I
> | > don't like about this is the use of feval. This shouldn't be needed as
> | > we can assume that all elements are 1x1. However, we need to treat
> | > arbitrary array return types and so its not evident how exact to replace 
> it.
> | > 
> | > Note I also had to export the Vlast_error_message and Vlast_error_id
> | > from error.cc, to allow the erorr handler to be implemented correctly.
> | > It appears to be matlab compatible with the tests I added.
> | 
> | Ok, I think I prefer the attached version instead that removes the
> | feval. Unfortunately I have to do everything with subsasgn on the
> | octave_value to allow arbitrary types to be treated. I can't even be
> | sure that the function will return the same type for the same arguments.
> | God this is a horrible choice on the part of mathworks to allow
> | "UniformOutput" to be true !!!
> | 
> | This version of the patch also removes the special case for the
> | UniformOutput outside the inner loop and so the UniformOutput false case
> | should be as faster as it always was.
>
> 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
>
>   * 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.
>   * 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.
>   * Is this
>
> | !                     std::string fname = "function y = ";
> | !                     fname.append (fcn_name);
> | !                     fname.append ("(x) y = ");
> | !                     ErrorHandler = extract_function (args(i), "cellfun", 
> | !                                                      err_name, fname,
> | !                                                      "; endfunction");
>
>     really the right thing here?  Is
>
>       function y = FCN (x) y = BODY; endfunction
>
>     the right form always?  If not, then maybe we should do something
>     else here to extract the function from the argument.  Or, do we
>     even need to handle the case of the error handler being a
>     character string?  Can we just require that it is a function
>     handle?
>   
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.

I'll propose something after work tonight

D.

-- 
David Bateman                                address@hidden
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary