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: 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

Attachment: patch18.bz2
Description: BZip2 compressed data


reply via email to

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