[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
- mapper functions for 3.1, David Bateman, 2008/02/05
- mapper functions for 3.1, John W. Eaton, 2008/02/05
- Re: mapper functions for 3.1, David Bateman, 2008/02/09
- Re: mapper functions for 3.1, David Bateman, 2008/02/09
- Re: mapper functions for 3.1, David Bateman, 2008/02/11
- Re: mapper functions for 3.1, David Bateman, 2008/02/11
- Re: mapper functions for 3.1, John W. Eaton, 2008/02/11
- Re: mapper functions for 3.1, David Bateman, 2008/02/13
- Re: mapper functions for 3.1, David Bateman, 2008/02/13
- Re: mapper functions for 3.1, John W. Eaton, 2008/02/13
- Re: mapper functions for 3.1,
David Bateman <=
- Re: mapper functions for 3.1, John W. Eaton, 2008/02/14
- Using C++ exceptions in liboctave (was: Re: mapper functions for 3.1), John W. Eaton, 2008/02/14
- Using C++ exceptions in liboctave (was: Re: mapper functions for 3.1), John W. Eaton, 2008/02/14
- Re: mapper functions for 3.1, David Bateman, 2008/02/15
- Re: mapper functions for 3.1, John W. Eaton, 2008/02/16
- Re: mapper functions for 3.1, David Bateman, 2008/02/16
- Re: mapper functions for 3.1, John W. Eaton, 2008/02/16
- Re: mapper functions for 3.1, John W. Eaton, 2008/02/16
- Re: mapper functions for 3.1, David Bateman, 2008/02/17
- Re: mapper functions for 3.1, John W. Eaton, 2008/02/18