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

According to John W. Eaton <

[hidden email]> (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/582http://www.octave.org/mailing-lists/octave-maintainers/2004/627I 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

[hidden email]
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