Hvordan nås resultatet?

overflow?

Hvad mener du??

nedrundingsfejl?

Hmm.....en integer er på 32bit

Dvs. max
2147483647 værdier

Det er virkelig en hjælp at få stillet spørgsmål som svar når jeg ikke har den fjernes idé om hvad det er der sker.
Jeg runder jo ikke ned.

hvis du ganger
1000000000
med 10, overstiger størrelsen af variablen de for en int tilladte
2147483647

Overflow in integer operations does not throw any exception in the JVM. The result is merely truncated to fit into the result type. For example, adding shorts 0x7fff and 1 yields 0x8000. This means that the JVM will report that 32,767 + 1 = -32,768, so long as the values being added are shorts and not ints or longs. It is up to the Java programmer to make sure that the appropriate type -- int or long -- is chosen for integer arithmetic in each situation. (If long isn't long enough, the Java programmer should invent a class that implements really long integers and the operations upon them.) Integer division by zero does throw an ArithmeticException, so the programmer should keep in mind that this exception could be thrown and catch it if necessary.

Som der står i ovenstående, får du ikke en fejl når du prøver at presse "for meget" ind i en integer variabel, værdien bliver bare truncated.

Bliver det virkelig 32 bit??!
Okay...
Tak for hjælpen pupputmaster.
(Hvis lige du har udregningen ved hånden vil ja da gerne se den)
Men svar lige så sp kan afsluttes.

Så har jeg et svar som vist forklarer rimelig godt hvad det er der sker:



an overflow results when a calculated value is larger than the number of bytes allowed for its type
a underflow results when a calculated value is smaller than the number of bytes assigned to its type
Java handles overflows by discarding the high-order-bytes that won't fit into the number of bytes allowed by its type (JJ pg 52)
int n = 2000000000;
System.out.println(n*2); // output: -1651507200

An int is 32-bits, the result of n*2 is
4,000,000,000,000,000,000 which
needs 64-bits which in binary is:

    ---------- high-order bytes -------
    00110111 10000010 11011010 11001110

    ------- low order bytes -----------
    10011101 10010000 00000000 00000000

because an 32-bit cannot retain the number,
the 4 high-order bytes are
dropped leaving the four low-order bytes:

    10011101 10010000 00000000 00000000
                                   
which represent 1651507200 and since the right most bit
is a 1 the sign value is negative


overflow or underflow conditions never throw a runtime exception; instead the sign of the result may not be the same as that expected in the mathematical result
You probably won't need to calculate overflows or underflows on the exam but should understand how they work.

Så hvis du vil se udregningerne, skal du skrive 1000000000 med binære tal og gange det med 10 (også i binær format). Så skal du fjerne de 4 high order bytes og skulle gerne ende på 1410065408 (hvilket er den "truncated" værdi)

:-)

Takker for point

Glemte helt: det binære tal du får ud af det skal selvfølgelig konverteres tilbage til decimaltal!

;)

2.147.483.647  ca =  2Giga
Det er det tal der var grænse for hvor stor en harddisk kunne være i det gamle FAT16 filsystem.
Du har mødt den slags grænser igen og igen i computeren.

Men de afhænger af det binære talsystem som man så lige skal kende for at forstå hvorfor, det er besværligt indtil man rigtig kender det. Men det kan sagtens siges i vores gode gamle 10-talssytem.

År 2000 problemet fx er et godt eksempel. en masse messesker havde sagt "2 cifre er vel nok til at vide hvad år det er" og havde derfor lavet programmer hvor årstallet stod som blot 2 cifre
  20-05-50  betyder  '20 maj 1950'
men kunne egentlig ligesågodt betyde '20 maj 2050' eller '20 maj 1850' eller...

fordi det årstal det egentlig er har mistet sine forreste cifre, og det er rent gætteri og menneskeregler hvilke forreste cifre der skal sættes ind foran 50.

dit tal
  1.410.065.408  har på samme måde mistet sine forreste bit der skulle stå
10.000.000.000  så der er blevet klippet
  8.589.934.592  af
prøv selv at udregne  4 * 2.147.483.648  jeg vil vædde på det er 8.589.934.592

mvh JakobA

...det er sa... så kloge folk er her.
Jeg går i træning ;-)

Tak for inputtet Jakoba.

Hvis du gerne vil have den til at gå 'lidt' længere op, så kan du evt forsøge dig med :
  long intTal = 10; // som måske så burde kaldes longTal :-)

en long er en 64-bits værdi - og burde kunne holde dig lidt mere beskæftiget..

/Søren

/// her er outputtet - med "i" i parentes ///

D:\>cr LongTiTest

D:\>javac LongTiTest.java

D:\>java LongTiTest
(0) -  10
(1) -  100
(2) -  1000
(3) -  10000
(4) -  100000
(5) -  1000000
(6) -  10000000
(7) -  100000000
(8) -  1000000000
(9) -  10000000000
(10) -  100000000000
(11) -  1000000000000
(12) -  10000000000000
(13) -  100000000000000
(14) -  1000000000000000
(15) -  10000000000000000
(16) -  100000000000000000
(17) -  1000000000000000000
(18) -  -8446744073709551616
(19) -  7766279631452241920
(20) -  3875820019684212736
(21) -  1864712049423024128
(22) -  200376420520689664
(23) -  2003764205206896640
(24) -  1590897978359414784
(25) -  -2537764290115403776
(26) -  -6930898827444486144
(27) -  4477988020393345024
(28) -  7886392056514347008
(29) -  5076944270305263616
(30) -  -4570789518076018688
(31) -  -8814407033341083648
(32) -  4089650035136921600
(33) -  4003012203950112768
(34) -  3136633892082024448
(35) -  -5527149226598858752
(36) -  68739955140067328
(37) -  687399551400673280
(38) -  6873995514006732800
(39) -  -5047021154770878464

D:\>

Og koden til ovenstående
class LongTiTest{
  public static void main(String args[]) {
      long l = 10;
      int i = 0;
      while(i<40) {
          System.out.println("("+i+") - \t"+l);
          l *= 10;
          i += 1;         
      }
  }
}