class LongDiv{ public static void main(String [] args){ final long x = 24*60*60*1000*1000; final long y = 24*60*60*1000; System.out.println(x/y); } } although the expected answer is 1000, but the javac gives it as 5. Reason?
5 Réponses :
Les expressions C'est ce que vous avez. P> 24 * 60 * 60 * 1000 * 1000 code> est un type
int code> pas un
long code> ce que vous voulez est
24l * 60 * 60 * 1000 * 1000 code> qui est
long code>
final long x = 24L*60*60*1000*1000;
final long y = 24L*60*60*1000;
System.out.println(x/y);
Pour être explicite à ce sujet, vous pouvez toujours faire un 1L * 24 * 60 * 60 * 1000 * 1000 code>.
Dans ce cas, vous pouvez faire (long) 24 * 60 * 60 * 1000 * 1000 code>
Quand la longue promotion de l'INT-> serait-elle arrivée? Pour 24 ou le résultat complet (intifié)?
Casting a priorité sur la multiplication introcs.cs.princeton.edu/java/11preCedence
Le long en ajoutant un Nous pouvons reproduire la valeur erronée pour X code> que vous créez n'est pas la valeur que vous attendiez. C'est dans la gamme entière. Pour créer des longs, utilisez:
x code> Vous avez calculé, dans la gamme INTEGER, était
500654080 code>. Ceci divisé par le
Y code> (=
86400000 code>), entraîne un
5.794607407407407 ... code>. Java tronque la partie décimale qui provoque le 5. P>
l code> après le numéro littéral, vous dites au compilateur de la compiler comme un
long code> au lieu d'un
int code>. La valeur pour
x code> que vous attendiez est
86400000000 code>. Mais est compilé comme un int. P>
x code> (
500654080 code>) en tronquant à un int: p >
// First correct
long x = 24L*60L*60L*1000L*1000L;
/* x = `86400000000`; */
// Now truncate
x &= 0xFFFFFFFFL; // again: don't forget the L suffix
/* x = `500654080` */
Un seul de ces littéraux dans chaque expression doit être un long code>. Voir @ la réponse de Peter.
Je sais, mais je pense que c'est une préférence de style.
@Martijn: Comment puis-je calculer cette valeur 500654080 sans l'ordinateur !! Cette question est apparue dans un examen écrit !!
C'est une jolie question écrite écrite ... Le mieux que je puisse penser serait d'écrire les morceaux de chaque numéro et de les masquer avec 0xFFFFFFFF, car @Peter est allongé ci-dessus.
@Aakash: Si la question était "Pourquoi cette valeur est-elle fausse?", Vous pouvez simplement dire que x code> est truc sur AT en raison du suffixe oublié
l code>.
@ERIC: Programme de recrutement d'eBay Campus !!
24 * 60 * 60 * 1000 * 1000 code> est trop grand pour s'intégrer à un
int code> et débords. p>
Tricky One!
Le problème est que 24, 60 et 1000 sont Java littéral intens em>. Avant que les valeurs ne soient attribuées à X et Y, elles sont tronquées pour s'adapter aux valeurs INT. Essayez p> pour voir exactement ce que je veux dire. La solution rapide est de rendre vos littéraux dans de longues valeurs comme: p>
Battu au poinçon! Pas aussi difficile que je pensais, je suppose :)
casting (forçage) aux longs travaux en cas de valeurs littérales pour le bon opérande; Mais le problème persiste en cas d'attribution d'une variable longue à une autre, comme dans l'exemple ci-dessous:
package utils; public class Utils { public static void main(String ... clps){ Utils.longDivision(); Utils.doubleDivision(); } private static void doubleDivision(){ double x=new Long("54321").doubleValue(); double y=new Long("12345").doubleValue(); double difference=x - y; double percentage=(difference/x)*100.00; System.out.println("\nDouble Division ==> X : "+x+" ; Y : "+y+" ; Difference : "+difference+" ; percentage : "+percentage+"\n"); } private static void longDivision(){ long x=new Long("54321").longValue(); long y=new Long("12345").longValue(); long difference=x - y; long percentage=(difference/x)*100L; System.out.println("\nLong Division ==> X : "+x+" ; Y : "+y+" ; Difference : "+difference+" ; percentage : "+percentage+"\n"); } }