Salut.
Super idée cette enigme, par contre je me demande sil ne serait pas encore temps de couper un peu dans le lard, 300 chiffres c'est beaucoup (ca limite les outils utilisable comme wolfram qui fait la tête).

Salut,
Une petite estimation:
En oubliant pi et e (qui ne me semblent pas utile mais de toute manière ca ne changerait que très peu qualitativement ce que je m'apprête à dire) on a en tout 18 symboles pour écrire une formule.
Il faut considérer la famille des "formule d'environ 80 caractères" pour en avoir autant que de nombres de 100 chiffres (18^80 =~ 10^100), dans l'optique que bien sur toutes ces formules soient valides et en bijection parfaite avec notre ensemble de nombres à 100 chiffres. (alors qu'en pratique il y a certainement peu de formule valide et beaucoup donne le même nombre).
On considérant qu'un caractère sur deux est numérique que qu'on a dans ce qui reste 1 formule valide sur 100 et en se donnant un peu de marge on peut imaginer vaguement pouvoir "formuliser" un nombre de 100 chiffres quelconque avec une formule de 95 caractères, on fera aveuglement confiance à ce 95 dans la suite de cette petite remarque.
Ce qui est aussi marrant à noter c'est la proportion des nombres "très compactables",  avec seulement 1 symbole de moins, soit 94 symboles on représente au mieux que 1/18 de nos nombres de 100 chiffres, et avec 80 symboles on sans doute plus de chance de gagner au loto 2 fois que d'être tombé par hasard sur un nombre de 100 chiffres à ce point compactable.
Conclusion la formule sera certainement assez grosse: 95 symboles
On retiendra qu'au bilan avec les symboles autorisés une formule a en moyenne une très mauvaise capacité de compression(95%...), et que tomber par hasard sur un nombre très-compactable est exponentiellement improbable...

Edit: La reflection était valable pour un énonce de 100 chiffres. A adapter.

Bonne idée de TiLapiot (quoique irréalisable à mon avis), mais pour cela il faudrait ajouter la partie entière.

Allez du coup, j'autorise 2 symboles supplémentaires.

Malin
Bon allez, je baisse la difficulté en étant moins restrictif sur l'énoncé

Intéressant (je relirai ça à tête reposée).
Pour répondre à la question: avec lettres de l'alphabet, on gagne la possibilité d'écrire des mots. 2 peut donc être écrit comme étant "1+1" ou "un plus 1" ou autre, tant que le nombre 2 est bien décrit

Mon score est de 204 avec le nouvel énoncé (et sans se fouler)

204! intéressant.

On remarquera que dans la version light de l'énoncé on a 41 symboles différents.
Et que 41^186 = environ 10^300.  Par conséquent on est sur qu'en moyenne on ne peut pas exprimer un nombre quelconque de 300 caractères en moins de 186 caractère. (Et c'est une minoration optimiste pour les raisons évoquées dans mon premier post.)

Ton 204 c'est un truc du genre:

"et6gfipuq32gvm4cs2yp3telu4xc6a5wnu6d5zwz
mmy7u2y2as1zmok2d400v5ix8nxq0svfsdat0gec
gezi1dgw3itbcjpp1ys5tasltni8vib4xzuagrxu
etmchxt0mr1ckr608wxr1g937e6evong6rqik4bg
3rmn6hfeesm9vz1jw98v868q4u4hcg788 en base 36"

Qui fait 204 caractères. comme de par hasard. Et j'égalise! que d'action!
Mouhahah.

Plus sérieusement, je ne pense pas que l'on puisse faire beaucoup mieux que le changement de base. le nombre étant aléatoire, sans prendre trop de risque :

je parie que personne en utilisant les ~70 caractères permis n'arrivera à faire mieux que :  log N / log 70 =~163 caractères
(N étant le nombre à compresser)

En effet si on considère les 70^163 combinaisons de caractères utilisant ces symboles, elles recouvrent bien moins que N nombres différents (car certaines combinaisons n'ont pas de sens et on retombe plein de fois sur les même nombres).
La probabilité que l'une de ces 70^163 combinaisons donne N est donc extrêmement faible.

Pas mal comme idée.

A la base, j'étais parti sur autre chose: une sorte de couverture des entiers avec des grands nombres avec une définition de petite taille; mais si c'est plus rapide, c'est beaucoup moins efficace

En fait il y a peut être une manière très courte d'écrire ce nombre : il faut étudier pour ça le programme de générateur pseudo-aléatoire qui l'a généré.

Si le programme est suffisamment court, il se compressera très bien. Mais si il s'appuie sur une liste de grand nombre pour générer le pseudo-aléatoire, là on n'est pas sûr d'avoir un bon résultat avec cette méthode.

ça me donne quand même une idée : quand on tape "au hasard" sur le clavier, on a tendance à taper sur les touches de proche en proche, sans faire d'un coup de grands sauts. Peut être qu'on peut exploiter ça...

Oui du coup si c'est un enfant (ou même n'importe quel individu) qui a généré l'aléatoire on a d'avantage de chance de pouvoir le compresser (car quelque soit le nombre de main il y aura une certaine continuité ou régularité).
Faudrait faire un tableau des chaines de  Markov
Le pourcentage de chaque digit dans le nombre.
Le pourcentage de chaque digit dans le nombre en fonction du digit précèdent.
Et éventuellement d'autre quantités.

Si on admet une manière "quantique" d'enregistrer de l'information un seul bit appelé Q-bit dans deux états en même temps :



On peut chercher une fonction qui à un nombre associe deux nombres plus petits voir trois si on a de la lumière qui vient par le haut (sur l'image). Et donc avec un couple (x;y;z) je pense qu'on peut minimiser le nombre de caractères.

Et pourquoi ne pas essayer avec les congruences ? (Maintenant que je fait spé maths vous pouvez en parler )

Je ne fais que donner des idées, par contre si qq'un connais bien les langages de programmation j'aimerai bien voir ce que ma méthode avec la factorisation en nombre premier donne. Parce que à la main....c'est trop dur et surtout trop long !