mapper functions for 3.1
David Bateman
David.Bateman at motorola.com
Mon Feb 11 09:51:33 CST 2008
Ok, to check the return types of the mapper functions under matlab
R2007b and Octave 3.0 I created the attached function, which created the
tables attached to this mail, where
D = "double"
C = "complex"
L = "logical"
S = "sparse"
CS = "complex sparse"
LS = "logical sparse"
STR = "char"
The Octave 3.0 version of cast.m needs to include the "logical" type to
get the script to run
There are a few interesting things to notice about this.
* The logical type is not promoted to a double type always. Check the
"abs" function where it is and the "acos" function where it isn't. Do we
want to duplicate this strange behavior? I'd suggest not doing so.
* Ditto for the string types. Why should "conj" and "ceil" work for
strings, but other functions not? Maybe we should keep this behavior..
* There are some mappers which are defined for the 8, 16 and 32-bit
types but not for the 64-bit types. These being abs/sign. I see no
reason to fail for these mapper functions as we can have
static int64_t xsign (const uint64_t& x)
{
uint64_t ret = static_cast<uint64_t>(0);
if (x > 0)
ret = static_cast<uint64_t>(1)
return ret;
}
static int64_t xsign (const int64_t& x)
{
int64_t ret = static_cast<uint64_t>(0);
if (x > 0)
ret = static_cast<uint64_t>(1)
else if (x < 0)
ret = static_cast<uint64_t>(-1)
return ret;
}
static uint64_t xabs (const uint64_t& x)
{
return x;
}
static int64_t xabs (const int64_t& x)
{
int64_t ret = x;
if (x < 0)
ret == - ret;
return ret;
}
So I'd prefer not to special case sign and abs for the 64 bit types.
* Why should "floor" fail for logical types when it suceeds for strings?
I'd suggest not failing at all.
* mappers with all "FAIL" are those that octave has that matlab doesn't
* The "finite" function has really weird behavior in matlab. What should
we do there?
* I'd suggest that function like isalpha should convert to a string type
and therefore be implemented as
DEFUN (isalpha, args, ,
"-*- texinfo -*-\n\
@deftypefn {Mapping Function} {} isalpha (@var{s})\n\
@deftypefnx {Mapping Function} {} isletter (@var{s})\n\
Return true for characters that are letters (@code{isupper (@var{s})}\n\
or @code{islower (@var{s})} is true).\n\
@end deftypefn")
{
octave_value retval;
if (args.length () == 1)
{
charNDArray m = args(0).char_array_value ();
if (!error_state)
{
octave_idx_type len = m.length ();
const char *m = m.fortran_vec();
boolNDArray result (m.dims ());
bool *p = result.fortran_vec ();
for (octave_idx_type i = 0; i < len; i++)
{
OCTAVE_QUIT;
p[i] = bool (xisalpha (m[i]));
if (error_state)
break;
}
if (!error_state)
retval = result;
}
}
else
print_usage ();
return retval;
}
explictly rather than being mapper functions at all.
Given the output of matlab I have serious doubt that mathworks made a
design decision about the return types of the mapper functions and just
developed them ad-hoc? That being the case do we want to copy them? If
we don't copy them, want should be the output types? I started trying to
develop a proposed list of return types for the mapper functions. Are
they any comments, or proposals to change certain return types? One the
list of proposed return types are decided upon, getting this finished
from where I am should be relatively easy.
regards
David
--
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 --------------
An embedded and charset-unspecified text was scrubbed...
Name: mapper.octave3.0
Url: https://www.cae.wisc.edu/pipermail/octave-maintainers/attachments/20080211/5753b866/attachment-0004.ksh
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mapper.proposed
Url: https://www.cae.wisc.edu/pipermail/octave-maintainers/attachments/20080211/5753b866/attachment-0005.ksh
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mapper.r2007b
Url: https://www.cae.wisc.edu/pipermail/octave-maintainers/attachments/20080211/5753b866/attachment-0006.ksh
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: testmapper.m
Url: https://www.cae.wisc.edu/pipermail/octave-maintainers/attachments/20080211/5753b866/attachment-0007.ksh
More information about the Octave-maintainers
mailing list