Re: std in NDArrays

[David Bateman]

I'm moving this discussion to the maintainers list..

According to John W. Eaton <address@hidden> (on 08/26/04):
>   * bitcmp, bitget, and bitset should work for int64 types (currently
>     they won't because they rely on being able to convert to double
>     and/or perform arithmetic on the values.  It would be best to
>     avoid using eval in these functions.  Perhaps they should be
>     implemented in C++?

Addressing this point, the only reason the existing bitcmp, bitget and
bitset functions don't work for uint64 and int64 is lines like

    Amax = eval ([cname, " (log2 (double (intmax (cname))) + 1);"]);

in the code. I originally thought that it would make sense to convert the
log mapper functions for use with the integer types. However it turns out 
that this is quite complex and as they would only return the integer part
of the log and log2(x) is implemented as log(x)/log(2) and the integer
part of log(2) is zero, this doesn't make any sense...

The only other mapper functions that might be of use are "abs" and "sign",
so I really don't think it is worth modifying the octave_mapper class for
this...

However as the value Amax is just the number of bits in the integer 
representation the above line might be written as

    Amax = str2num(substr(cname, 5, length(cname)-4));

and this will then work for uint64. A similar change is needed for the
int64 case. With only this change the existing functions will work with
int64 and uint64 with a small proviso as discussed below.

As for the other "eval" statements, they are all a variant of the form
"eval ([cname, "(1);"]);" and are used to cast an unknown type to the
correct type. I think these are pretty harmless, for readability I can
write

_conv = eval (["@", cname, ";"]);

and hide the other evals behind this function handle. This is certainly
clearer..

Note that for n > 53, bitset and bitget will be broken due to the
incorrect return type of .^, and so this needs to be fixed..

Also note that something like

a = uint8 (int8 (1))

or even

a = uint8 (uint64 (1))

is currently broken as they return an int8 type rather than a uint8 type...
I fixed this bug in passing...

Find attached a patch that addresses all of the above issues and thus
gets bitcmp, bitget and bitset working for both int64 and uint64 types.
Hopefully, this brings a 2.1.58 release that little bit closer..

D.

PS. John, I've seen no reaction from you to my patches in the mails

http://www.octave.org/mailing-lists/bug-octave/2004/582
http://www.octave.org/mailing-lists/octave-maintainers/2004/627

I know these are relatively recent patches, but as you're talking about
a 2.1.58 release just giving you a heads up for some of my other patches
to perhaps include...
 
-- 
David Bateman                                address@hidden
Motorola CRM                                 +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary

patch.bitfcns20040826
Description: Text document

changelog-bitfcns20040826
Description: Text document