Negative number

Discussion in 'Java' started by snehapshinde, Jan 21, 2009.

  1. snehapshinde

    snehapshinde Guest

    Hello,
    Following is a java snippet,

    System.out.println(Integer.toBinaryString(5));
    System.out.println(Integer.toBinaryString(~5));
    System.out.println(~5);

    The output is:
    101
    11111111111111111111111111111010
    -6

    First is the binary of 5.
    Second is binary inversion of 5.
    Third line displays the decimal form of ~5
    How to know that inversion of 5 is decimal -6 and not decimal
    4294967290(I have calculated this value using calc).
    Plz help.Thanks.
     
    snehapshinde, Jan 21, 2009
    #1
    1. Advertisements

  2. Java treats all integral types as signed.
     
    Joshua Cranmer, Jan 21, 2009
    #2
    1. Advertisements

  3. snehapshinde

    snehapshinde Guest

    OK, it means that while deciding that the number is positive or not we
    should consider the number of bits used for that data type.
    Thanks,Patricia.
     
    snehapshinde, Jan 21, 2009
    #3
  4. snehapshinde

    snehapshinde Guest

    I have just started with basics.
    anyway, thanks for the suggession.
     
    snehapshinde, Jan 21, 2009
    #4
  5. snehapshinde

    Mark Space Guest

    Except for "char" ... because consistency would be bad, and mixing
    signed and unsigned types never causes confusion.
     
    Mark Space, Jan 21, 2009
    #5
  6. And including byte, even though bytes are (like chars) almost never
    used in arithmetic and (as with chars) sign-extending them is almost
    never desirable.
     
    Mike Schilling, Jan 21, 2009
    #6
  7. snehapshinde

    blue indigo Guest

    As others have noted, Java's "int" type is signed and 2s-complement.
    As a result, every integer n will be changed by ~ to -n-1 (that is,
    negated and one subtracted).

    Put the bit pattern for ~5 into the low 32 bits of a Java "long", though,
    with zeros for the high 32 bits, and you would indeed get 4294967290. Same
    if you bit-inverted a C "unsigned int" on a platform with ints 32 bits
    wide (printf("%d",(unsigned int)~5);) or an "unsigned long" on a platform
    with longs 32 bits wide.

    Most of the time, Java programmers don't need to worry overly much about
    the exact bit representation of integers. Even when using them in I/O,
    since the default representation for all Java implementations is the same
    regardless of host architecture.

    The major exceptions are:
    * Using large values. You may need long or even BigInteger, depending.
    * Doing binary-format I/O with non-Java tools reading files, writing
    files, or networking with your Java one, including reading common
    binary file formats like .gif. Mostly there are existing library
    routines (ex. JAI/ImageIO classes in the case of .gif) for common
    file formats.
    * Doing work with bytes. Java's "byte" type is, unfortunately, signed.
    * Doing arithmetic with chars. Java's "char" type is UNsigned.
    * Implementing compare() and compareTo(). Naive subtraction could result
    in an unwanted wraparound eventually. Best is to return -1, 0, or 1 as
    appropriate.
    Poor: return this.intField - that.intField;
    Good: if (this.intField < that.intField) return -1;
    if (this.intField > that.intField) return 1;
    return 0;
    The "poor" version has problems if the intField values get widely enough
    separated. The difference might be bigger than 2147483647 in magnitude,
    and then the sign of the returned value would be exactly opposite what
    is desired! The "good" version, meanwhile, makes it easy to add more
    subordinate sort criteria by inserting other stuff before "return 0".
    Ex. if (this.intField < that.intField) return -1;
    if (this.intField > that.intField) return 1;
    if (this.intField2 < that.intField2) return -1;
    if (this.intField2 > that.intField2) return 1;
    return 0;
    sorts on intField and, for objects with equal intFields, sorts on
    intField2. Real world example could be sorting on last name, but
    for equal last names earlier first names come first instead of all
    comparing equal for position and therefore being jumbled up.
     
    blue indigo, Jan 21, 2009
    #7
  8. snehapshinde

    Roedy Green Guest

    any string of bits can be interpreted as BOTH a signed or unsigned
    quantity.

    see http://mindprod.com/jgloss/binary.html
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com

    "Here is a point of no return after which warming becomes unstoppable
    and we are probably going to sail right through it.
    It is the point at which anthropogenic (human-caused) warming triggers
    huge releases of carbon dioxide from warming oceans, or similar releases
    of both carbon dioxide and methane from melting permafrost, or both.
    Most climate scientists think that point lies not far beyond 2°C (4°F) C hotter."
    ~ Gwynne Dyer
     
    Roedy Green, Jan 27, 2009
    #8
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.