$c main.tex | sed '/Output written/d'| sed '/Rerun to get \/Page/d'| sed '/Warning: Citation/d'| sed '/Warning: Empty bib/d'| sed '/has changed/d'| sed '/Warning: There were/d'| sed '/biblatex Warning/d'
$c main.tex | sed '/Output written/d'| sed '/Warning: There were/d'| sed '/biblatex Warning/d'
@ -16,25 +16,25 @@ Cependant, avec cette méthode, si l'on oublie un cas particulier dans nos tests
\inputminted[bgcolor=darkBackground]
{ocaml}
{src/max_in_list.ml}
{max_in_list.ml}
Supposons que l'on ait écrit les tests suivants pour notre algorithme:
\inputminted[bgcolor=darkBackground]
{ocaml}
{src/test_max_in_list.ml}
{test_max_in_list.ml}
Notre algorithme ne va échouer sur aucun des tests et l'on pourrait alors croire qu'il est correct. Ce n'est bien évidemment pas le cas. Si notre liste n'est composée que de nombres entiers négatifs, l'algorithme renverra $0$ dans tous les cas\textellipsis\ Le test suivant aurait pu détecter cela:
\inputminted[bgcolor=darkBackground]
{ocaml}
{src/test_max_in_list_bis.ml}
{test_max_in_list_bis.ml}
Une version correcte de l'algorithme serait:
\inputminted[bgcolor=darkBackground]
{ocaml}
{src/max_in_list_correct.ml}
{max_in_list_correct.ml}
On voit bien alors une des faiblesses des tests: on ne peut jamais être certain d'avoir pensé à tous les cas et on ne peut généralement pas tous les tester lorsqu'il y en a une infinité ou qu'ils sont trop nombreux.
@ -52,7 +52,7 @@ Cependant, si on y regarde de plus près, on s'aperçoit que le programme suivan
\inputminted[bgcolor=darkBackground]
{ocaml}
{src/max_in_list_plus_one.ml}
{max_in_list_plus_one.ml}
Ici, le problème n'est donc plus celui des cas particuliers, mais celui de la spécification : ici, on a oublié de préciser que la valeur renvoyée par notre fonction doit être présente dans la liste. Cela pourrait s'exprimer ainsi:
La ligne $27$ indique un \emph{Seq Scan} sur la relation \emph{reserves}, si l'on enlève l'indication de l'algorithme utilisé, cela revient à simplement parler de la relation \emph{reserves}. Sur les lignes $22$ à $29$, on utilise $\omega$ sur cette relation avec des paramètres particuliers. La ligne $23$ nous indique qu'il n'y a aucune partition, ce qui se note \emph{Fine}. La ligne $24$ nous indique qu'on va sélectionner les attributs \emph{sid}, \emph{bid} et \emph{dday} de la relation, et qu'on les renomme respectivement en \emph{r.sid}, \emph{r.bid} et \emph{r.dday}. La ligne $25$ indique quant à elle que l'on va filtrer le résultat en ne gardant que les lignes respectant la condition $bid =103$. L'écriture mathématique de cette expression, en faisant abstraction des variables notées $x_i$, serait la suivante:
@ -19,13 +19,13 @@ Interviennent alors les \emph{plans d'exécution}. En effet, \bsc{sql} étant un
\inputminted[bgcolor=darkBackground]
{sql}
{src/movie_01.sql}
{movie_01.sql}
On pourrait obtenir un plan comme celui-ci:
\inputminted[bgcolor=darkBackground]
{xml}
{src/movie_01.xml}
{movie_01.xml}
Cependant, il n'existe pas de standard portant sur les plans d'exécution, les \bsc{sgbd} les présentent de façon différente, utilisent leurs propres algorithmes, utilisent un nom différent pour un même algorithme, ne donnent pas la même quantité d'informations etc.
zapashcanon
4 years ago
