[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: |
Mon, 11 Feb 2008 14:26:13 +0100 |
User-agent: |
Thunderbird 2.0.0.6 (X11/20070914) |
David Bateman wrote:
> Ok, first hitch. As an example std::sin can accept both double and
> Complex arguments. Therefore in you example
>
>
>> DEFUN (sin, args, , "...")
>> {
>> octave_value retval;
>> if (args.length () == 1)
>> retval = args(0).map (std::sin);
>> else
>> print_usage ();
>>
>> return retval;
>> }
>>
>>
>
> how is the map method supposed to know which version of the sin function
> we are referring to? The current implemented gets around this by storing
> a version of both and then picking the appropriate version when the
> apply method is called?
>
> D.
>
>
Ok, here is a first cut of what this might look like, and it appears to
work more or less. There are a number of issues still to address, these
being
* How to really address correctly things like "sin('string')" that are
incorrectly handled at the moment
* How to treat the integer types
* Addition of test code
* Check that the return types are correct for all functions.
* Add a Changelog
However, I wanted to show what I'd done up to now. I think to address
the first two issues will require that the methods
octave_value map (int (*fcn) (int), int flag = 0) const
octave_value map (double (*rfcn) (double), Complex (*cfcn) (const
Complex&)) const
will need to become a method like
octave_value map (int (*sfcn) (int), double (*rfcn) (double), Complex
(*cfcn) (const Complex&), uint64_t (*ifcn) (const uint64_t&), int flag =
0) const
that is perhaps a little messy and something similar to handle the abs
would be
octave_value map (int (*sfcn) (int), double (*rfcn) (double), double
(*cfcn) (const Complex&), uint64_t (*ifcn) (const uint64_t&), int flag =
0) const
and for things like isna would be
octave_value map (bool (*sfcn) (int), bool (*rfcn) (double), bool
(*cfcn) (const Complex&), bool (*ifcn) (const uint64_t&), int flag = 0)
const
Would such a method of dispatching to the correct mapper function be
acceptable? It means that the octave_value map methods are much more
unwieldy that you originally proposed.. In any case that is the
direction I'm headed with this change.
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
patch18.bz2
Description: BZip2 compressed data
- 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 <=
- 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, 2008/02/14
- 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