Perso je n'ai jamais vu quelqu'un venir se plaindre qu'un prog marche malgré la présence d'un bug purement théorique qui ne s'est jamais manifesté.
Serais-tu trop jeune pour ne pas encore travailler dans ce secteur il y a dix ans ? À cette époque reculée, tout le monde s'activait pour réparer des bogues « purement théorique » qui ne s'étaient (alors) jamais encore manifestés
Ca dépend.. il n'y a pas d'obligations. Tu n'es pas obligé d'acheter la maintenance, mais dans ce cas il ne faut pas venir pleurer que l'outil ne marche plus avec la dernière version de l'OS, et que du coup tu doive acheter une nouvelle licence "plein pot" rien que pour ca. Tout change, même et surtout les OS.
Je ne pleure pas lorsque je fait un pari et que la balance résulte défavorable. Par contre, je n'aime pas lorsqu'on ne me laisse pas d'autre choix que de payer sans avoir voix au chapitre. Et moins encore lorsque je paye pour des prestations qui ne sont pas ensuite tenues.
Est-on autorisé de pleurer quand le fournisseur (auquel tu as contracté la maintenance) n'arrive pas à faire marcher son programme avec le nouvel OS ? Et quand il t'oblige à payer plein pot (normal, puisque lui-même est obligé de souffrir la totalité des frais) une nouvelle version de son programme, parce qu'il n'arrive pas à remplir ses obligations de l'ancienne version sur le nouvel OS ? Voire pire, lorsqu'il finit par faire faillite ou disparaître du panorama, pour ne pas réussir à sortir de ce mauvais pas ?
La maintenance n'est qu'une assurance comme les autres, et ne devrait pas sortir de ce rôle. Quand le prix actualisé de l'assurance dépasse de beaucoup le prix du bien assuré, il y a un problème.
Il est aussi des cas où ce n'est pas une bonne idée. Quand tu envoies une fusée dans l'espace, ou même si tu diffuses un produit grand public à des millions d'exemplaires, il n'est pas encore admis par tout le monde que le code devra peut-être évoluer dans le futur...
Détrompe toi: tout est conçu pour évoluer de nos jours.
Détrompe toi : je suis parfaitement conscient des reprogrammations possibles et mises en ½uvre ici ou là. En particulier pour ce qui concerne l'espace (où j'ai pris à dessein l'exemple d'une fusée, en souvenir d'un bogue fameux pour son importance sur les concepts de génie logiciel, et en prenant soin de mentionner l'exemple très voisin de l'aviation de ligne.) Aussi pour ce qui concerne l'automobile, que j'ai du mal à inclure dans la catégorie de articles grand public, et qui est ÀMHA par bien des points une exception du point de vue de la maintenance (des presses pliaient encore des côtés de R16 à Flins vers 1992 ; et j'ai assisté en 1994 à une intéressante discussion sur l'avenir d'une machine spéciale pour fabriquer des pièces de moteur de 4CV et de R4, parce que Renault voulait savoir où finirait la dite machine, irremplaçable, pour le cas où on ait à refaire une série de pièces détachées... une démarche pro active, que certains font aussi dans le domaine du logiciel, par exemple en prenant soin de garder utilisables les compilateurs utilisés pour générer chaque version livrée.)
Et pour revenir à l'exemple des téléviseurs, la pratique existe depuis des années sur le satellite... et je n'ai jamais réussi à récupérer en téléchargement la mise à jour de mes décos, j'ai toujours eu à recourir à FTP et au port RS-232C ; et pour avoir passé un peu de temps à regarder les signaux transmis, il me semble bien qu'au bout d'un an environ, les fabricants passent à autre chose : en fait le téléchargement ne semble être rien d'autre pour eux qu'un outil leur permettant de peaufiner la mise au point de leur logiciel au-delà de la date de livraison, grâce à un ensemble plus larges de cobayes pour finaliser les tests ; de la même manière que pour Microsoft la RTM n'est qu'un point de la durée de vie d'un produit, le produit stabilisé est plutôt le premier SP, où on trouve très peu de nouveautés et beaucoup de corrections de bogues...
Antoine
Samuel Devulder écrivit :
Perso je n'ai jamais vu quelqu'un venir se plaindre qu'un prog marche
malgré la présence d'un bug purement théorique qui ne s'est jamais
manifesté.
Serais-tu trop jeune pour ne pas encore travailler dans ce secteur il y
a dix ans ?
À cette époque reculée, tout le monde s'activait pour réparer des bogues
« purement théorique » qui ne s'étaient (alors) jamais encore manifestés
Ca dépend.. il n'y a pas d'obligations. Tu n'es pas obligé d'acheter la
maintenance, mais dans ce cas il ne faut pas venir pleurer que l'outil
ne marche plus avec la dernière version de l'OS, et que du coup tu doive
acheter une nouvelle licence "plein pot" rien que pour ca. Tout change,
même et surtout les OS.
Je ne pleure pas lorsque je fait un pari et que la balance résulte
défavorable. Par contre, je n'aime pas lorsqu'on ne me laisse pas
d'autre choix que de payer sans avoir voix au chapitre. Et moins encore
lorsque je paye pour des prestations qui ne sont pas ensuite tenues.
Est-on autorisé de pleurer quand le fournisseur (auquel tu as contracté
la maintenance) n'arrive pas à faire marcher son programme avec le
nouvel OS ?
Et quand il t'oblige à payer plein pot (normal, puisque lui-même est
obligé de souffrir la totalité des frais) une nouvelle version de son
programme, parce qu'il n'arrive pas à remplir ses obligations de
l'ancienne version sur le nouvel OS ? Voire pire, lorsqu'il finit par
faire faillite ou disparaître du panorama, pour ne pas réussir à sortir
de ce mauvais pas ?
La maintenance n'est qu'une assurance comme les autres, et ne devrait
pas sortir de ce rôle. Quand le prix actualisé de l'assurance dépasse de
beaucoup le prix du bien assuré, il y a un problème.
Il est aussi des cas où ce n'est pas une bonne idée. Quand tu envoies
une fusée dans l'espace, ou même si tu diffuses un produit grand public
à des millions d'exemplaires, il n'est pas encore admis par tout le
monde que le code devra peut-être évoluer dans le futur...
Détrompe toi: tout est conçu pour évoluer de nos jours.
Détrompe toi : je suis parfaitement conscient des reprogrammations
possibles et mises en ½uvre ici ou là. En particulier pour ce qui
concerne l'espace (où j'ai pris à dessein l'exemple d'une fusée, en
souvenir d'un bogue fameux pour son importance sur les concepts de génie
logiciel, et en prenant soin de mentionner l'exemple très voisin de
l'aviation de ligne.) Aussi pour ce qui concerne l'automobile, que j'ai
du mal à inclure dans la catégorie de articles grand public, et qui est
ÀMHA par bien des points une exception du point de vue de la maintenance
(des presses pliaient encore des côtés de R16 à Flins vers 1992 ; et
j'ai assisté en 1994 à une intéressante discussion sur l'avenir d'une
machine spéciale pour fabriquer des pièces de moteur de 4CV et de R4,
parce que Renault voulait savoir où finirait la dite machine,
irremplaçable, pour le cas où on ait à refaire une série de pièces
détachées... une démarche pro active, que certains font aussi dans le
domaine du logiciel, par exemple en prenant soin de garder utilisables
les compilateurs utilisés pour générer chaque version livrée.)
Et pour revenir à l'exemple des téléviseurs, la pratique existe depuis
des années sur le satellite... et je n'ai jamais réussi à récupérer en
téléchargement la mise à jour de mes décos, j'ai toujours eu à recourir
à FTP et au port RS-232C ; et pour avoir passé un peu de temps à
regarder les signaux transmis, il me semble bien qu'au bout d'un an
environ, les fabricants passent à autre chose : en fait le
téléchargement ne semble être rien d'autre pour eux qu'un outil leur
permettant de peaufiner la mise au point de leur logiciel au-delà de la
date de livraison, grâce à un ensemble plus larges de cobayes pour
finaliser les tests ; de la même manière que pour Microsoft la RTM n'est
qu'un point de la durée de vie d'un produit, le produit stabilisé est
plutôt le premier SP, où on trouve très peu de nouveautés et beaucoup de
corrections de bogues...
Perso je n'ai jamais vu quelqu'un venir se plaindre qu'un prog marche malgré la présence d'un bug purement théorique qui ne s'est jamais manifesté.
Serais-tu trop jeune pour ne pas encore travailler dans ce secteur il y a dix ans ? À cette époque reculée, tout le monde s'activait pour réparer des bogues « purement théorique » qui ne s'étaient (alors) jamais encore manifestés
Ca dépend.. il n'y a pas d'obligations. Tu n'es pas obligé d'acheter la maintenance, mais dans ce cas il ne faut pas venir pleurer que l'outil ne marche plus avec la dernière version de l'OS, et que du coup tu doive acheter une nouvelle licence "plein pot" rien que pour ca. Tout change, même et surtout les OS.
Je ne pleure pas lorsque je fait un pari et que la balance résulte défavorable. Par contre, je n'aime pas lorsqu'on ne me laisse pas d'autre choix que de payer sans avoir voix au chapitre. Et moins encore lorsque je paye pour des prestations qui ne sont pas ensuite tenues.
Est-on autorisé de pleurer quand le fournisseur (auquel tu as contracté la maintenance) n'arrive pas à faire marcher son programme avec le nouvel OS ? Et quand il t'oblige à payer plein pot (normal, puisque lui-même est obligé de souffrir la totalité des frais) une nouvelle version de son programme, parce qu'il n'arrive pas à remplir ses obligations de l'ancienne version sur le nouvel OS ? Voire pire, lorsqu'il finit par faire faillite ou disparaître du panorama, pour ne pas réussir à sortir de ce mauvais pas ?
La maintenance n'est qu'une assurance comme les autres, et ne devrait pas sortir de ce rôle. Quand le prix actualisé de l'assurance dépasse de beaucoup le prix du bien assuré, il y a un problème.
Il est aussi des cas où ce n'est pas une bonne idée. Quand tu envoies une fusée dans l'espace, ou même si tu diffuses un produit grand public à des millions d'exemplaires, il n'est pas encore admis par tout le monde que le code devra peut-être évoluer dans le futur...
Détrompe toi: tout est conçu pour évoluer de nos jours.
Détrompe toi : je suis parfaitement conscient des reprogrammations possibles et mises en ½uvre ici ou là. En particulier pour ce qui concerne l'espace (où j'ai pris à dessein l'exemple d'une fusée, en souvenir d'un bogue fameux pour son importance sur les concepts de génie logiciel, et en prenant soin de mentionner l'exemple très voisin de l'aviation de ligne.) Aussi pour ce qui concerne l'automobile, que j'ai du mal à inclure dans la catégorie de articles grand public, et qui est ÀMHA par bien des points une exception du point de vue de la maintenance (des presses pliaient encore des côtés de R16 à Flins vers 1992 ; et j'ai assisté en 1994 à une intéressante discussion sur l'avenir d'une machine spéciale pour fabriquer des pièces de moteur de 4CV et de R4, parce que Renault voulait savoir où finirait la dite machine, irremplaçable, pour le cas où on ait à refaire une série de pièces détachées... une démarche pro active, que certains font aussi dans le domaine du logiciel, par exemple en prenant soin de garder utilisables les compilateurs utilisés pour générer chaque version livrée.)
Et pour revenir à l'exemple des téléviseurs, la pratique existe depuis des années sur le satellite... et je n'ai jamais réussi à récupérer en téléchargement la mise à jour de mes décos, j'ai toujours eu à recourir à FTP et au port RS-232C ; et pour avoir passé un peu de temps à regarder les signaux transmis, il me semble bien qu'au bout d'un an environ, les fabricants passent à autre chose : en fait le téléchargement ne semble être rien d'autre pour eux qu'un outil leur permettant de peaufiner la mise au point de leur logiciel au-delà de la date de livraison, grâce à un ensemble plus larges de cobayes pour finaliser les tests ; de la même manière que pour Microsoft la RTM n'est qu'un point de la durée de vie d'un produit, le produit stabilisé est plutôt le premier SP, où on trouve très peu de nouveautés et beaucoup de corrections de bogues...
Antoine
Philippe Estival
> Apres, si tu veux faire des calculs precis, ben c'est complique, tu le sais aussi bien que moi. Voire impossible, et ca c'est plus drole (savoir que les equations diophantiennes, c'est mort, par exemple, c'est toujours amusant).
(desole, a la bourre, je detaillerai ce dont je parle si on me demande).
Oui j'aimerais bien que tu nous expliques : c'est hors sujet, mais allons-y quand même, la confiture c'est comme les très grands nombres : ça s'étale. Si le théorème de Matiyasevich nous dit qu'"en général" les problèmes diophantiens ne sont résolubles, ça ne veut pas dire qu'ils ne le sont pas. Des solutions se trouvent parfois aisément pour des équations avec un sens géométrique, bonsoir.
> Apres, si tu veux faire des calculs precis, ben c'est complique, tu le
sais aussi bien que moi. Voire impossible, et ca c'est plus drole
(savoir que les equations diophantiennes, c'est mort, par exemple, c'est
toujours amusant).
(desole, a la bourre, je detaillerai ce dont je parle si on me demande).
Oui j'aimerais bien que tu nous expliques : c'est hors sujet, mais allons-y
quand même, la confiture c'est comme les très grands nombres : ça s'étale.
Si le théorème de Matiyasevich nous dit qu'"en général" les problèmes
diophantiens ne sont résolubles, ça ne veut pas dire qu'ils ne le sont pas.
Des solutions se trouvent parfois aisément pour des équations avec un
sens géométrique, bonsoir.
> Apres, si tu veux faire des calculs precis, ben c'est complique, tu le sais aussi bien que moi. Voire impossible, et ca c'est plus drole (savoir que les equations diophantiennes, c'est mort, par exemple, c'est toujours amusant).
(desole, a la bourre, je detaillerai ce dont je parle si on me demande).
Oui j'aimerais bien que tu nous expliques : c'est hors sujet, mais allons-y quand même, la confiture c'est comme les très grands nombres : ça s'étale. Si le théorème de Matiyasevich nous dit qu'"en général" les problèmes diophantiens ne sont résolubles, ça ne veut pas dire qu'ils ne le sont pas. Des solutions se trouvent parfois aisément pour des équations avec un sens géométrique, bonsoir.
espie
In article <hfmliu$gmf$, Philippe Estival wrote:
Apres, si tu veux faire des calculs precis, ben c'est complique, tu le sais aussi bien que moi. Voire impossible, et ca c'est plus drole (savoir que les equations diophantiennes, c'est mort, par exemple, c'est toujours amusant).
(desole, a la bourre, je detaillerai ce dont je parle si on me demande).
Oui j'aimerais bien que tu nous expliques : c'est hors sujet, mais allons-y quand même, la confiture c'est comme les très grands nombres : ça s'étale. Si le théorème de Matiyasevich nous dit qu'"en général" les problèmes diophantiens ne sont résolubles, ça ne veut pas dire qu'ils ne le sont pas. Des solutions se trouvent parfois aisément pour des équations avec un sens géométrique, bonsoir.
Ben oui, j'ai tres resume, et c'est evidemment a ce theoreme que je faisais reference. C'est quand meme un des exemples les plus classiques de problemes non calculables ayant une applicabilite reelle...
Avec la meme idee, je sais faire du tri en temps nul: suffit que je me limite aux donnees qui sont deja dans le bon ordre...
In article <hfmliu$gmf$1@news.cerfacs.fr>,
Philippe Estival <i@n.cer.facs.net> wrote:
Apres, si tu veux faire des calculs precis, ben c'est complique, tu le
sais aussi bien que moi. Voire impossible, et ca c'est plus drole
(savoir que les equations diophantiennes, c'est mort, par exemple, c'est
toujours amusant).
(desole, a la bourre, je detaillerai ce dont je parle si on me demande).
Oui j'aimerais bien que tu nous expliques : c'est hors sujet, mais allons-y
quand même, la confiture c'est comme les très grands nombres : ça s'étale.
Si le théorème de Matiyasevich nous dit qu'"en général" les problèmes
diophantiens ne sont résolubles, ça ne veut pas dire qu'ils ne le sont pas.
Des solutions se trouvent parfois aisément pour des équations avec un
sens géométrique, bonsoir.
Ben oui, j'ai tres resume, et c'est evidemment a ce theoreme que je
faisais reference. C'est quand meme un des exemples les plus classiques
de problemes non calculables ayant une applicabilite reelle...
Avec la meme idee, je sais faire du tri en temps nul: suffit que je
me limite aux donnees qui sont deja dans le bon ordre...
Apres, si tu veux faire des calculs precis, ben c'est complique, tu le sais aussi bien que moi. Voire impossible, et ca c'est plus drole (savoir que les equations diophantiennes, c'est mort, par exemple, c'est toujours amusant).
(desole, a la bourre, je detaillerai ce dont je parle si on me demande).
Oui j'aimerais bien que tu nous expliques : c'est hors sujet, mais allons-y quand même, la confiture c'est comme les très grands nombres : ça s'étale. Si le théorème de Matiyasevich nous dit qu'"en général" les problèmes diophantiens ne sont résolubles, ça ne veut pas dire qu'ils ne le sont pas. Des solutions se trouvent parfois aisément pour des équations avec un sens géométrique, bonsoir.
Ben oui, j'ai tres resume, et c'est evidemment a ce theoreme que je faisais reference. C'est quand meme un des exemples les plus classiques de problemes non calculables ayant une applicabilite reelle...
Avec la meme idee, je sais faire du tri en temps nul: suffit que je me limite aux donnees qui sont deja dans le bon ordre...
Philippe Estival
Marc Espie wrote, On 12/09/2009 12:07 AM:
In article <hfmliu$gmf$, Philippe Estival wrote:
Apres, si tu veux faire des calculs precis, ben c'est complique, tu le sais aussi bien que moi. Voire impossible, et ca c'est plus drole (savoir que les equations diophantiennes, c'est mort, par exemple, c'est toujours amusant).
(desole, a la bourre, je detaillerai ce dont je parle si on me demande).
Oui j'aimerais bien que tu nous expliques : c'est hors sujet, mais allons-y quand même, la confiture c'est comme les très grands nombres : ça s'étale. Si le théorème de Matiyasevich nous dit qu'"en général" les problèmes diophantiens ne sont résolubles, ça ne veut pas dire qu'ils ne le sont pas. Des solutions se trouvent parfois aisément pour des équations avec un sens géométrique, bonsoir.
Ben oui, j'ai tres resume, et c'est evidemment a ce theoreme que je faisais reference. C'est quand meme un des exemples les plus classiques de problemes non calculables ayant une applicabilite reelle... Avec la meme idee, je sais faire du tri en temps nul: suffit que je me limite aux donnees qui sont deja dans le bon ordre...
L'exemple est amusant. Mais redéfinir l'espace d'un problème dans un sous-espace (de R dans Z par exemple), est un problème d'une autre nature que celui qui consiste à explorer un espace déjà fonctionnel (l'intervalle de Z trié par ex.).
Traiter une quantité d'information nulle prend un temps nul.
Marc Espie wrote, On 12/09/2009 12:07 AM:
In article <hfmliu$gmf$1@news.cerfacs.fr>,
Philippe Estival <i@n.cer.facs.net> wrote:
Apres, si tu veux faire des calculs precis, ben c'est complique, tu le
sais aussi bien que moi. Voire impossible, et ca c'est plus drole
(savoir que les equations diophantiennes, c'est mort, par exemple, c'est
toujours amusant).
(desole, a la bourre, je detaillerai ce dont je parle si on me demande).
Oui j'aimerais bien que tu nous expliques : c'est hors sujet, mais allons-y
quand même, la confiture c'est comme les très grands nombres : ça s'étale.
Si le théorème de Matiyasevich nous dit qu'"en général" les problèmes
diophantiens ne sont résolubles, ça ne veut pas dire qu'ils ne le sont pas.
Des solutions se trouvent parfois aisément pour des équations avec un
sens géométrique, bonsoir.
Ben oui, j'ai tres resume, et c'est evidemment a ce theoreme que je
faisais reference. C'est quand meme un des exemples les plus classiques
de problemes non calculables ayant une applicabilite reelle...
Avec la meme idee, je sais faire du tri en temps nul: suffit que je
me limite aux donnees qui sont deja dans le bon ordre...
L'exemple est amusant. Mais redéfinir l'espace d'un problème dans un
sous-espace
(de R dans Z par exemple), est un problème d'une autre nature que
celui qui
consiste à explorer un espace déjà fonctionnel (l'intervalle de Z trié
par ex.).
Traiter une quantité d'information nulle prend un temps nul.
Apres, si tu veux faire des calculs precis, ben c'est complique, tu le sais aussi bien que moi. Voire impossible, et ca c'est plus drole (savoir que les equations diophantiennes, c'est mort, par exemple, c'est toujours amusant).
(desole, a la bourre, je detaillerai ce dont je parle si on me demande).
Oui j'aimerais bien que tu nous expliques : c'est hors sujet, mais allons-y quand même, la confiture c'est comme les très grands nombres : ça s'étale. Si le théorème de Matiyasevich nous dit qu'"en général" les problèmes diophantiens ne sont résolubles, ça ne veut pas dire qu'ils ne le sont pas. Des solutions se trouvent parfois aisément pour des équations avec un sens géométrique, bonsoir.
Ben oui, j'ai tres resume, et c'est evidemment a ce theoreme que je faisais reference. C'est quand meme un des exemples les plus classiques de problemes non calculables ayant une applicabilite reelle... Avec la meme idee, je sais faire du tri en temps nul: suffit que je me limite aux donnees qui sont deja dans le bon ordre...
L'exemple est amusant. Mais redéfinir l'espace d'un problème dans un sous-espace (de R dans Z par exemple), est un problème d'une autre nature que celui qui consiste à explorer un espace déjà fonctionnel (l'intervalle de Z trié par ex.).
Traiter une quantité d'information nulle prend un temps nul.
Antoine Leca
Philippe Estival a écrit :
Traiter une quantité d'information nulle prend un temps nul.
Seulement si tu sais que la quantité est toujours nulle. Si tu ne le sais pas, ce qui sera le cas d'un algorithme normalement générique, ton algorithme devra découvrir qu'il n'y a pas d'information à traiter, et cette découverte lui prendra un temps non nul.
Antoine
Philippe Estival a écrit :
Traiter une quantité d'information nulle prend un temps nul.
Seulement si tu sais que la quantité est toujours nulle.
Si tu ne le sais pas, ce qui sera le cas d'un algorithme normalement
générique, ton algorithme devra découvrir qu'il n'y a pas d'information
à traiter, et cette découverte lui prendra un temps non nul.
Traiter une quantité d'information nulle prend un temps nul.
Seulement si tu sais que la quantité est toujours nulle. Si tu ne le sais pas, ce qui sera le cas d'un algorithme normalement générique, ton algorithme devra découvrir qu'il n'y a pas d'information à traiter, et cette découverte lui prendra un temps non nul.
Antoine
Phil Estival
>> Traiter une quantité d'information nulle prend un temps nul.
Seulement si tu sais que la quantité est toujours nulle.
Oui, c'est ce que j'ai écrit : une quantité d'information nulle. La quantité d'information d'un message est nul si on connait déjà le message. C'est comme si ce clown de Poujadas me communique une nouvelle de la veille que j'ai déjà lu ou entendu : information zero.
Si tu ne le sais pas, ce qui sera le cas d'un algorithme normalement générique, ton algorithme devra découvrir qu'il n'y a pas d'information à traiter, et cette découverte lui prendra un temps non nul.
En l'absence de certitude sur la quantité d'information, cette information ne sera pas nulle, mais transportera au moins deux bits : oui il y a information ou non il n'y en a pas, le second bit étant le minimum d'information en question... et l'algorithme de se poursuivre.
>> Traiter une quantité d'information nulle prend un temps nul.
Seulement si tu sais que la quantité est toujours nulle.
Oui, c'est ce que j'ai écrit : une quantité d'information nulle.
La quantité d'information d'un message est nul si on connait déjà le
message.
C'est comme si ce clown de Poujadas me communique une nouvelle de la veille
que j'ai déjà lu ou entendu : information zero.
Si tu ne le sais pas, ce qui sera le cas d'un algorithme normalement
générique, ton algorithme devra découvrir qu'il n'y a pas d'information
à traiter, et cette découverte lui prendra un temps non nul.
En l'absence de certitude sur la quantité d'information, cette information
ne sera pas nulle, mais transportera au moins deux bits : oui il y a
information
ou non il n'y en a pas, le second bit étant le minimum d'information en
question...
et l'algorithme de se poursuivre.
>> Traiter une quantité d'information nulle prend un temps nul.
Seulement si tu sais que la quantité est toujours nulle.
Oui, c'est ce que j'ai écrit : une quantité d'information nulle. La quantité d'information d'un message est nul si on connait déjà le message. C'est comme si ce clown de Poujadas me communique une nouvelle de la veille que j'ai déjà lu ou entendu : information zero.
Si tu ne le sais pas, ce qui sera le cas d'un algorithme normalement générique, ton algorithme devra découvrir qu'il n'y a pas d'information à traiter, et cette découverte lui prendra un temps non nul.
En l'absence de certitude sur la quantité d'information, cette information ne sera pas nulle, mais transportera au moins deux bits : oui il y a information ou non il n'y en a pas, le second bit étant le minimum d'information en question... et l'algorithme de se poursuivre.
