Le choix de l'école a été de former les étudiants dans leurs deux premières années d'info sur FreePascal. Dans un post plus haut ce choix a été expliqué.
Je milite à titre personnel (mais je ne fais pas partie de l'équipe d'info) pour qu'on passe, comme à l'INSA Toulouse, à Ada. Le problème c'est que ça demande beaucoup de temps (entre autres pour refaire tous les supports de cours et former les collègues qui ne connaissent pas ce langage). Je le redis au passage: ils apprennent également Python et C au cours de leur projet math et de leur projet info. Ceux qui iront dans le département info toucheront à tout.
FreePascal permet de répondre malgré tout aux besoins (et même plus) qu'ont les étudiants (grands débutants en première année). Le projet que j'ai donné est destiné à des élèves en fin de premier cycle dans le cadre d'une introduction à l'analyse numérique et à la sensibilisation au problème épineux de la représentation des nombres en machine source de nombreuses erreurs de conception dans des algorithmes de calculs (phénomène de cancellation, d'absorption, gestion de l'erreur relative et de l'erreur absolue etc).
Le projet n'a pas été pensé et préparé en Ada. Il a été pensé de façon théorique puis implémenté initialement en Pascal chez moi. Mon implémentation tournait parfaitement mais je n'étais pas allé faire des tests unitaires aussi poussés qu'eux tout persuadé que mon algo était bon (et il l'était !). Fallait quand même imaginer qu'un décalage de 64 entre deux exposants de deux flottants qu'on veut additionner allait provoquer cette erreur sournoise et non documentée par FreePascal.
Ensuite j'ai voulu faire la même chose proprement en Ada chez moi pour le fun.
Et là, je reçois un mail d'un binôme qui a le bon algo, exactement la bonne démarche, la bonne implémentation a priori, qui me dit "on a une incohérence dans des tests unitaires". Après leur propre investigation (pendant une semaine) et un ou deux échanges avec eux on isole le problème et on voit que shr a un comportement (non documenté par la doc de fpc) complètement incohérent sur le plan arithmétique. Puis je me suis aperçu avec un ami (l'auteur du journal) que de nombreux langages soit disant de haut niveau souffraient de cette incohérence qui consiste à reproduire "bêtement" ce que fait le shr des X86 pour des raisons d'optimisation à bas niveau.
Une fois le bug identifié, un simple "if" a permis de régler le problème et tout revenait dans l'ordre.
Voilà l'histoire :)
En tout cas, j'ai trouvé ça super intéressant de suivre les remarques de chacun, ça montre un aperçu de la façon d'aborder l'arithmétique des entiers dans plein de langages et c'est chouette !
[^] # Re: Du haut niveau pour gérer correctement du bas niveau
Posté par snowball (site web personnel) . En réponse au journal Un décalage de 64 bits, ça vous inspire comment ?. Évalué à 2.
Le choix de l'école a été de former les étudiants dans leurs deux premières années d'info sur FreePascal. Dans un post plus haut ce choix a été expliqué.
Je milite à titre personnel (mais je ne fais pas partie de l'équipe d'info) pour qu'on passe, comme à l'INSA Toulouse, à Ada. Le problème c'est que ça demande beaucoup de temps (entre autres pour refaire tous les supports de cours et former les collègues qui ne connaissent pas ce langage). Je le redis au passage: ils apprennent également Python et C au cours de leur projet math et de leur projet info. Ceux qui iront dans le département info toucheront à tout.
FreePascal permet de répondre malgré tout aux besoins (et même plus) qu'ont les étudiants (grands débutants en première année). Le projet que j'ai donné est destiné à des élèves en fin de premier cycle dans le cadre d'une introduction à l'analyse numérique et à la sensibilisation au problème épineux de la représentation des nombres en machine source de nombreuses erreurs de conception dans des algorithmes de calculs (phénomène de cancellation, d'absorption, gestion de l'erreur relative et de l'erreur absolue etc).
Le projet n'a pas été pensé et préparé en Ada. Il a été pensé de façon théorique puis implémenté initialement en Pascal chez moi. Mon implémentation tournait parfaitement mais je n'étais pas allé faire des tests unitaires aussi poussés qu'eux tout persuadé que mon algo était bon (et il l'était !). Fallait quand même imaginer qu'un décalage de 64 entre deux exposants de deux flottants qu'on veut additionner allait provoquer cette erreur sournoise et non documentée par FreePascal.
Ensuite j'ai voulu faire la même chose proprement en Ada chez moi pour le fun.
Et là, je reçois un mail d'un binôme qui a le bon algo, exactement la bonne démarche, la bonne implémentation a priori, qui me dit "on a une incohérence dans des tests unitaires". Après leur propre investigation (pendant une semaine) et un ou deux échanges avec eux on isole le problème et on voit que shr a un comportement (non documenté par la doc de fpc) complètement incohérent sur le plan arithmétique. Puis je me suis aperçu avec un ami (l'auteur du journal) que de nombreux langages soit disant de haut niveau souffraient de cette incohérence qui consiste à reproduire "bêtement" ce que fait le shr des X86 pour des raisons d'optimisation à bas niveau.
Une fois le bug identifié, un simple "if" a permis de régler le problème et tout revenait dans l'ordre.
Voilà l'histoire :)
En tout cas, j'ai trouvé ça super intéressant de suivre les remarques de chacun, ça montre un aperçu de la façon d'aborder l'arithmétique des entiers dans plein de langages et c'est chouette !