octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

unary mapper system redesigned + a few questions


From: Jaroslav Hajek
Subject: unary mapper system redesigned + a few questions
Date: Thu, 12 Nov 2009 16:19:03 +0100

hi all,

the following (rather large) changeset redesigns the system for unary mapper functions.
http://hg.savannah.gnu.org/hgweb/octave/rev/f80c566bc751

Rationale:
Until now, there existed a single virtual octave_base_value method for each mapper. Now, there is a single map (unary_mapper_t) method that takes an enum parameter identifying the mapper. The new style has some advantages:
1. It becomes far easier to implement a "handle some, convert & forward others" approach.
2. When adding a new mapper, less classes need to be touched. Adding support for scalars and dense arrays mostly suffices; the fallback conversions will handle the rest.
3. Adding a new mapper won't alter the VMT, hence the ABI is not broken.
4. 40 virtual methods are replaced by one, saving 39 VMT entries :) (probably not a real issue though)
5. Less code and less macros.

I think the only disadvantage is that one now needs to write value.map (umap_abs) rather than value.abs (). If anyone thinks that would be a good idea, the old mappers can be put back to octave_value for compatibility. Right now they're gone.

I also altered somewhat the way mapping functions on arrays is handled, but that's even more technical and probably not yet final...

If you compile, you'll notice 37 failures.

Of those, 30 are caused by the fact that isalpha, tolower et al. now don't work for numeric inputs. Matlab apparently only has lower/upper and only mentions characters. Giving an error on, say, toupper (1+1i) makes sense to me, so unless someone disagrees I'll alter the tests instead.

The remaining 7 failures are more subtle, caused by things like:
 octave:1> a = -1i*sqrt(-1/(6.4187*6.4187));
octave:2>  assert (erf(a), erf(real(a)));
error: erf: not defined for complex scalar
error: evaluating argument list element number 1

For some reason, Octave's complex->real autoconversion doesn't take place on a:
octave:2> isreal (a)
ans = 0

I checked the sources and it seems this behaviour is intended - positive imaginary zeros are narrowed, negative zeros aren't.

that gives rise to some surprising results:

octave:3> isreal (i*i)
ans =  1
octave:4> isreal (-i*i)
ans = 0

why by all heavens does Octave do this? Can anyone explain? Apparently it was done on purpose, but I don't understand it. And I'd like to, so that I can argue about it :)

best regards

--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

reply via email to

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