octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mapper functions for 3.1


From: David Bateman
Subject: Re: mapper functions for 3.1
Date: Thu, 14 Feb 2008 11:47:00 +0100
User-agent: Thunderbird 2.0.0.6 (X11/20070914)

John W. Eaton wrote:
> On 13-Feb-2008, David Bateman wrote:
>
> | David Bateman wrote:
> | > I believe that lgamma and gamma are the only mapper functions that can
> | > in fact set error_state and that these two functions are only valid for
> | > real arguments, and so one solution and the one I'm working on is to
> | > just not treat gamma and lgamma as mappers but like any other builtin
> | > function
> | 
> | OK, this isn't a solution as the asinh, etc functions and others also
> | use the F77_XFCN macro. The only other solution I see at this point is
> | to move the declaration of error_state.cc from error.cc and into
> | liboctave.. Do you see any other solutions?
>
> Short of rewriting everything to use C++ exceptions?
>
> How about something like the following patch?  With this, I think you
> should be able to do
>
>   if (liboctave_check_error_state ())
>     {
>       // handle error ...
>     }
>
> I'm not sure this is a great solution, but I think it should work.
> Should we add "revamp error handling" to the list for 3.2?
>
>   
In fact it seems to me that it wouldn't be hard to add a c++ exception
in this case, or in fact in the general liboctave case. For the mapper
functions only the F77_XFCN can cause an error, and if we add an
exception in this case, then with the corresponding catch in
pt-stmt.cc(tree_statement_list::eval) this would be fairly trivial. In
fact we could modify the lo-error.cc (set_liboctave_error_handler)
function so that it wrapped the function that was passed in another
function that also threw an exception. Is it really that simple? Am I
missing something?

In any case the proposed change will be likely to slow the mapper
function down as the check on error_state now needs to call an
additional function, whereas the exception idea will speed if up as we
will not have to check the error_state for each element in the loop.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]