Re: mapper functions vs. cell arrays

[David Bateman]

John W. Eaton wrote:
> | 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?
>   
The case were it doesn't work is that pt-except.cc decrements
buffer_error_messages, where I felt it made more sense to increment it.
So its not a real problem just one of book keeping. A change of variable
name would make it clearer that this is a counter.

> | >   * 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));
>   
Ok, that works for me..

> | 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?
>   
I suppose we could, but then cellfun behaves slightly differently from
other code that accepts function handles that also accept strings (eg
quad, etc). I'd prefer to keep it and comment it for this reason..

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