mapper functions for 3.1

[David Bateman]

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                                David.Bateman at motorola.com
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch18.bz2
Type: application/x-bzip2
Size: 12211 bytes
Desc: not available
Url : https://www.cae.wisc.edu/pipermail/octave-maintainers/attachments/20080211/6b1f1af2/attachment.bin