0:00:00.380,0:00:03.286
Initialement, si je compile [br]et exécute le testeur,

0:00:03.286,0:00:06.203
toutes les méthodes renvoient des zéros.

0:00:06.203,0:00:08.620
Rectifions l'amdahlSpeedup en premier.

0:00:08.620,0:00:10.355
Pour l'instant, il renvoie 0.

0:00:10.355,0:00:13.319
[br]Et si je l'écris juste comme ça?

0:00:13.319,0:00:15.777
Maintenant, si je lance[br]à nouveau le testeur,

0:00:15.777,0:00:18.716
j'obtiens en réalité 2.875

0:00:18.716,0:00:20.843
alors que je m'y attendais à 1.6.

0:00:20.843,0:00:23.335
Je ferais mieux de revenir[br]en arrière et le corriger.

0:00:23.345,0:00:25.565
Maintenant, il fait d'abord les divisions,

0:00:25.565,0:00:28.516
donc 1 sur s et s sur n.

0:00:28.516,0:00:30.799
Ensuite les additions et[br]soustractions au milieu

0:00:30.799,0:00:34.109
et il n'y a pas de sens de la fraction[br]avec laquelle nous avons commencé.

0:00:34.109,0:00:37.363
Toute cette pièce, de s à n

0:00:37.363,0:00:40.618
devrait rester unie dans le dénominateur

0:00:40.628,0:00:44.628
et celle -1 doit rester unie [br]dans son numérateur.

0:00:45.586,0:00:47.468
Essayons ça encore.

0:00:47.468,0:00:50.304
On dirait que amdalhSpeedup fonctionne,

0:00:50.304,0:00:53.483
mais nous devons encore [br]faire le rapport croisé.

0:00:53.483,0:00:56.298
Je vais essayer de refaire[br]de façon un peu naïve.

0:00:56.298,0:00:59.437
J'ai écrit ça comme ça a l'air[br]mais l'ai aplati sur une ligne.

0:00:59.437,0:01:02.974
Donc, si je renvoie cette[br]quantité et que je compile,

0:01:03.404,0:01:05.623
j'obtiens une erreur, type inattendu,

0:01:05.623,0:01:08.629
classe valeur trouvée requise.

0:01:09.149,0:01:12.560
Cette erreur n'a probablement [br]pas beaucoup de sens pour le moment,

0:01:12.560,0:01:14.789
mais c'est un petit indice[br]de ce qui vient.

0:01:14.789,0:01:17.179
Une paire de parenthèses [br]comme celle-ci suivie

0:01:17.179,0:01:20.108
d'une autre quantité [br]a une autre signification

0:01:20.108,0:01:21.931
surtout, si vous mettez un type ici

0:01:21.931,0:01:24.595
au lieu d'une expression comme a - c.

0:01:24.595,0:01:27.715
Ce que je dois faire, c'est indiquer[br]ce que je veux multiplier

0:01:27.715,0:01:29.828
[br]et je vais devoir le faire ici aussi.

0:01:29.828,0:01:32.378
Et maintenant, si j'essaie [br]de relancer le testeur,

0:01:32.378,0:01:35.183
je n'obtiens pas les bonnes [br]réponses pour le rapport croisé.

0:01:35.183,0:01:37.306
Car lorsque nous avons[br]un groupe d'opérateurs

0:01:37.306,0:01:39.206
avec les mêmes précédents,

0:01:39.206,0:01:42.405
Java commencera juste à gauche [br]et se déplacera vers la droite.

0:01:42.405,0:01:46.211
Donc, au lieu de calculer[br]a - c * b - d

0:01:46.211,0:01:50.218
sur, entre parenthèses, (b - c) * (a - d).

0:01:50.218,0:01:54.291
Cela donnera a - c * b - d / b - c

0:01:54.306,0:01:58.125
et toute cette quantité [br]multipliée par a - d.

0:01:58.425,0:02:02.145
Ce que je dois faire ici, [br]c'est grouper le dénominateur.

0:02:02.145,0:02:05.106
Je pourrais aussi regrouper[br]le numérateur, si je le voulais,

0:02:05.106,0:02:07.347
mais cela ne ferait pas [br]beaucoup de différence.

0:02:07.347,0:02:10.930
Si je compile à nouveau[br]et exécute le testeur,

0:02:10.930,0:02:13.711
j'ai maintenant deux méthodes [br]qui fonctionnent bien.

0:02:13.711,0:02:15.306
[br]Maintenant pour la moyenne.

0:02:15.306,0:02:18.983
Je pourrais essayer de renvoyer [br]la somme de tous ces éléments,

0:02:18.983,0:02:20.984
[br]tous divisés par quatre.

0:02:20.984,0:02:22.894
[br]Voyons voir comment cela fonctionne.

0:02:22.894,0:02:26.297
Si je lance le testeur, il semble [br]que cela fonctionne dans un cas,

0:02:26.297,0:02:27.445
[br]mais pas dans l'autre.

0:02:27.445,0:02:29.644
[br]Regardons le deuxième cas.

0:02:29.644,0:02:31.751
Je vais aller lire à [br]l'intérieur du testeur.

0:02:31.751,0:02:33.849
Le cas qui ne fonctionne pas[br]est quand nous essayons

0:02:33.849,0:02:36.687
[br]de prendre la moyenne de 3, 4, 3 et 3.

0:02:37.627,0:02:40.109
Nous devrions, en fait, nous[br]attendre à 3,25,

0:02:40.629,0:02:43.044
mais il semble que [br]nous perdons la décimale.

0:02:43.044,0:02:46.076
Java interprète cela [br]comme une division entière,

0:02:46.076,0:02:50.076
car 4 est un entier, et a, b, c et d [br]sont tous déclarés comme entiers.

0:02:50.396,0:02:52.744
Il y a plusieurs façons [br]de résoudre ce problème.

0:02:52.744,0:02:56.272
Je pourrais écrire 4 comme 4. ou 4.0

0:02:56.272,0:02:58.555
et alors il obtiendrait[br]la bonne réponse ici.

0:02:58.725,0:03:01.882
Ou je pourrais réellement changer [br]tous ces ints en doubles

0:03:01.882,0:03:05.538
et alors je n'aurais pas besoin[br]de spécifier que le 4 était un double.

0:03:05.538,0:03:09.538
Je peux compiler ceci, lancer [br]le testeur et cela fonctionne toujours.

0:03:10.101,0:03:13.559
C'est parce que si une de [br]ces variables est un double,

0:03:13.559,0:03:16.647
cette expression entière entre[br]parenthèses sortira comme un double

0:03:16.647,0:03:20.312
et un double divisé par un entier ne doit[br]pas être fait avec la division entière

0:03:20.312,0:03:22.784
qui requiert une division régulière.

0:03:22.784,0:03:24.890
C'est une chose vraiment [br]facile à confondre.

0:03:24.890,0:03:27.891
Cela nous semble juste, [br]mais l'ordinateur le lira mal

0:03:27.891,0:03:30.066
[br]et le compilateur ne vous avertira pas.

0:03:30.066,0:03:32.723
Lorsque nous lançons cela[br]avec les ints et sans doubles,

0:03:32.723,0:03:35.633
nous avons vu que cela a fini[br]par être une erreur d'exécution.

0:03:35.633,0:03:38.499
Ceci est un bon exemple de pourquoi[br]il est utile de penser

0:03:38.499,0:03:41.069
à ce que vous voulez que[br]votre réponse soit à l'avance.

0:03:41.069,0:03:43.556
Calculez quelques exemples, [br]puis écrivez votre code.

0:03:43.556,0:03:44.746
Au plaisir avec ce quiz.