Demontre moi avec des arguments crédible que l'écriture d'un programme informatique n'est pas un probléme mathématique (OK, c'est aussi un pbs de frics).
Tres simplement : traitement d'un flux de donnees, ou de facon generale tout domaine ou on a pas la maitrise des flux entrants. On peut demontrer que le traitement d'un jeu de donnees prendra un certain temps machine a condition de connaitre suffisament bien le contenu de ce jeu.
Ce qui est beaucoup plus dur c'est d'etre capable de traiter des donnees exterieures dont on se doute qu'elle risquent d'etre incompletes a un moment ou a un autre tout en gardant une coherence de la base interne. La les maths ne peuvent pas vraiment assurer un resultat (meme si l'utilisation d'outils stochastiques permet de debrouisailler pas mal).
Trois examples pour se faire une idee :
1)Traitement de flux boursiers : On recoit des quotes boursieres par satellite en temps reel. Il faut ecrire un programme capable de transformer ces informations ephemeres en un historique complet. En cas de "flambee" boursiere les informations que l'on recoit passent en mode "burst" a savoir une quote qui remonte a jusqu'a il y a 10 minutes puis la liste des variations au coup par coup jusqu'a maintenant. Bien sur si il y a perte d'une information sur les variations d'une action, les variations suivantes sont perdues aussi. Question : Est ce que je peux etre sur que ma base sera "propre" demain en sachant que je peux m'aider d'un fournisseur d'historique externe pour verifier le contenu de ma base ?
Reponse : non, rien ne dit que j'aurais fini le boulot a temps. En utilisant les stochastiques je peux etre raisonablement sur. La seule "bonne" facon de verifier c'est de tester en rejouant par exemple une des journees boursiere les plus chargees.
2)Maintenance serveur : On a un serveur qui doit effectuer un certains nombre de tache la nuit. Ces taches sont pour certainnes paralelisables pour d'autres mutuellement exclusives. Ce sont les taches suivantes
a) - Consolidation base de donnees
b) - Verification et eventuellement recreation des index base
c) - Backup des disques
d) - Mise a jour automatique des versions des applis si besoin
e) - Update des scripts de traitement si besoin
f) - mise a jour des droits utilsateurs si besoin
g) - verification de la synchro applis avec un autre serveur en load balancing, et mise a jour si besoin.
Je sais (parceque j'ai une enorme base et de vieux serveurs) que je ne pourrais pas faire toutes les operations dans la nuit. Il faut pourtant que les serveurs soient "libres" le lendemain.
De plus avant de consolider la base de donnees(a) il faut faire un backup (c)
De meme (b) necessite (a)
(c) n'a pas de prerequis mais prend du temps
(d) necessite (c) et implique (g) et enventuellement (e)
(e) peut necessiter (f) et/ou (d)
(f) implique (a) (ne pas garder en base des utilisateurs qui n'existent plus)
(g) peut necessiter (f)
En sachant que je n'ai pas le droit de faire deux backups du serveur le meme soir (ou alors exceptionellement avec une personne sur site pour changer les bandes) est ce que je peux etre sur que chacune des operations sera effectuee au moins deux fois par semaine ?
Pour les memes raisons que plus haut : non. Une fois de plus le test est la seule methode valide.
3)compression de flux videos. En theorie en compression video on peut atteindre des taux de 1400/1 en pratique on est proche de 500/1. Intel avec son codec Indeo, juste en essayant des equations d'ondes a la file a reussit sur le codec 5 a passer de 1/200 (5.02) a 1/350 (5.11). Je ne pense pas que la raison en soit que les matheux de chez Intel ne savent pas calculer, a mon avis c'est juste encore un de ces cas ou a besoin de faire des tests pour savoir si ca marche.
Kha
(qui va faire un post one liner pour se changer les idees)
[^] # Re: Droit d'auteur et travailleurs
Posté par Jerome Herman . En réponse à la dépêche Droit d'auteur et travailleurs. Évalué à 5.
Tres simplement : traitement d'un flux de donnees, ou de facon generale tout domaine ou on a pas la maitrise des flux entrants. On peut demontrer que le traitement d'un jeu de donnees prendra un certain temps machine a condition de connaitre suffisament bien le contenu de ce jeu.
Ce qui est beaucoup plus dur c'est d'etre capable de traiter des donnees exterieures dont on se doute qu'elle risquent d'etre incompletes a un moment ou a un autre tout en gardant une coherence de la base interne. La les maths ne peuvent pas vraiment assurer un resultat (meme si l'utilisation d'outils stochastiques permet de debrouisailler pas mal).
Trois examples pour se faire une idee :
1)Traitement de flux boursiers : On recoit des quotes boursieres par satellite en temps reel. Il faut ecrire un programme capable de transformer ces informations ephemeres en un historique complet. En cas de "flambee" boursiere les informations que l'on recoit passent en mode "burst" a savoir une quote qui remonte a jusqu'a il y a 10 minutes puis la liste des variations au coup par coup jusqu'a maintenant. Bien sur si il y a perte d'une information sur les variations d'une action, les variations suivantes sont perdues aussi. Question : Est ce que je peux etre sur que ma base sera "propre" demain en sachant que je peux m'aider d'un fournisseur d'historique externe pour verifier le contenu de ma base ?
Reponse : non, rien ne dit que j'aurais fini le boulot a temps. En utilisant les stochastiques je peux etre raisonablement sur. La seule "bonne" facon de verifier c'est de tester en rejouant par exemple une des journees boursiere les plus chargees.
2)Maintenance serveur : On a un serveur qui doit effectuer un certains nombre de tache la nuit. Ces taches sont pour certainnes paralelisables pour d'autres mutuellement exclusives. Ce sont les taches suivantes
a) - Consolidation base de donnees
b) - Verification et eventuellement recreation des index base
c) - Backup des disques
d) - Mise a jour automatique des versions des applis si besoin
e) - Update des scripts de traitement si besoin
f) - mise a jour des droits utilsateurs si besoin
g) - verification de la synchro applis avec un autre serveur en load balancing, et mise a jour si besoin.
Je sais (parceque j'ai une enorme base et de vieux serveurs) que je ne pourrais pas faire toutes les operations dans la nuit. Il faut pourtant que les serveurs soient "libres" le lendemain.
De plus avant de consolider la base de donnees(a) il faut faire un backup (c)
De meme (b) necessite (a)
(c) n'a pas de prerequis mais prend du temps
(d) necessite (c) et implique (g) et enventuellement (e)
(e) peut necessiter (f) et/ou (d)
(f) implique (a) (ne pas garder en base des utilisateurs qui n'existent plus)
(g) peut necessiter (f)
En sachant que je n'ai pas le droit de faire deux backups du serveur le meme soir (ou alors exceptionellement avec une personne sur site pour changer les bandes) est ce que je peux etre sur que chacune des operations sera effectuee au moins deux fois par semaine ?
Pour les memes raisons que plus haut : non. Une fois de plus le test est la seule methode valide.
3)compression de flux videos. En theorie en compression video on peut atteindre des taux de 1400/1 en pratique on est proche de 500/1. Intel avec son codec Indeo, juste en essayant des equations d'ondes a la file a reussit sur le codec 5 a passer de 1/200 (5.02) a 1/350 (5.11). Je ne pense pas que la raison en soit que les matheux de chez Intel ne savent pas calculer, a mon avis c'est juste encore un de ces cas ou a besoin de faire des tests pour savoir si ca marche.
Kha
(qui va faire un post one liner pour se changer les idees)