Skip to content

fix: restore the non-breaking spaces the numba.md sync stripped #9

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
mmcky merged 1 commit into from
Jul 16, 2026
+14 −14
Merged

fix: restore the non-breaking spaces the numba.md sync stripped #9

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 14 additions & 14 deletions lectures/numba.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -470,7 +470,7 @@ Comparez la vitesse avec et sans Numba lorsque la taille de l'échantillon est g
:class: dropdown
```

Voici une solution :
Voici une solution :

```{code-cell} ipython3
@jit
Expand All @@ -487,7 +487,7 @@ def calculate_pi(u_draws, v_draws):
return area_estimate * 4 # division par le rayon**2
```

Voyons maintenant à quelle vitesse cela s'exécute :
Voyons maintenant à quelle vitesse cela s'exécute :

```{code-cell} ipython3
with qe.Timer():
Expand All @@ -504,7 +504,7 @@ considérablement plus de temps sur notre machine.

Nous obtenons donc un gain de vitesse important en ajoutant quatre caractères.

La solution ci-dessus adopte l'une des deux approches naturelles : elle *tire tous les
La solution ci-dessus adopte l'une des deux approches naturelles : elle *tire tous les
points aléatoires d'abord*, les stocke dans `u_draws` et `v_draws`, puis laisse la
fonction jittée les parcourir en boucle.

Expand Down Expand Up @@ -539,7 +539,7 @@ aléatoires sont tirés une seule fois dans le bloc de configuration partagé ci
la seconde approche paie pour ses tirages à l'intérieur de la fonction chronométrée.

Pour comparer les deux approches de manière équitable, nous chronométrons la première approche de bout en bout,
en incluant le coût de la génération des tableaux :
en incluant le coût de la génération des tableaux :

```{code-cell} ipython3
with qe.Timer():
Expand Down Expand Up @@ -657,7 +657,7 @@ print(np.mean(x == 0)) # Fraction du temps où x est dans l'état 0

C'est (approximativement) la bonne sortie.

Chronométrons-le maintenant :
Chronométrons-le maintenant :

```{code-cell} ipython3
with qe.Timer():
Expand All @@ -684,7 +684,7 @@ with qe.Timer():
compute_series_numba(n, U)
```

C'est une belle amélioration de vitesse pour une ligne de code !
C'est une belle amélioration de vitesse pour une ligne de code !

```{solution-end}
```
Expand Down Expand Up @@ -716,7 +716,7 @@ Pour la taille de la simulation Monte-Carlo, utilisez quelque chose de substanti
:class: dropdown
```

Voici une solution :
Voici une solution :

```{code-cell} ipython3
@jit(parallel=True)
Expand All @@ -733,7 +733,7 @@ def calculate_pi_parallel(u_draws, v_draws):
return area_estimate * 4 # division par le rayon**2
```

Voyons maintenant à quelle vitesse cela s'exécute :
Voyons maintenant à quelle vitesse cela s'exécute :

```{code-cell} ipython3
with qe.Timer():
Expand Down Expand Up @@ -775,16 +775,16 @@ Dans {ref}`numba_ex3`, nous avons tiré tous les points aléatoires *avant* la b

Il est tentant de plutôt tirer chaque point *à l'intérieur* de la boucle `prange`, en passant un générateur `rng` en argument et en appelant `rng.uniform()` dans le corps de la boucle.

Essayez-le : le code devrait s'exécuter et renvoyer un nombre proche de $\pi$, pourtant il y a un bug subtil dans cette approche.
Essayez-le : le code devrait s'exécuter et renvoyer un nombre proche de $\pi$, pourtant il y a un bug subtil dans cette approche.

Enquêtez comme suit :
Enquêtez comme suit :

1. Appelez votre fonction quelques fois avec la *même* graine et vérifiez si le résultat est reproductible.
2. Répétez l'estimation de nombreuses fois sur une gamme de tailles d'échantillon et comparez sa dispersion à celle d'une version parallèle correcte.

Expliquez ensuite ce qui ne va pas et donnez une manière correcte de tirer à l'intérieur d'une boucle parallèle.

Astuce : essayez d'utiliser une fonction aléatoire ancienne telle que `np.random.uniform()` au lieu d'un `Generator` et voyez ce qui se passe.
Astuce : essayez d'utiliser une fonction aléatoire ancienne telle que `np.random.uniform()` au lieu d'un `Generator` et voyez ce qui se passe.
```

```{solution-start} numba_ex_race
Expand Down Expand Up @@ -829,7 +829,7 @@ imprévisible.

Deux symptômes révèlent le problème.

*Symptôme 1 : le résultat n'est plus reproductible.*
*Symptôme 1 : le résultat n'est plus reproductible.*

Un générateur correct renvoie la même réponse chaque fois qu'on lui donne la même graine.

Expand All @@ -842,7 +842,7 @@ for seed in (1, 1, 1):

Chaque appel utilise la même graine, pourtant les réponses diffèrent.

*Symptôme 2 : l'estimateur est bien plus bruité qu'il ne devrait l'être.*
*Symptôme 2 : l'estimateur est bien plus bruité qu'il ne devrait l'être.*

Les tirages dupliqués et corrélés portent moins d'information que $n$ tirages indépendants, de sorte que la taille d'échantillon *effective* est bien plus petite que $n$.

Expand Down Expand Up @@ -889,7 +889,7 @@ plt.show()

Les deux bandes sont centrées sur $\pi$, mais la bande associée à la course aux données est bien plus large que l'autre et se rétrécit très lentement à mesure que la taille de l'échantillon augmente.

L'autre option sûre est celle de {ref}`numba_ex3` : tirer les points avant la boucle afin que la boucle parallèle ne fasse que lire depuis la mémoire.
L'autre option sûre est celle de {ref}`numba_ex3` : tirer les points avant la boucle afin que la boucle parallèle ne fasse que lire depuis la mémoire.

```{solution-end}
```
Expand Down