octave-bug-tracker
[Top][All Lists]
Advanced

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

[Octave-bug-tracker] [bug #54931] bitpack order in big-endian machines


From: Carnë Draug
Subject: [Octave-bug-tracker] [bug #54931] bitpack order in big-endian machines
Date: Thu, 1 Nov 2018 12:00:13 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0

URL:
  <https://savannah.gnu.org/bugs/?54931>

                 Summary: bitpack order in big-endian machines
                 Project: GNU Octave
            Submitted by: carandraug
            Submitted on: Thu 01 Nov 2018 04:00:10 PM UTC
                Category: Octave Function
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Incorrect Result
                  Status: None
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 4.4.1
        Operating System: GNU/Linux

    _______________________________________________________

Details:

The bitpack function packs an array of logical values in an array of another
type. Its documentation says:

> Bits come in increasing order of significance, i.e., 'x(1)' is bit 0, 'x(2)'
is bit 1, etc.

The documentation has an issue since the position of the least significant bit
is not necessarily bit 0, in the case of packing into a 32bit integer, it will
be bit 24.

The actual implementation also does not take the values by order of
significance, so the results differ between big and little endian machines. On
a little endian machine (amd64):


>> x = false (1, 32);
>> x(1) = true;
>> disp (bitpack (x, "uint32"))
1
>> x([1 9]) = true;
>> disp (bitpack (x, "uint32"))
257


While on a big endian machine (mips at
https://db.debian.org/machines.cgi?host=minkus )


>> x = false (1, 32);
>> x(1) = true;
>> disp (bitpack (x, "uint32"))
16777216
>> x([1 9]) = true;
>> disp (bitpack (x, "uint32"))
16842752


For what is worth, both the bitpack and bitunpack are Octave only, so what
Matlab does does not apply here.

Looking at the code for bitpack, I believe the issue comes from the fact that
the bit shifting is done in a char instead of the type that the bits are being
packed into.




    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?54931>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

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