Re: mapper functions for 3.1

[David Bateman]

John W. Eaton wrote:
> On  5-Feb-2008, David Bateman wrote:
>
> | In the "goals for 3.1" thread there were the points
> | 
> | 8. Make mapper functions work like other built-in functions?
> | 
> | 9. Mapper functions like real, imag, and mod should preserve type (are
> | there others?)
> | 
> | I can see easily how to address point 9 in ov-mapper.cc itself, though
> | in might involve some if/else blocks. However, I'm not sure I see what
> | is meant by point 8. John what was your thoughts for point 8? Does this
> | mean that you wanted to get rid of the ov-mapper class and duplicate the
> | mapper loops in the functions themselves?
>
> Yes, that was my original idea.  It seemed like it would be good to
> have an individual DEFUN for each one, same as all other functions.  I
> was thinking that dispatching for the mapper functions would not work
> properly otherwise, but that may be wrong.
>
> | The nice thing about the
> | current code is that it the loops aren't duplicated for each function.
> | How can we make the mapper functions more like other functions without
> | massive code duplication?
>
> I think we could still avoid code duplication by using function
> pointers and some templates.
>
>   DEFUN (sin, args, , "...")
>   {
>     octave_value retval;
>     if (args.length () == 1)
>       retval = args(0).map (std::sin);
>     else
>       print_usage ();
>
>     return retval;
>   }
>
> Then we would need some map functions:
>
>   octave_value octave_value::map (double (*fcn) (double)) const
>   {
>     return rep->map (fcn);
>   }
>
>   octave_value octave_value::map (bool (*fcn) (double)) const
>   {
>     return rep->map (fcn);
>   }
>
>   ...
>
> and also to implement these in the numeric/character classes, then
> ultimately in the Array<T> and Sparse<T> classes.  I think some use of
> templates or macros there could avoid duplicating the loops (at least
> in the source code itself).
>   
I don't think they can really be implemented in the Array<T> and
Sparse<T> classes as if the mapper function returns an error how do we
quit the loop? See the comment in ov-mapper.cc

// In most cases, we could use the map member function from the NDArray
// classes, but as currently implemented, they don't allow us to
// detect errors and abort properly.  So use these macros to do the
// looping here instead.

Its probably therefore better to implement the map function in
ov-base-mat.cc and ov-base-sparse.cc instead. However, I see a few
issues, and I see several possible ways to address them. If the map
function is implemented in ov-base-mat.cc then how should the integer
arrays be treated? Can we even apply the mapper functions to integer
arrays? Does matlab allow this and if so with what result (for example
sqrt(-ones(2,2,'int8')) returns what exactly)? It therefore might be
better to treat the mapper functions in ov-re-mat.cc and ov-cx-mat.cc.
Does ov-bool-mat.cc then promote the matrix to a real matrix before
calling the map method or should it deal with the mapper functions itself?

How do we handle the can_ret_cmplx_for_real flag? What I suggest is
something like

octave_value
octave_matrix::map (double (*fcn) (double), double lower = -octave_Inf,
double upper = octave_Inf)
{
      if (any_value_outside_limit (matrix, lower, upper))
        return octave_complex_matrix (fcn);
      else
        ....
}

and then the limits can be passed explicitly. Something similar needs to
be done to handle ch_map_flag as well. Humm, ok I think this is quite
possible to do.. I'll take this one on for the 3.1 list..

D.