Articles précédents : Articles
- [9] Unix/sh : la meilleur interface utilisateur ?
- [20] Da Geek Contest #3
- [68] Bobby Fischer joue anonymement sur Internet
- [69] L'accès au site de Nessus devient restreint
- [34] Fujitsu va mettre en vente HOAP-1
- [37] Le Bundestag se méfie des produits Microsoft
- [69] le site de Ximian fait peau neuve
- [31] Discussion autour du ... brevet
- [36] J2EE/Enhydra: le jeu étrange de Sun
- [25] Intel se sent menacé ...
Liens connexes
- First illegal prime number (1717 hits)
- an executable prime number (1198 hits)
- the register (410 hits)
- tutorial CSS (597 hits)
Dépêche modérée par
Articles : Un nombre premier exécutable ... illégal ?
Posté par pappy (page perso, ). Modéré le 14 septembre 2001.
Il y a qq temps, Phil Carmody avait réussit à convertir le code de DeCSS en un nombre premier (nombre divisible que par 1 et lui-même).
Il revient, toujours plus fort, avec un nombre premier exécutable en tentant de répondre à la passionnante question : est-ce tous les programmes sont <<exprimables>> sous forme d'un nombre premier exécutable ?
A titre d'exemple scientifique, il travaille sur le nombre premier qui représente DeCSS ... mais que va dire la MPAA ?
![[en]](../../../images/en.png)
First illegal prime number (1717 hits)-
an executable prime number (1198 hits)
-
the register (410 hits)
-
tutorial CSS (597 hits)
> Lire les commentaires (57 commentaires, moyenne: 1,5).
Très joli
Je trouve ca très demonstratif de montré que un nombre premier peut être illégal pour le MPAA.
leur tête au bout d'un pique :D
(attention j'ai mis un ':D')
-
[^]Re: Très joli
Posté par Eudoxe () le 14/09/2001 à 20:12. (lien). Évalué à 3.Il existe des nombres appelés "nombres-univers" qui contiennent dans leurs décimales tous les nombres entiers existants.
Par exemple le nombre de Champernown (?) : 0.1234567891011121314...
et peut-être pi (et d'autres).
Donc ce nombre contient aussi cette valeur de DeCSS, par conséquent un nombre-univers est illégal pour le MPAA. :)
--
CQFD
Le même et qui fasse des divx
Ca serait pas merveilleux, un nombre premier qui rip les dvd et les encode en dvd !
Ah les brevets
DeCSS n'a pas fini de faire couler beaucoup d'encre, ou plutôt beaucoup d'octets. On en revient toujours au problème des brevets logiciel. Lorsque le logiciel en question devient un nombre... personne ne peux devenir propriétaire d'un nombre... Quoi que Peugeot avait bien déposé les nombre à 3 chiffres avec 0 au milieu. D'un autre coté Intel a appelé ses processeurs Puntium car il ne pouvait être propriétaire de 586 qui justement était un nombre.
A suivre...
-
[^]Re: Ah les brevets
Posté par Anonyme () le 14/09/2001 à 08:42. (lien). Évalué à 5.Le fameux nombres déposés par Peugeot n'ont cependant pas grand chose a voir avec les brevets. Cela ne veux pas dire que ce nombre leur appartient.
Cela donnerait lieu à un procès si Renault voulait créer une R306, mais si Heknkel voulait créer une lessive 306, ou des chouches 306, je ne sais pas si Peugeot pourrait y faire grand chose.
Le problème qui a vu le jour avec Illustrator & KIllustrator est presque pareil: cela voudrait dire que si quelqu'un crérait un KWindows ou un GPhotoshop, il pourrait se prendre un procès dans la face, étant donné ques les produits portant presque le même nom sont dans le même secteur d'activité.
GNutella, par contre, a pas grand chose a craindre.
La chose est différente pour les brevets, vu que, je crois, on ne peut pas (encore) breveter un nombre, voire un nom.-
[^]Re: Ah les brevets
Posté par kadreg () le 14/09/2001 à 08:48. (lien). Évalué à 2.Cela donnerait lieu à un procès si Renault voulait créer une R306
C'est deja arrivé. La Porsche 911 devait a l'origine s'appeler 901, et a du être rebaptisé suite à une remarque de Peugeot (ca s'est fait a l'amiable). A noter qu'il n'y a jamais eut de Peugeot 901.-
[^]Re: Ah les brevets
Posté par Anonyme () le 14/09/2001 à 09:10. (lien). Évalué à 1.La 901, c'était pas la voiture proto de chez Peugeot qui courrait les 24 heures du Mans?
Ah ben non, c'était la 905. J'ai fait une recherche sur le site de peugeot, rien sur la 901. Va comprendre Charles...-
[^]Re: Ah les brevets
Posté par Axel R. (page perso, ) le 14/09/2001 à 09:31. (lien). Évalué à 0.Les nombres sont brevetables ? Cool ça !
Axel - 584-
[^]Re: Ah les brevets
Posté par kadreg () le 14/09/2001 à 09:35. (lien). Évalué à 1.Pas brevetable, mais on peut les deposer comme marques, ce qui permet d'eviter leur utilisation ulterieur dans le meme domaine.
-
[^]Re: Ah les brevets
Posté par Arnaud (page perso, ) le 14/09/2001 à 22:38. (lien). Évalué à 1.hum ... t'es sur ?
pourquoi intel à laisser tomber la dénomination des x86 alors ?
-
-
-
-
-
[^]Re: Ah les brevets
Posté par Axel R. (page perso, ) le 14/09/2001 à 09:34. (lien). Évalué à 1.Pour GNutella, ils ont pas eu des problemes avec leur logo qui ressemblait beaucoup à une marque de pâte chocolaté à tartiner ?
Axel - 584
-
[^]Re: Ah les brevets
Posté par Anonyme () le 14/09/2001 à 12:19. (lien). Évalué à 1.Si je me souviens bien, GNUtella avait des problèmes avec Nutella parce que ça nuisait à leur image de marque.
Cela dit, je ne sais pas s'ils ont eu des problèmes avec GNU, mais d'après la logique de la chose, ils auraient dû, sauf si le projet fait partie officielle du projet GNU.
Car si je me souviens bien (j'ai des problèmes de mémoire :o) ), si un programme schmool ne fait pas partie de GNU, il ne peut pas s'appeler GNUdschmool.
-
-
[^]Re: Ah les brevets
Posté par Anonyme () le 14/09/2001 à 11:18. (lien). Évalué à 1.le brevet c'est se préserver le droit d'une
EVENTUELLE action future.
Avez-vous noté le copyright suivant le slogan
Maxigaffe (pardon... µsoft!)"mais que ferez-vous demain?"
rien ne vous interdit de le dire. Mais si µsoft estime que cela porte atteinte à son image, il peut vous attaquer et très probablement gagner!
A partir de là, cela se transforme en épée de Damoclès bien déplaisante (surtout quand son tranchant s'abat sur vous!)
L'absurdité du système culmine avec les noms de marque qui cherchent à interdire à un citoyen lambda d'utiliser le sien du fait de l'homonymie (voir les nombreux cas de sociétés "de quartier" tenues par la justice de changer de raison sociale parce qu'une Major homonyme avait trouvé via le net qu'un "concurrent" détenait déjà le nom de domaine -bien que quelques affaires aient démontré l'existance de la dite société avant la création de la Major-!)
Ah dites donc! si l'inventeur de la roue avait déposé un brevet, pauvres de nous!
Un nouvel algo de compression ?
Juste une idée - probablement débile...
Supposons qu'un binaire ne soit pas un nombre premier, on pourrait en faire la décomposition en nombres premiers.
Avec un peu de chance cette décomposition sera plus petite que le nombre initial.
On pourrait même utiliser le rang des nombres premiers avec une table pour gagner encore un peu.
-
[^]Re: Un nouvel algo de compression ?
Posté par jr lamoule (page perso, ) le 14/09/2001 à 08:45. (lien). Évalué à 1.Ben, si je comprend bien ton idée, tu voudrais faire une factorisation d'un nombre en nombre premiers ?
C'est pas sur le fait que cette décomposition est très difficile que reposent les méthodes de cryptographie actuelle (enfin, j'ai plus vraiment de souvenirs hein ...)
Alors bon, si ta compression doit mettre des siecles a se faire, euh ... Je doute de la validité de ton idée.
Par contre, la décompression elle serai rapide.
Corrigez moi si j'ai dis une betise ... C'est après tout fort possible.-
[^]Re: Un nouvel algo de compression ?
Posté par Olivier Dupuis () le 14/09/2001 à 12:42. (lien). Évalué à 3.>C'est pas sur le fait que cette décomposition est
>très difficile que reposent les méthodes de
>cryptographie actuelle (enfin, j'ai plus vraiment
>de souvenirs hein ...)
C'est exactement là-dessus que se base la sécurté de la méthode RSA. Ta mémoire est bonne.
La clef publique est le produit de deux nombres premiers "grands". Et actuellement on ne dispose pas de méthode "rapide" pour décomposer un nombre.
En gros, rien de tellement mieux que d'essayer de diviser le nombre par les nombres premiers inférieurs à son carré.
Le second problème vient du fait qu'à moins de connaître exactement tous ces dits nombres premiers inférieurs à sa racine carrée, on en est souvent réduit à tester 2, 3 et 5 puis 7+2*k.
Au final, si le nombre est "grand", l'algorithme de décomposition est en n^(1/2) avec n la valeur du nombre a décomposer.
Le temps de calcul augmente beaucoup trop vite avec la taille du nombre.
(J'espère juste ne pas m'être trompé dans ces calculs...)-
[^]RSA != factorisation
Posté par pappy (page perso, ) le 14/09/2001 à 18:48. (lien). Évalué à 2.Je sais, vous allez être déçu, mais RSA et la facatorisation sont deux problèmes différents.
RSA repose sur la factorisation, ce qui fait que si on trouve un algorithme polynomial pour factoriser, RSA est cassé.
MAIS on ne sait pas si il y a besoin de factoriser pour casser RSA.
Par exemple, il existe des nombres premiers particuliers (je ne me souviens plus de leur nom) qu'il faut absolument éviter de choisir quand tu génères tes clés sans quoi tu peux casser RSA sans avoir à factoriser.
Par ailleurs, il existe d'autres algorithmes, bien plus performants que ceux dont tu parles pour factorise (tester tous les nombres premiers inférieurs à sqrt(n)) : le crible quadratique et le crible algébrique.
Tu trouveras ds référecnes sur cette page :
http://www.lix.polytechnique.fr/Labo/Francois.Morain/Crypto/crypto.(...)
-
-
-
[^]Re: Un nouvel algo de compression ?
Posté par GP Le (page perso, ) le 14/09/2001 à 08:53. (lien). Évalué à 0.OUi, c'est nimp !
Un programme doit etre precis au bit pres. Sinon, il ne s'execute pas correctement. C'est un melange d'une grande recherche et d'une bonne chance que d'avoir ecrit DECSS sous forme d'un nombre premier.
-
[^]Re: Un nouvel algo de compression ?
Posté par Foxy (page perso, ) le 14/09/2001 à 08:54. (lien). Évalué à 6."Juste une idée - probablement débile... "
L'idée est intéressante mais complétement irréalisable. En effet, tout personne ayant fait un tant soit peu de math ;-) sait que le problème de décomposition d'un nombre entier en facteurs entiers est un problème très difficile (en langage correct, on dit "NP-complet").
Autrement dit, la décomposition en facteurs premiers est bien trop consommatrice de ressources pour être effectuée dans un temps raisonnable.
L'algorithme de crypto à clé publique RSA est d'ailleurs basé sur ce principe.
"On pourrait même utiliser le rang des nombres premiers avec une table pour gagner encore un peu."
Cette idée est déjà mise en place dans les algos de ce type mais ne permet pas de gagner beaucoup d'efficacité. (Voir un bon bouquin de crypto pour plus de détails).-
[^]Re: Un nouvel algo de compression ?
Posté par jigso () le 14/09/2001 à 09:33. (lien). Évalué à 1."L'idée est intéressante mais complétement irréalisable. En effet, tout personne ayant fait un tant soit peu de math ;-) sait que le problème de décomposition d'un nombre entier en facteurs entiers est un problème très difficile (en langage correct, on dit "NP-complet"). "
Certes, mais je pense qu'en découpant le binaire en morceaux relativement petit, ça devrait être faisable.
Qqu'un connait-il les ordres de grandeur de factorisation de nombres, mettons, de 10 chiffres, 50, 100 ?-
[^]Re: Un nouvel algo de compression ?
Posté par Olivier Dupuis () le 14/09/2001 à 14:13. (lien). Évalué à 0.Tu te trompes ! J'ai écris plus haut un algorithme qui résoud ce problème en n^(1/2). On est donc très loin d'un problème NP-complet.
Voir pour plus d'info sur la complexité de ce problème et des résultat en temps de calcul :
http://dept-info.labri.u-bordeaux.fr/~betrema/deug/poly/premiers.ht(...)
(très grossièrement, un problème est dit NP-complet si on ne sait pas montrer qu'il est au mieux exponentiel ou polynomial ; actuellement, on ne dispose que d'algorithme exponentiel pour les résoudre et comme ils sont dans une même classe d'équivalence, dès q'un tombe, tout le reste suit).-
[^]Re: Un nouvel algo de compression ?
Posté par Foxy (page perso, ) le 14/09/2001 à 15:13. (lien). Évalué à 1.Va réviser tes cours de compléxité algorithmique (si tu en as suivi) : un algorithme est dit "NP-complet" si son temps de résolution est exponentiel en fonction de la taille des entrées (ici, le nombre de chiffres pour écrire l'entier à décomposer).
Un algo est dit "P-complet" si son temps de résolution varie comme un polynome de la taille des entrées.
Et va relire l'URL que tu donnes : la factorisation d'un nombre entier est "NP-complet".
Tu confonds tout : ce n'est pas parce que l'algorithme d'Euclide (celui que tu as décrit) fait sqrt(n) opérations qu'il n'est pas NP-complet.
Extrait de l'URL :
- "si par exemple n = pq est le produit de deux nombres premiers voisins, l'algorithme a une complexité exponentielle en fonction du nombre de chiffres nécessaires pour écrire n."
- "si n s'écrit avec k chiffres en base b, la complexité de cet algorithme est proportionnelle à bk/2, et est donc exponentielle en fonction de k. "
Un DEA d'informatique théorique, ça sert parfois avant de dire n'importe quoi ;-)-
[+] [^]Re: Un nouvel algo de compression ?
Posté par Olivier Dupuis () le 14/09/2001 à 16:35. (lien). Évalué à -1.On ne parle pas de la même chose : je persiste et je signe en disant que trouver un facteur d'un nombre n se fait en sqrt(n), donc la difficulté augmente en racine de n avec n. C'est exponentiel, mais en puissance 1/2...
Ce que dit le texte en référence, c'est que la difficulté augmente exponentiellement (avec une puissance > 1) en fonction DU NOMBRE DE CHIFFRES NECESSAIRES pour décrire n :
Pour n = 100, 3 chiffres seulement sont nécessaires.
Si tu décris le problème en étudiant l'exposant dans une base donnée, tu passes d'un problème de taille n en exp(n).
Au fait, j'ai beau relire le texte, je n'arrive pas à trouver où ils prétendent que c'est NP-difficile. Ce qu'il faut comprendre, c'est qu'il est facile actuellement d'augmenter le nombre de chiffres pour décrire un nombre : on multiplie par 1000 le nombre (de 3 l'exposant en base 10), on augmente de facto le temps de calcul par 30... Ce qui finit vite pas devenir gros.
Pour finir, j'ai un DEA d'info et j'ai suivi des cours de complexité algorithmique et je bosse actuellement sur des problème NP-difficiles si pas plus. Ce qui ne m'empêche pas de dire des bétises :)
-
[^]Re: Un nouvel algo de compression ?
Posté par Gaël Le Mignot (page perso, ) le 15/09/2001 à 12:14. (lien). Évalué à 0.Quelques précisions sur les problèmes P, NP et NP-complet:
P signifie Polynomial: il existe un algorithme qui resout le problême en un temps polynomial dans le pire cas.
NP ne signifie pas non polynomial mais Non-deterministic Polynomial. Cela signifie qu'il est possible en temps polynomial de tester si un candidat X est ou n'est pas solution du problème.
Un problème P est un problème NP tout comme un carré est un rectangle.
En géneral, on parle de problème NP-complet pour désigner les problèmes de complexité exponentielle , car il existe un théorème (le théorème de Cook) qui indique que certains problemes NP (dits NP-complet) sont équivalents, et qui si on peut en résoudre un de manière polynomiale, alors on peut résoudre les autres aussi.
Pour plus d'informations, voir le rapport que l'un des mes camarades a fait:
http://www.epita.fr:8000/~barada_n(...)
-
-
-
-
[+] [^]Re: Un nouvel algo de compression ?
Posté par Anonyme () le 14/09/2001 à 12:12. (lien). Évalué à -1.... sait que le problème de décomposition d'un nombre entier en facteurs entiers est un problème très difficile
Effectivement, c'est même impossible, puisque le principe du nombre premier, c'est que tu ne peux pas le décomposer en facteurs entiers ;)
-
-
[^]Re: Un nouvel algo de compression ?
Posté par Christophe GRAND (page perso, ) le 14/09/2001 à 09:30. (lien). Évalué à 10.Non.
Ton binaire représente un nombre N. Il a donc besoin de log2(N) bits pour être représenté.
(log2(x)=ln(x)/ln(2))
ok ?
Mettons que ce nombre se décompose en XY.
or log2(N)=log2(XY)=log2(X)+log2(Y)
donc on a rien gagné : le nombre de bits nécessaire pour représenter les facteurs est le même que le nombre de bits nécessaires pour représenter le produit.
Et comme c'est un code à longueur variable, il faut des bits de stop et tout et tout.
Non, désolé, ça ne marchera jamais !-
[^]Re: Un nouvel algo de compression ?
Posté par jigso () le 14/09/2001 à 09:49. (lien). Évalué à 5.Bon ok. J'avais prévenu que c'était probablement débile...
Ça pourrait marcher si certains facteurs sont présents plusieurs fois, mais ça fera pas lourd au final comme compression.
De façon plus génerale, est-ce que la "description" d'un nombre sous forme d'une formule "calculable" occupe le même ordre de grandeur de bit que le nombre ?
Je serais tenté de dire non, 123^4 prend moins de place que 228886641. Mais trouver la "bonne" formule est certainement une gageure dans le cas général...
Pour finir, connaissez-vous "le plus petit nombre non descriptible en moins de douze mots" ?
Gasp, mais cette description en compte 11 !
...
-
-
[^]Re: Un nouvel algo de compression ?
Posté par Anonyme () le 14/09/2001 à 13:59. (lien). Évalué à 0.On appelle cette technique "les nombres de göedels"(*). C'est une grande légende, qui nous vient des débuts de l'informatique, je crois me souvenir que Turing est mélé à une histoire de ce genre.
Théoriquement c'est la panacée, techniquement, on attendra après Moore encore longtemps ...
(*) orthographe ?-
[^]Re: Un nouvel algo de compression ?
Posté par Anonyme () le 14/09/2001 à 21:37. (lien). Évalué à 2.Les nombres de Gödel n'ont rien à voir avec la factorisation des nombres entiers en nombres premiers. Et ça n'a rien d'une légende.
(grosso modo) Ils ont servis à démontrer que si on formalisait les mathématiques (et quelle que soit la formalisation), le système formel serait incomplet (= il existe des vérités indémontrables) et/ou inconsistant (= on peut démontrer une chose et son contraire)
Les nombres de Gödel sont en fait une représentation de chaque symbole du système formel.
Pour plus de renseignements, cherchez des infos sur le "Théorème de Gödel"
-
-
[^]Re: Un nouvel algo de compression ?
Posté par Nicolas Vabo () le 14/09/2001 à 16:34. (lien). Évalué à 0.C'est une bonne idée, très intéressante, faisable facilement avec un script bash, avec factor qui décompose le nombre en nombre premier.
Bien sûr la compression peut demander du temps, mais certain nombres plus grands que d'autres peuvent être factorisés en moins longtemps, par exemple 2^500 se factorise plus rapidement que 3*5*132546798785412123453.
Pour gagner du temps, pourquoi ne pas découper le fichier en plusieurs plus petits ?
C'est vraiment faisable, faudrait essayer.
Un volontaire ?
-
[^]Re: Un nouvel algo de compression ?
Posté par Jar Jar Binks (page perso, ) le 14/09/2001 à 17:44. (lien). Évalué à 2.Effectivement, ça ne peut pas marcher.
Exemple simple, tu veux compresser le nombre 100.
100=5²×2²
Il te faut donc coder un 5 et trois 2 (en plus des informations sur la façon de les agencer), soit dans le meilleur des cas 3 bits pour le 5 et 2 bits pour chaque 2, soit 9 bits. Or, 8 bits suffisent pour coder 100.
De façon générale, un algorithme de compression sans pertes (compactage ?) doit se baser sur les propriétés des données à compresser. Par exemple, un fichier texte contient plus de e que de ®. Mais de façon générale, un tel algorithme est une bijection. L'ensemble d'arrivée (l'ensemble des programmes compactés) et l'ensemble de départ (l'ensemble des programmes non compactés) doivent faire la même taille. En moyenne, un programme compacté, s'il est constitué d'octets aléatoires, fera donc la même taille qu'un programme qui ne l'est pas. Simplement, comme les programmes ont certaines propriétés, on arrive à faire pencher la balance d'un côté plutôt que de l'autre.
Juste mes deux centimes d'euros.
ouatisdat ?
Je sais ce que c'est qu'un nombre premier
Je sais ce que c'est qu'un executable
Mais je sais pas ce que ca veut dire un nombre premier executable (si je fait un shell script executable de 13 octets, c'est un nombre premier executable ? )
;-)
-
[^]Re: ouatisdat ?
Posté par GP Le (page perso, ) le 14/09/2001 à 08:56. (lien). Évalué à 2.Tu transforme le chiffre decimal en bianire et tu obtient la sequence bianire executable. Le seul probleme de ce nombre, c'est qu'il est executable sur 1 OS et une plateforme... donc au final :)
On peut faire la meme chose en transforme un fichier bianire zip en nombre !
-
[^]Re: ouatisdat ?
Posté par Frederic PY () le 14/09/2001 à 10:20. (lien). Évalué à 3.Ben c'est pas complique ton programme etant un fichier stocke en binaire il peut etre represnt par une valeur entiere et cette valeur peut etre un nombre premier (c'est pas force mais c'est probable)... donc si une personne decide de copier le fichier il ne fait que copier un nombre -- premier en l'occurence -- donc c'est quelque chose qui n'est pas sdu tout interdit ... c'estr un peut pilotracte mais voila
-
[^]Re: ouatisdat ?
Posté par Anonyme () le 14/09/2001 à 12:08. (lien). Évalué à 0.D'accord, mais alors ce que tu dis est valable également pour les nombres qui ne sont pas premiers.
Alors pourquoi parle-t-on de tels nombres ? En quoi le fait que ce nombre soit premier change qqch au niveau de la légalité de la copie ?-
[^]Re: ouatisdat ?
-
-
[+] To <> or not to <>
est-ce tous les programmes sont <> sous forme d'un nombre premier exécutable
Question intéressante!
A votre avois, ils sont <> ou ils sont pas <> ?
Et les modéros qui relisent, ils boivent de la <> ou de la >< ?
-
[^]Re: To <> or not to <>
Posté par Vivi (page perso, ) le 14/09/2001 à 09:06. (lien). Évalué à 1.Euh oui, ça veut dire quoi tout ça ?
Dans mon langage favori, <> ça veut dire "différent de" : apparemment, c'est pas ça ici ...-
[^]Re: To <> or not to <>
Posté par Christophe GRAND (page perso, ) le 14/09/2001 à 09:32. (lien). Évalué à 0.<> <-> equivalent
-
[^]Re: To <> or not to <>
-
-
Et Pi ?
Sachant que Pi est une suite de nombres qui ne se repete jamais, ledit nombre entier executable doit bien être inclus quelque part dans les decimales de Pi ? :-) (comment ça "un peu long à calculer" ?)
-
[^]Re: Et Pi ?
Posté par Jar Jar Binks (page perso, ) le 14/09/2001 à 17:49. (lien). Évalué à 1.Ça ne change rien au problème, il faudra bien que tu indiques à quelle décimale ton programme commence, et ce nombre est statistiquement aussi long une fois codé en binaire que ton programme.
Et d'ailleurs, il me semble que cette propriété de \pi n'a pas encore été démontrée.
-
[^]Re: Et Pi ?
Posté par Wawet76 (page perso, ) le 15/09/2001 à 02:08. (lien). Évalué à 2.Ce n'est pas parceque un nombre à un nombre de décimale infini et sans cycle que tout nombre doit y être inclus...
contre-exemple : Tu prends pi et tu retire toutes les occurrences de la chaine "123". Ca donne un nombre avec un nombre infini de décimales, sans boucle, et sans que 123 y soit inclus.-
[^]Re: Et Pi ?
Posté par Olivier Jeannet () le 15/09/2001 à 17:41. (lien). Évalué à 1.Tu prends pi et tu retire toutes les occurrences de la chaine "123". Ca donne un nombre avec un nombre infini de décimales, sans boucle, et sans que 123 y soit inclus.
Ton contre-exemple ne marche pas pour ton histoire de "123" car si Pi contient la séquence "1 123 2 123 3" (j'ai mis des blancs pour la lisibilité), une fois que tu as retiré les "123" il en reste une.
Ceci dit, je crois que quand on étudie statistiquement Pi, on trouve une équiprobabilité de tous les motifs possibles, ce qui laisse à penser (pour moi) qu'on a une probabilité non nulle d'y trouver à peu près n'importe quelle suite de chiffres.
-
Mouais....
Nombre premier ou pas, de toutes facons tout ce que l'on manipule (logiciels, audio, images etc...) peut avoir une représentation numérique (sous forme d'une entier atrocement long, par exemple).
La creativité peut s'exporter de nombreuses manières, mais ce n'est que la représentation d'une idée que l'on cible.
Parce qu'aprés tout, une contrefacon audio, ce n'est qu'une suite de bits, hein, il y a mathématiquement une probabilité pour que je reproduise accidentellement cette série, non ?
Alors le fait que ce soit un nombre (premier et/ou executable)(ou non d'ailleurs) qui represente un concept importe peu, le point important est qu'il y a ...hum... volonté de "diffusion". Et c'est ca que le RIAA cible. Donc je pense que son auteur peut malheureusement, en toute logique, être victime de poursuites.
Salut, tu browses à combien, toi ?
-
[^]Re: Mouais....
Posté par Anonyme () le 14/09/2001 à 13:23. (lien). Évalué à 4.Parce qu'aprés tout, une contrefacon audio, ce n'est qu'une suite de bits, hein, il y a mathématiquement une probabilité pour que je reproduise accidentellement cette série, non ?
Avant, on pensait qu'un grand nombre de personnes tapant n'importe quoi sur leur clavier finiraient par ecrire les oeuvres complete de shakespeare.
Depuis la tribune, on sait que c'est faux.-
[^]A mourir de rire!
Posté par Gauthier () le 14/09/2001 à 14:41. (lien). Évalué à 2.Avant, on pensait qu'un grand nombre de personnes tapant n'importe quoi sur leur clavier finiraient par ecrire les oeuvres complete de shakespeare.
Depuis la tribune, on sait que c'est faux.
Il ne faut pas avoir peur d'être rigolo. Le mauvais éléve qui raconte des blagues au fond de la classe, ne devrait pas avoir peur de le dire devant tous le monde.
J'ai plus de point pour scorer mais demain je mets +1. (zut demain c'est samedi je bosse pas)
-
Question
Ai-je le droit d'utiliser ce nombre premier pour mes clefs publiques/privées ?
-
[^]Re: Question
Posté par Wawet76 (page perso, ) le 15/09/2001 à 02:14. (lien). Évalué à 2.Ca m'amène à me poser une question...
Est-ce que le serveurs de clés publiques vérifient l'unicité des clefs qu'on leur donne en pature ?
(oui, je sais que c'est hautement improbable. Vous n'avez jamais entendu parler des générateurs d'improbabilités ?)
Cette page a été générée par Templeet en 0.2055s (dont 0.0249 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.