[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: mapper functions vs. cell arrays
From: |
David Bateman |
Subject: |
Re: mapper functions vs. cell arrays |
Date: |
Wed, 06 Sep 2006 11:09:10 +0200 |
User-agent: |
Thunderbird 1.5.0.5 (X11/20060817) |
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
- Re: mapper functions vs. cell arrays, David Bateman, 2006/09/01
- Re: mapper functions vs. cell arrays, David Bateman, 2006/09/01
- Re: mapper functions vs. cell arrays, John W. Eaton, 2006/09/01
- Re: mapper functions vs. cell arrays, David Bateman, 2006/09/01
- Re: mapper functions vs. cell arrays, David Bateman, 2006/09/03
- Re: mapper functions vs. cell arrays, John W. Eaton, 2006/09/05
- Re: mapper functions vs. cell arrays,
David Bateman <=
- Re: mapper functions vs. cell arrays, John W. Eaton, 2006/09/06
- Re: mapper functions vs. cell arrays, David Bateman, 2006/09/06
- Re: mapper functions vs. cell arrays, David Bateman, 2006/09/07
- Re: mapper functions vs. cell arrays, David Bateman, 2006/09/12
- Re: mapper functions vs. cell arrays, John W. Eaton, 2006/09/12
- Re: mapper functions vs. cell arrays, David Bateman, 2006/09/12