Re: 3.0.1 release?

[David Bateman]

Michael Goffioul wrote:
> On Tue, Apr 8, 2008 at 4:41 PM, David Bateman
> <address@hidden> wrote:
>   
>>  Then I'm not sure I understand, it is clear that the example
>>
>>
>>   Bmax = bitmax;
>>   A = bitshift(Bmax,-2);
>>   bitxor(cast(A,'uint64'),cast(Bmax,'uint64'))
>>
>>
>>  Is incorrect in the windows version (I used your 3.0 MSVC binary) of
>>  Octave, and that corresponds to the piece of code I sent.. Can you
>>  confirm that this is incorrect under MSVC (that is it doesn't return
>>  6755399441055744). I checked the casts above independently and they are
>>  returning the correct answers, so the issue is in the bitxor function in
>>  src/bitfcns.cc. This calls the code fragment
>>
>>           uint64NDArray x (args(0).array_value ()); \
>>           uint64NDArray y (args(1).array_value ());    \
>>           if (! error_state) \
>>         BITOPX (OP, FNAME, uint64NDArray); \
>>           retval = retval.array_value (); \
>>
>>  in the BITOP macro, and BITOPX call a fragment
>>
>>         for (int i = 0; i < nelx; i++) \
>>           if (is_scalar_op) \
>>         for (int k = 0; k < nely; k++) \
>>           result(i+k) = x(i) OP y(k); \
>>
>>  where "OP" is "^". This then calls the operator ^ from
>>  liboctave/oct-inttypes.h
>>
>>  #define OCTAVE_INT_BITCMP_OP(OP) \
>>   template <class T> \
>>   octave_int<T> \
>>   operator OP (const octave_int<T>& x, const octave_int<T>& y) \
>>   { \
>>     return x.value () OP y.value (); \
>>   }
>>
>>  OCTAVE_INT_BITCMP_OP (^)
>>
>>  where T is of type uint64_t and x.value() returns a value of type
>>  uint64_t. I don't see where this can go wrong and so laid the cause on
>>  the ^ operator for uint64_t types in MSVC. Frankly I'm stumped why this
>>  is wrong under MSVC..
>>     
>
> I'll check further this evening or tomorrow. In the meantime, I did this
> simple check: using the code you sent me, I derived the following:
>
> int main (void)
> {
>         uint64_t a = 0x001FFFFFFFFFFFFFUL^0x0007FFFFFFFFFFFFUL;
>       std::cerr << 0x001FFFFFFFFFFFFFUL << std::endl;
>       std::cerr << 0x0007FFFFFFFFFFFFUL << std::endl;
>         std::cerr << a  << std::endl;
>         return 0;
> }
>
> When executed, it gives:
>
> 9007199254740991
> 2251799813685247
> 6755399441055744
>
> Then I executed the following in octave:
>
> Bmax = bitmax;
> A = bitshift(Bmax,-2);
> cast(Bmax,'uint64'), cast(A,'uint64'),
> bitxor(cast(A,'uint64'),cast(Bmax,'uint64'))
>
> which returned
>
> ans = 9007199254740992
> ans = 2251799813685247
> ans = 11258999068426239
>
> Notice the 1-bit difference in the first entry. If I'm right, they
> should be equivalent,
> right?
>   
Yes this is the issue... It seems the bitmax under windows if not
returning the right value.. bitmax uses

static_cast<double> (0x1FFFFFFFFFFFFFLL)

as its definition and so perhaps its the "LL" at the end that is causing
the issue as it really should be a "UL".. Can you try

#include <iostream>
int main (void)
{
        uint64_t a = 0x001FFFFFFFFFFFFFUL^0x0007FFFFFFFFFFFFUL;
    double b = static_cast<double> (0x1FFFFFFFFFFFFFLL);
    double c = static_cast<double> (0x1FFFFFFFFFFFFFUL);
    std::cerr << 0x001FFFFFFFFFFFFFUL << std::endl;
    std::cerr << 0x0007FFFFFFFFFFFFUL << std::endl;
        std::cerr << a  << std::endl;
        std::cerr << b  << std::endl;
        std::cerr << c  << std::endl;
        std::cerr << b - c  << std::endl;
        return 0;
}

and see whether the last result is something other than zero.. If so I
think we've found the issue.

D.

> Michael.
>
>   


-- 
David Bateman                                address@hidden
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