[ncl-talk] dim_gbits issue

[Kevin Vermeesch]

Thank you for pointing that out. I didn't catch that distinction.
Kevin


On 3/2/2015 10:28 AM, Dennis Shea wrote:
> http://www.ncl.ucar.edu/Applications/HDF.shtml
>
> provides an application example. As noted, this is a sequence of bits not bytes.
>
> ;******************************************************************
> ; hdf4eos_5.ncl
> ;
> ; Concepts illustrated:
> ;   - Plotting EOS-DIS data
> ;   - Reading HDF4 data
> ;   - Using dim_gbits to extract bits of information from a variable
> [SNIP]
> ;******************************************************************
> ;    Bit fields within each byte are numbered from the left:
> ;    7, 6, 5, 4, 3, 2, 1, 0.
> ;    The left-most bit (bit 7) is the most significant bit.
> ;    The right-most bit (bit 0) is the least significant bit.
> ;
> ;    bit field    Description                        Key
> ;    ---------    -----------                        ---
> ;    2, 1         Unobstructed FOV Quality Flag    00 (0) = Cloudy
> ;                                                  01 (1) = Uncertain
> ;                                                  10 (2) = Probably  Clear
> ;                                                  11 (3) = Clear
> ;******************************************************************
>
> ===
> FYI: There is another function that "Unpacks one-bit chunks from the input array."
>
> http://www.ncl.ucar.edu/Document/Functions/Built-in/getbitsone.shtml
>
> Good luck
>
> On Mon, Mar 2, 2015 at 7:45 AM, Rick Brownrigg <brownrig at ucar.edu 
> <mailto:brownrig at ucar.edu>> wrote:
>
>     Hi Kevin,
>
>     I get the same result. However, your case is not exactly like the
>     examples page, which depicts a sequence of bits, whereas you are
>     feeding a sequence of bytes into the function.  If you look at the
>     series of bits within those bytes:
>
>     0000 0000 | 0000 0001 | 0000 0000 ...
>     ^                ^                ^
>     x[0]            x[1]           x[2]          ...
>
>     and then perform the dim_gbits decomposition on that, you do
>     indeed get (/ 0, 0, 2, 0 /)
>
>     Hope that helps...
>     Rick
>
>
>     On Mon, Mar 2, 2015 at 6:00 AM, Kevin Vermeesch
>     <kevin.c.vermeesch at nasa.gov <mailto:kevin.c.vermeesch at nasa.gov>>
>     wrote:
>
>         Hi,
>         I'm trying to use the built-in function dim_gbits
>         (https://www.ncl.ucar.edu/Document/Functions/Built-in/dim_gbits.shtml)
>         and am not getting the expected result while trying the
>         example in the link above. Looking at the worked example in
>         the Description Section, I used the following commands:
>
>         x = tobyte((/0,1,0,1,0,1,1,1,1,1,1,0,0,1,0,0,1,1,0,1,0,0/))
>         print(dim_gbits(x,5,2,3,4))
>
>         I get: (/0,0,2,0/)
>         when I was expecting to get: (/3,2,1,0/) as the example indicates.
>
>         I am using version 6.1.0 (Cygwin) and 6.2.1 (32-bit CentOS).
>         Is this a bug or am I not using/understanding the function
>         correctly?
>         thanks,
>         Kevin
>
>         _______________________________________________
>         ncl-talk mailing list
>         List instructions, subscriber options, unsubscribe:
>         http://mailman.ucar.edu/mailman/listinfo/ncl-talk
>
>
>
>     _______________________________________________
>     ncl-talk mailing list
>     List instructions, subscriber options, unsubscribe:
>     http://mailman.ucar.edu/mailman/listinfo/ncl-talk
>
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/ncl-talk/attachments/20150302/b47c572a/attachment.html