8+8 = 137 ??

Discussion in 'Java' started by Rajesh.Rapaka, Aug 10, 2005.

  1. Hi,
    I am trying to decode the RLE 16 - bit compression using java.
    So here I believe all the data is encoded in 16-bit. so even the face
    number should be encoded in 16-bit. using java I am reading it as 2
    eight bits A and B. Now I need to add these 2 bits in such a way that I
    get the correct value in an 8-bit space.

    any ideas?

    Thank u in advance,
    kind regards,
    Rajesh Rapaka.
    Rajesh.Rapaka, Aug 10, 2005
    #1
    1. Advertising

  2. Rajesh.Rapaka

    Roedy Green Guest

    On 10 Aug 2005 10:02:30 -0700, "Rajesh.Rapaka"
    <> wrote or quoted :

    >number should be encoded in 16-bit. using java I am reading it as 2
    >eight bits A and B. Now I need to add these 2 bits in such a way that I
    >get the correct value in an 8-bit space.


    I presume you mean adding modulo 256.


    sum = ( a + b ) & 0xff;

    --
    Bush crime family lost/embezzled $3 trillion from Pentagon.
    Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
    http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

    Canadian Mind Products, Roedy Green.
    See http://mindprod.com/iraq.html photos of Bush's war crimes
    Roedy Green, Aug 10, 2005
    #2
    1. Advertising

  3. Rajesh.Rapaka

    Paul Tomblin Guest

    In a previous article, lid said:
    >On 10 Aug 2005 10:02:30 -0700, "Rajesh.Rapaka"
    ><> wrote or quoted :
    >>number should be encoded in 16-bit. using java I am reading it as 2
    >>eight bits A and B. Now I need to add these 2 bits in such a way that I
    >>get the correct value in an 8-bit space.

    >
    >I presume you mean adding modulo 256.
    >
    >
    >sum = ( a + b ) & 0xff;


    I think he's trying to put two 8 bit values together to make one 16 bit
    value, in which case he'd want

    sum = a << 8 | b;



    --
    Paul Tomblin <> http://xcski.com/blogs/pt/
    "You can get anything you want on Alice's NNTP server."
    Paul Tomblin, Aug 10, 2005
    #3
  4. Paul Tomblin wrote:
    >
    > I think he's trying to put two 8 bit values together to make one 16 bit
    > value, in which case he'd want
    >
    > sum = a << 8 | b;


    Presumably not if he's stored them in bytes.

    Tom Hawtin
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
    Thomas Hawtin, Aug 10, 2005
    #4
  5. Paul Tomblin wrote:
    >
    > In a previous article, lid said:
    > >On 10 Aug 2005 10:02:30 -0700, "Rajesh.Rapaka"
    > ><> wrote or quoted :
    > >>number should be encoded in 16-bit. using java I am reading it as 2
    > >>eight bits A and B. Now I need to add these 2 bits in such a way that I
    > >>get the correct value in an 8-bit space.

    > >
    > >I presume you mean adding modulo 256.
    > >
    > >
    > >sum = ( a + b ) & 0xff;

    >
    > I think he's trying to put two 8 bit values together to make one 16 bit
    > value, in which case he'd want
    >
    > sum = a << 8 | b;


    At least that makes sense with his subject, assuming he got his hex to decimal
    conversion wrong. (8 << 8 | 8) is 0x88 or 136 decimal ... not 137 decimal.

    --
    Lee Fesperman, FFE Software, Inc. (http://www.firstsql.com)
    ==============================================================
    * The Ultimate DBMS is here!
    * FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)
    Lee Fesperman, Aug 11, 2005
    #5
  6. Rajesh.Rapaka

    Tim Tyler Guest

    Lee Fesperman <> wrote or quoted:
    > Paul Tomblin wrote:
    > > In a previous article, lid said:
    > > >On 10 Aug 2005 10:02:30 -0700, "Rajesh.Rapaka"
    > > ><> wrote or quoted :


    > > >>number should be encoded in 16-bit. using java I am reading it as 2
    > > >>eight bits A and B. Now I need to add these 2 bits in such a way that I
    > > >>get the correct value in an 8-bit space.
    > > >
    > > >I presume you mean adding modulo 256.
    > > >
    > > >sum = ( a + b ) & 0xff;

    > >
    > > I think he's trying to put two 8 bit values together to make one 16 bit
    > > value, in which case he'd want
    > >
    > > sum = a << 8 | b;

    >
    > At least that makes sense with his subject, assuming he got his hex to
    > decimal conversion wrong. (8 << 8 | 8) is 0x88 or 136 decimal ... not
    > 137 decimal.


    I make it 0x808.
    --
    __________
    |im |yler http://timtyler.org/ Remove lock to reply.
    Tim Tyler, Aug 11, 2005
    #6
  7. yes,
    I am reading them as bytes! and I am this is how i felt is the correct
    way of doing it....
    byte a, b;
    readbytes ab();
    short value = b << 8 | a;

    in this particular compression technique, we get only values between
    -127 and 127.

    ie a and b can contain values between -127 and 127. But when i see the
    value that i get i get most of them above -127.

    I dont think conversion from hexadecimal to decimal is important.

    any ideas?

    thanks in advance,
    regards,
    Rajesh Rapaka.
    Rajesh.Rapaka, Aug 11, 2005
    #7
  8. Hi Rejesh,

    Rajesh.Rapaka wrote:
    > byte a, b;
    > readbytes ab();
    > short value = b << 8 | a;


    OK, think about, what "b<<8" will do with a *byte*!

    Hth,
    Ingo
    Ingo R. Homann, Aug 11, 2005
    #8
  9. Ingo R. Homann wrote:
    >
    > Rajesh.Rapaka wrote:
    >
    >> byte a, b;
    >> readbytes ab();
    >> short value = b << 8 | a;


    Doesn't even compile.

    > OK, think about, what "b<<8" will do with a *byte*!


    Much the same as it'd do to an int.

    Think about the representation of negative ints across their 32-bits.

    Tom Hawtin
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
    Thomas Hawtin, Aug 11, 2005
    #9
  10. Hi,

    Thomas Hawtin wrote:
    > Ingo R. Homann wrote:
    >>
    >> Rajesh.Rapaka wrote:
    >>
    >>> byte a, b;
    >>> readbytes ab();
    >>> short value = b << 8 | a;

    >
    > Doesn't even compile.
    >
    >> OK, think about, what "b<<8" will do with a *byte*!

    >
    > Much the same as it'd do to an int.


    Testing... compiling... testing again...

    Intersting!

    What's the reason, that java does not compile the first one, when it
    really compiles the second one without complaining? Why does java treat
    byte and int so differently in this case?:

    byte b = 42;
    b = b << 8; // not OK

    int i = 42;
    i = i << 128; // perfectly OK


    > Think about the representation of negative ints across their 32-bits.


    ???

    Ciao,
    Ingo
    Ingo R. Homann, Aug 12, 2005
    #10
  11. "Ingo R. Homann" <> writes:

    > What's the reason, that java does not compile the first one, when it
    > really compiles the second one without complaining? Why does java
    > treat byte and int so differently in this case?:


    It doesn't: The shift operator, like all other operators, promote its
    arguments - in this case to int, since neither operand is a double or
    long. You then need to mask and/or downcast as needed.
    Tor Iver Wilhelmsen, Aug 12, 2005
    #11
  12. Tim Tyler wrote:
    >
    > Lee Fesperman <> wrote or quoted:
    > > Paul Tomblin wrote:
    > > > In a previous article, lid said:
    > > > >On 10 Aug 2005 10:02:30 -0700, "Rajesh.Rapaka"
    > > > ><> wrote or quoted :

    >
    > > > >>number should be encoded in 16-bit. using java I am reading it as 2
    > > > >>eight bits A and B. Now I need to add these 2 bits in such a way that I
    > > > >>get the correct value in an 8-bit space.
    > > > >
    > > > >I presume you mean adding modulo 256.
    > > > >
    > > > >sum = ( a + b ) & 0xff;
    > > >
    > > > I think he's trying to put two 8 bit values together to make one 16 bit
    > > > value, in which case he'd want
    > > >
    > > > sum = a << 8 | b;

    > >
    > > At least that makes sense with his subject, assuming he got his hex to
    > > decimal conversion wrong. (8 << 8 | 8) is 0x88 or 136 decimal ... not
    > > 137 decimal.

    >
    > I make it 0x808.


    Quite right. I was thinking of:

    sum = (a << 4) | b;

    ((8 << 4) | 8) produces 0x88.

    Mea Culpa...

    --
    Lee Fesperman, FFE Software, Inc. (http://www.firstsql.com)
    ==============================================================
    * The Ultimate DBMS is here!
    * FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)
    Lee Fesperman, Aug 13, 2005
    #12
  13. Rajesh.Rapaka

    Tim Tyler Guest

    Ingo R. Homann <> wrote or quoted:

    > What's the reason, that java does not compile the first one, when it
    > really compiles the second one without complaining? Why does java treat
    > byte and int so differently in this case?:
    >
    > byte b = 42;
    > b = b << 8; // not OK
    >
    > int i = 42;
    > i = i << 128; // perfectly OK


    In the first case Java is promoting to an integer - perhaps because
    that's what you might normally want to do - and perhaps so they
    don't have to write different bytecode operators for every single
    primitive type.

    In the second case, Java is not promoting to a 256-bit type -
    perhaps because Java doesn't have a 256-bit primitive type - and
    perhaps because that's rarely what you would want to do in the first
    place.

    It doesn't give an overflow error either - Java's primitive integer
    types tend not to do that.

    Instead it suggests that 42 << 128 is 42.

    That is, after all, the answer to everything - isn't it?
    --
    __________
    |im |yler http://timtyler.org/ Remove lock to reply.
    Tim Tyler, Aug 13, 2005
    #13
  14. Hi,

    Tim Tyler wrote:
    > Instead it suggests that 42 << 128 is 42.


    It's getting more and more interesting! Do I understand it correctly,
    that when x is an int

    x<<y

    is really interpreted as

    x<<(y%32)

    ? My test suggest so...

    > That is, after all, the answer to everything - isn't it?


    :)

    Ciao,
    Ingo
    Ingo R. Homann, Aug 15, 2005
    #14
  15. Rajesh.Rapaka

    Chris Uppal Guest

    Ingo R. Homann wrote:

    > x<<y
    >
    > is really interpreted as
    >
    > x<<(y%32)
    >
    > ? My test suggest so...


    That's right; it's part of the language specification. Similarly, the shift
    value for longs is implicitly &-ed with 63.

    IMO, the compiler should issue a warning when the 'y' value is a literal value
    that it "knows" will be truncated.

    -- chris
    Chris Uppal, Aug 15, 2005
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Manish Hatwalne

    Understanding error - Java returned: 137

    Manish Hatwalne, Sep 3, 2004, in forum: Java
    Replies:
    1
    Views:
    7,248
    Thomas Fritsch
    Sep 3, 2004
  2. Ruby Quiz

    [QUIZ] Twisting a Rope (#137)

    Ruby Quiz, Aug 31, 2007, in forum: Ruby
    Replies:
    29
    Views:
    421
    Eugene Kalenkovich
    Sep 7, 2007
  3. Ruby Quiz

    [SUMMARY] Twisting a Rope (#137)

    Ruby Quiz, Sep 6, 2007, in forum: Ruby
    Replies:
    5
    Views:
    369
    Eugene Kalenkovich
    Sep 7, 2007
  4. Braulio Lima

    Getting machine name by port 137

    Braulio Lima, Jan 18, 2011, in forum: Ruby
    Replies:
    0
    Views:
    79
    Braulio Lima
    Jan 18, 2011
Loading...

Share This Page