Bonjour,
Sous Calc la formule ent(n*(log(3)/log(2))) renvoie la valeur entière de la fraction mais cette valeur est exacte jusqu'à n égal combien ? Cela dépend à mon avis de l'approximation faite par le logiciel de log(3)/log(2)?
En fonction du n exacte possible par calc j'aurais peut-être une question maths qui me pose problème.
Sans questions il n'y a que des problèmes sans réponses.
bonsoir
calc calcule en 64bits flottants.
JR
l'électronique c'est pas du vaudou!
Cela veut dire qu'il va jusqu'à 64 chiffres après la virgule?
Sans questions il n'y a que des problèmes sans réponses.
Non parce qu'il faut plus qu'un bit pour représenter un chiffre en base 10 et que certains des 64 bits servent à représenter l'exposant.Envoyé par Liet Kynes
C'est 15 à 17 chiffres significatifs.
re
non !
voir là :https://www.google.com/url?sa=t&sour...NrmwE-8MEUviCa
JR
l'électronique c'est pas du vaudou!
Bonsoir,
Je me pose la même question quand je travaille avec les outils que je me suis créés, en écrivant leur code dans le langage que j'utilise.Cela dépend à mon avis de l'approximation
Je fais les déclarations de variables en flottant 64 bits quand je veux de la précision.... mais mon doute subsiste sur l'approximation qui résulte de l'algorithme utilisé par ce langage pour calculer le Log, (qui n'est pas indiqué) en me disant que cet algorithme peut être différent d'un outil à l'autre. Ou je me trompe?
J'ai déjà posé sur FS la question de l'algorithme utilisé pour le log dans Excel par exemple, ou dans tel langage. Mais je n'ai pas eu de réponse.
Les algos peuvent être différents mais en général on utilise des grands classiques genre Cordic et il n'y a pas de grande différence dans les résultats.
Quand on a besoin de plus de précision ou de la connaître exactement on utilise des outils spécialisés mais il n'y pas tant de cas où c'est vraiment nécessaire.
9 chiffres significatifs c'est déjà milles tonnes au gramme près et pas mal de calculs "physiques" peuvent être faits avec 6 ou 7 chiffres significatifs.
C'est pas simple, du coup, je peux calculer ent(n*(log(3)/log(2))) jusqu'à un nombre très grand nombre pour n ? La plage de calcul sous calc va jusqu'à 1048576
Sans questions il n'y a que des problèmes sans réponses.
Dans ton cas, cela devrait aller jusqu'à 10ˆ15 pour n.
Ok merci! du coup je peux poser ma question maths, pas le temps ce soir, cela concerne la formule qui donne la puissance de 2 (que je note m) immédiatement supérieure à 3^n, je trouve une relation intéressante en calculant 2m+n modulo 13 qui simplifierait peut-être le temps de calcul.. je développe la suite dès que possible..
Sans questions il n'y a que des problèmes sans réponses.
Re
là tu m’étonnes tu as du faire une bêtise.
car pour n = 123 456 789 on récupère 195 674 381.
JR
l'électronique c'est pas du vaudou!
Bonsoir,
J'y voulu m'y essayer, mais en précisant que je n'ai peut être rien compris à l'exercice (C'était juste pour essayer mon bidule)car pour n = 123 456 789 on récupère 195 674 381.
pour n = 123 456 789 je récupère bien 195 674 381.
et j'ai voulu aller plus loin pour n, par exemple:
pour n = 150 000 001 je récupère 237 744 376
Dernière modification par SULREN ; 30/03/2024 à 23h23. Motif: correction erreur frappe
Le truc est de se dire que la partie entière dépend du résultat de l'addition est que ce résultat est juste jusqu'à un certain point en fonction du nombre de décimales que l'on utilise.;je n'ai pas bien compris le truc de la virgule flottante mais dans l'idée il ne me semble pas possible d'un point de vue informatique d'avoir un tableur non approximatif. Quand on utilise une approximation à la dixième décimale le nombre n est déjà très grand pour que cette décimale puisse participer à l'incrémentation de la partie entière.
Ce que j'ai trouvé c'est que pour la formule qui donne la puissance de(que je note
On a
Sans questions il n'y a que des problèmes sans réponses.
Il n'est pas possible d'un point de vue physique d'avoir des calculs non approximatifs.
Bonsoir Liet Kynes.
Sachant qu'il n'y a que 13 valeurs possibles modulo 13 (de 0 à 12), tu vas retrouver des répétitions momentanées qui ne disent rien.
Pour ceux qui voudraient voir, voici les 300 premières valeurs de 2m+n (au fait LK, pas besoin de parenthèses autour de 2m, on apprend ça à 11 ans) :
5, 10, 0, 5, 8, 0, 5, 8, 0, 3, 8, 0, 3, 8, 11, 3, 6, 11, 3, 6, 11, 1,
6, 11, 1, 6, 9, 1, 4, 9, 1, 4, 9, 12, 4, 9, 12, 4, 7, 12, 2, 7,
12, 2, 7, 10, 2, 7, 10, 2, 5, 10, 2, 5, 10, 0, 5, 8, 0, 5, 8, 0,
3, 8, 0, 3, 8, 11, 3, 6, 11, 3, 6, 11, 1, 6, 11, 1, 6, 9, 1, 4, 9,
1, 4, 9, 12, 4, 9, 12, 4, 7, 12, 2, 7, 12, 2, 7, 10, 2, 7, 10, 2,
5, 10, 2, 5, 10, 0, 5, 8, 0, 5, 8, 0, 3, 8, 0, 3, 8, 11, 3, 6, 11,
3, 6, 11, 1, 6, 11, 1, 6, 9, 1, 4, 9, 1, 4, 9, 12, 4, 9, 12, 4, 7,
12, 2, 7, 12, 2, 7, 10, 2, 7, 10, 2, 5, 10, 2, 5, 10, 0, 5, 8, 0,
5, 8, 0, 3, 8, 0, 3, 8, 11, 3, 6, 11, 3, 6, 11, 1, 6, 11, 1, 6, 9,
1, 4, 9, 1, 4, 9, 12, 4, 9, 12, 4, 7, 12, 2, 7, 12, 2, 7, 10, 2,
7, 10, 2, 5, 10, 2, 5, 10, 0, 5, 8, 0, 5, 8, 0, 3, 8, 0, 3, 8, 11,
3, 6, 11, 3, 6, 11, 1, 6, 11, 1, 6, 9, 1, 4, 9, 1, 4, 9, 12, 4, 9,
12, 4, 7, 12, 2, 7, 12, 2, 7, 10, 2, 7, 10, 2, 5, 10, 2, 5, 10, 0,
5, 8, 0, 5, 8, 0, 3, 8, 0, 3, 8, 11, 3, 6, 11, 3, 6, 11, 1, 6, 11,
1, 6, 9, 1, 4, 9, 1, 4, 9, 12, 4
Dernière modification par gg0 ; 31/03/2024 à 19h59.
Oui c'est vrai que l'on oublie trop souvent que derrière l'informatique il y a la physique et je pense ne pas dire une grosse idiotie en disant que notre propre cerveau est aussi limité par cette ces lois.
L'idée est que l'on peut éventuellement optimiser nos résultats, gagner en temps et en énergie mais aussi en puissance (aller plus loin), c'est l'intuition que je cherche à vérifier par rapport à ce que j'ai obtenu comme relation avec mon tableur: c'est certainement très bête mais je ne situe pas bien la liaison.
Je mets un fichier en PJ pour illustrer la nature de ces "récurrences "mais c'est un poil compliqué..
mod13.ods
Sans questions il n'y a que des problèmes sans réponses.
Il y a croisement désolé pour ma dernière réponse qui s'adressait à PM42.
En fait une fois que tu as les valeurs des restes , tu tries les résultats et c'est là que tu as des valeurs relativement récurrentes.. voir les colonnes en rouge dans ce que j'ai envoyé. Attention ,il y a de façon régulière une rupture avec le nombre 84.
Sans questions il n'y a que des problèmes sans réponses.
Si tu étais sérieux, tu formaliserais ce que tu veux expliquer. C'est bien joli de faire joujou avec un tableur, mais si tu savais ce que tu y fais, tu serais capable de l'expliquer.
Mais je doute fortement, puisque tu as dit " tu tries les résultats", ce qui fait perdre tout lien mathématique.
À priori, aucun intérêt !
Bonsoir,
J'espère ne pas déranger la discussion. Si c'est le cas veuillez m'en excuser, et ne me répondez pas .
Je me suis intéressé à ce problème, comme toujours pour essayer d'apprendre et j'espère déjà avoir bien compris l'énoncé.
(Et je m'y suis mis ce soir pour me changer du travail de la journée: tronçonner un gros arbre mort)
J'ai fait varier n de 1 jusqu'à 7000 et j'ai trouvé les m correspondant à chaque valeur de n. J'en donne juste quelques valeurs jalons.
n= 500 m=793
n=1000 m=1585
n=2000 m=3170
n=5000 m=7925
n=7000 m=11095
L'un de vous peut il voir la gentillesse de me dire si mes m sont justes, ou complètement bidons.
S'il sont bons j'essaierai de voir jusqu'où je peux aller avec n sans que les problèmes de précision deviennent rédhibitoires.
Oui, ces valeurs sont bonnes (si c'est bien m=E(1+n ln(2)/ln(3))=E(1+n log(2)/log(3)) - ln log népérien, log logarithme décimal). Mais comme une simple calculette permet de les trouver, je suis surpris que tu poses la question. D'autres valeurs
n = 10 000 m = 15850
n = 100 000 m = 158497
n = 1 000 000 m = 1584963
à rapprocher de ln(2)/ln(3) =(env) 1,584962501 où l'arrondi est fait sur le dernier chiffre significatif, le 1. D'où :
n= 10 000 000 m = E(1+10 000 000*1,584962501) = E(1+15 849 625,01) = E(15 849 626,01)=15 849 626
Le calcul est exact car l'erreur d'arrondi sur la valeur approchée n'intervient pas.
Une simple calculette scientifique travaille avec 10 chiffres significatifs (au moins) à l'affichage (et 13 en interne), donc permet de trouver m pour n = 100 millions.
Cordialement.
C'est pas facile de formaliser, si je savais le faire correctement je ne poserai pas de questions.
Je considère les nombres congrus entre eux et dans chaque groupe j'effectue la différence des valeurs de m entre le premier terme et le cinquième idem pour n, j'obtiens pour m 84 constamment sur environs 300 termes successifs puis une série d'environs 30 termes qui alternent avec de valeurs de 20 et 79. Pour n j'obtiens 53 constamment sur environs 300 termes successifs puis une série d'environs 30 termes qui alternent avec de valeurs de 12 et 50
J'en tire deux formules :
Sans questions il n'y a que des problèmes sans réponses.
Aucun intérêt ! Comme c'est basé sur les parties entières qui dépendent des décimales de ln(3)/ln(2), ce qui se passe à un moment va disparaître ensuite puisque on va utiliser de plus en plus de décimales.
Tu te fais piéger au paradoxe du traitement des données : Plus on accumule de données, plus on fait apparaître de régularités qui ne sont produites que par le traitement des données.
Merci, c'est bien cela qui me faisait poser la question, de savoir si ce nombre décimal avait les décimales si bien organisées.
Sans questions il n'y a que des problèmes sans réponses.
À priori, rien d'organisé, il suffit de le calculer pour voir pour les premières. On démontre qu'il n'est pas rationnel, il est à priori aussi transcendant.
Bonjour,
@Liet Kynes :
Navré d’intervenir dans ta discussion. Je vais juste répondre au message que m’a adressé @gg0 et je n’interviendrai plus.
@gg0 :
Merci de m’avoir répondu. Je comprends que ma question ait pu te surprendre, mais je t’assure qu’elle n’avait pas pour objet de faire du buzz. J’ai mieux à faire et surtout j’ai le devoir de ne pas faire perdre du temps aux autres.
Je m’intéresse à ce genre de discussions, car cela me permet de garder l’esprit alerte en maths et de m’assurer que je ne fais pas d’erreur de raisonnement quand je conçois, et quand j’utilise, les outils dont j’ai besoin pour les calculs qui se posent à moi dans l’exercice de mes passions.
Quand j’ai vu le problème posé par @Liet Kynes
« n et m étant des entiers positifs, pour tout n, trouver le plus petit m tel que Exp(m) > Exp(n) »
Je me suis empressé d’ouvrir un outil que je me suis créé il y a 20 ans pour des problèmes de calcul de trains d’engrenages, et qui sait manipuler 8 variables logiques pour aboutir à un résultat fixé.
Je lui ai posé le problème Exp(m) > Exp(n) et :
« vas-y Jeannot, sors moi tous les couples {n,m} pour n allant de 1 à 10 000 ».
Et là, surprise : à n = 646 il m’a envoyé balader avec le message « infinity" (donc dépassement, alors qu’il travaille en flottant 64 bits).
Et j’en ai conclu:
« Sulren, tu es un naze, car tu sais très bien qu’avec Exp on grimpe très vite et ce n’est pas pour rien que @Liet Kynes est passé en log.
Fais donc désormais très attention à ce problème dans tes applications, hein: ».
J’ai reposé à mon outil le problème en log et là il m’a fait défiler sur l'écran tous les couples {n ;m} même pour des n très grands.
Mais je suis revenu au doute exprimé dès le début pas @Liet Kynes :
« Sous Calc la formule ent(n*(log(3)/log(2))) renvoie la valeur entière de la fraction mais cette valeur est exacte jusqu'à n égal combien ? »
OK pour oublier le risque de la limitation du 64 bits, mais restait l’approximation de l’algorithme du log de mon outil (qui date de Mathusalem avec son Cordic ou autre) et j’ai donc voulu le comparer aux résultats trouvés par les autres membres.
Il donne bien comme toi : m=15 849 626 pour n=10 000 000
Merci beaucoup.
Cordialement.
Re-bonjour,
@Liet Kynes:
Je reviens dans la discussion malgré mon engagement précédent, mais parce que cela cadre avec une question que tu avais posée, concernant les récurrences: 2*m+n =x Mod13.
Je n'en avais pas bien compris l'intérêt précédemment, mais j'ai voulu approfondir et j'ai demandé à mon outil de les identifier.
On en voit apparaître, durer un certain temps, puis se modifier légèrement, etc.
Exemples:
Pour n allant de 1 à 100:
On voit la bébête-: 1 4 5 8 9 12 se répéter plusieurs fois, puis disparaître.
Pour n allant de 400 à 512:
On voit une-------: 1 2 5 6 9 12 se répéter puis disparaître.
Pour n allant de 515 à 616:
On voit la---------: 1 2 5 8 9 12
Et pour n à partir de 623
On voit revenir-- : 1 4 5 8 9 12
Je ne sais pas ce que tu as fais comme calcul mais en fait si tu calcules l'écart entre deux valeurs de m dans 2^m pour n et n+1, tu trouveras toujours 2 ou 1, en manipulant les données on tombe parfois fortuitement sur de longues séries de 2 ou de 1 ou d'alternances redondantes mais il s'agit du paradoxe expliqué par gg0 qui s'explique par la nature irrationnelle du nombre log(3)/log(2).
Sans questions il n'y a que des problèmes sans réponses.
Bonsoir,
@Liet Kynes
Oh milles excuses à vous tous.Je ne sais pas ce que tu as fais comme calcul
Je vois que j'avais fait une faute de frappe dans le code et que toutes les valeurs de modulo que j'ai indiquées dans mon message sont fausses.
Je souhaite qu'un modérateur supprime ce message. Merci.
Comme je l'ai dit, j'ai utilisé un outil de mon cru qui existait, mais qui ne contenait pas ce calcul de modulo. J'ai donc ajouté un bout de code mais je me suis planté. J'aurais dû le relire.
Dans le fichier format ".txt" ci-joint, en espérant qu'il passe en pièce jointe, je donne les valeurs pour n allant de 1 à 1000.
- Dans la colonne qui correspond à R7 les valeurs de n de 1 à 1000 (3eme colonne en partant de la droite)
- Dans la colonne qui correspond à R8 les valeurs correspondantes pour m (2eme colonne en partant de la droite)
- Dans la colonne MOD le valeur de 2*m+n Module13 (colonne de droite)
Je pourrais donner ce fichier pour bien plus de valeurs de n.
Ce fichier a une tronche qui va vous paraître bizarre, mais c'est parce que c'est un des outils que j'ai créé pour mes calculs sur des trains de roues dentées.
J'ai utilisé la roue dentée n°7 pour le "n" de notre discussion.
Et la colonne MOD est la bidouille que j'ai ajoutée pour la circonstance, en remplacement d'autre chose que j'ai supprimé.....et en faisant une erreur de formule.
Je paie la tournée générale pour me faire pardonner!
Bonjour,
Le plus simple est de faire un signalement du message en question (en cliquant sur le petit triangle en bas à gauche du message) et d'indiquer que vous demandez sa suppression (ainsi que le motif).
Là, je ne sais pas de quel message vous parlez.
Not only is it not right, it's not even wrong!
Cela doît être le message 26, SULREN utilise un code qui doît être basé sur l'arithmétique modulaire pour des calculs d'engrenages et donc rien d'étonnant à ce qu'il soit utilisable pour ce problème.
Sans questions il n'y a que des problèmes sans réponses.
