> Bref, je suis persuadé que certains ingénieurs sont prêts à regarder ce que font les chercheurs et que certains chercheurs sont prêts à aider les ingénieurs. Le principal problème, c'est qu'il n'y a pas de vraie culture de transfert et donc, c'est difficile.
Il ne faut pas oublier que la plupart des ingénieurs sont formés par des chercheurs ! Ce que vous dîtes est vrai pour les décideurs qui sont sorti des écoles il y a bien longtemps.
Sans compter que presque tous les chercheurs ne font pas que du théorique, et que bon nombre de publications (peut-être trop même) sont des applications de la recherche à des problèmes concrets mais "mal" résolus. En réalité, la communication ne passe pas mal entre la recherche et l'ingénierie, mais ça prend du temps et de l'énergie, et que les décideurs sont un peu dépassés et considèrent que ça marchait très bien comme ça. La plupart ne vont pas prendre le risque de faire utiliser une technologie que personne ne maîtrise encore sans en avoir déjà vu quelques démonstrations concluantes.
L'ennui avec les tableaux c'est que qu'ils par essence moins "fonctionnels" que les listes. Je m'explique, ils sont plus onéreux à créer que celles-ci car en plus de devoir les créer de la bonne taille (ce que l'on ne connaît pas toujours à l'avance), il faut les remplir après les avoir créé. Malheureusement, pour calculer les coefficients, notre ami a recréé un tableau, puis la parcouru une première fois pour le remplir et enfin, l'a parcouru un seconde fois pour faire sa somme (avec des 0, ce qui n'est jamais bon signe).
Si l'on veut s'éviter la peine de recoder une fonction Array.fold_left jouant sur deux tableaux (de toutes les façon, la fonction Array.fold_left est programmée en impératif), alors on peut simplement utiliser une référence qui facilite bien la tâche et qui montre bien que le caml et à la fois souple et évolué, car il sait profiter des bons aspects de plusieurs méthodes de programmation. Merci l'INRIA !
Je propose donc :
let produit mata matb =
....let coeff li col =
........let k = ref (-1) in
........(Array.fold_left (fun tot m -> incr k; tot + m * matb.(!k).(col)) 0 mata.(li)) in
....Array.init (length mata) ((fun f g x -> f (g x)) (Array.init (Array.length matb.(0))) coeff);;
[^] # Re: Dommage...
Posté par charled . En réponse à la dépêche OCaml 3.10.0 est sorti. Évalué à 2.
Il ne faut pas oublier que la plupart des ingénieurs sont formés par des chercheurs ! Ce que vous dîtes est vrai pour les décideurs qui sont sorti des écoles il y a bien longtemps.
Sans compter que presque tous les chercheurs ne font pas que du théorique, et que bon nombre de publications (peut-être trop même) sont des applications de la recherche à des problèmes concrets mais "mal" résolus. En réalité, la communication ne passe pas mal entre la recherche et l'ingénierie, mais ça prend du temps et de l'énergie, et que les décideurs sont un peu dépassés et considèrent que ça marchait très bien comme ça. La plupart ne vont pas prendre le risque de faire utiliser une technologie que personne ne maîtrise encore sans en avoir déjà vu quelques démonstrations concluantes.
[^] # Re: Dommage...
Posté par charled . En réponse à la dépêche OCaml 3.10.0 est sorti. Évalué à 1.
Si l'on veut s'éviter la peine de recoder une fonction Array.fold_left jouant sur deux tableaux (de toutes les façon, la fonction Array.fold_left est programmée en impératif), alors on peut simplement utiliser une référence qui facilite bien la tâche et qui montre bien que le caml et à la fois souple et évolué, car il sait profiter des bons aspects de plusieurs méthodes de programmation. Merci l'INRIA !
Je propose donc :
let produit mata matb =
....let coeff li col =
........let k = ref (-1) in
........(Array.fold_left (fun tot m -> incr k; tot + m * matb.(!k).(col)) 0 mata.(li)) in
....Array.init (length mata) ((fun f g x -> f (g x)) (Array.init (Array.length matb.(0))) coeff);;