Avec algobox ou sans ...

[chan79]

Trouver 3 nombres entiers positifs a, b et c tels que

[Kikoo <3 Bieber]

Salut,

Je trouve un unique couple (1/17; 2/(3-V5); 2/(3+V5))...

[Dlzlogic]

Trouver 3 nombres entiers positifs a, b et c tels que

Bof, y'a pas mal de solutions, j'ai pas algobox, je sais pas si j'ai le droit en C ?
Rectification, sauf erreur, il n'y a que 4 solutions indépendantes.

[Kikoo <3 Bieber]

J'avais dit n'importe quoi tout à l'heure.

Mais après avoir revu le problème, je ne trouve pas de solution pour une variable :/

[chan79]

Bof, y'a pas mal de solutions, j'ai pas algobox, je sais pas si j'ai le droit en C ?
Rectification, sauf erreur, il n'y a que 4 solutions indépendantes.

Salut
J'ai aussi plusieurs solutions mais je suis incapable de dire combien il y en a.
Je ne connais pas le langage C (malheureusement ) mais tu fais comme tu veux, bien-sûr :zen:

[Dlzlogic]

Donc, j'ai gagné, je peux donner la réponse ?
Ce qui m'intéresserait, c'est trouver une solution mathématique, parce qu'avec un programme c'est trop facile.
Par contre, je n'arrive pas à montrer qu'il n'y en a que 4.
Oups! j'en ai trouvé deux de plus.
... j'en suis déjà à 18, je continue ?

[chan79]

Donc, j'ai gagné, je peux donner la réponse ?
Ce qui m'intéresserait, c'est trouver une solution mathématique, parce qu'avec un programme c'est trop facile.
Par contre, je n'arrive pas à montrer qu'il n'y en a que 4.
Oups! j'en ai trouvé deux de plus.
... j'en suis déjà à 18, je continue ?

Si ça se trouve, quelqu'un va nous prouver qu'il y a une infinité de solutions
j'ai trouvé en premier(6,17,102)
ce qui est sûr, c'est qu'au moins un des trois nombres doit être divisible par 17

[Dlzlogic]

Si ça se trouve, quelqu'un va nous prouver qu'il y a une infinité de solutions
j'ai trouvé en premier(6,17,102)
ce qui est sûr, c'est qu'au moins un des trois nombres doit être divisible par 17

Je suis sûr qu'il y en a un nombre infini, mais c'est un infini plus petit que le nombre des entiers, et encore plus petit que le nombre des réels.
Voir le sujet "infini" où je démontre (presque) que les infinis ont une structure de corps. :mur:
(Je pense qu'on me pardonnera cette généralisation intellectuelle) :hum:

[chan79]

Je suis sûr qu'il y en a un nombre infini, mais c'est un infini plus petit que le nombre des entiers, et encore plus petit que le nombre des réels.

Le plus petit cardinal infini est bien celui de l'ensemble des entiers naturels ?

[Dlzlogic]

Le plus petit cardinal infini est bien celui de l'ensemble des entiers naturels ?

Depuis la dernière discussion sur l'infini, je ne suis plus sûr de rien. Quand j'ai fait mes études, on savait ce que voulait dire "tendre vers l'infini". Maintenant on sait établir une relation d'ordre entre les différents infinis. Il me semble tout de même qu'il y a moins d'éléments dans l'ensemble des carrés des entiers naturels que dans l'ensemble des entiers naturels eux-mêmes.
Mais comme j'ai dit plus haut, je ne plus sûr de rien. Les définitions changent, bref, je ne m'y retrouve plus.
Voir aussi la division d'un gâteau en un nombre infini de convives. Mais j'arrête, sinon je vais encore le faire appeler Troll.

[fatal_error]

slt

pour ma part, je n'en trouve que 4:
a = 5
b = 30
c = 510
===
a = 5
b = 34
c = 170
===
a = 6
b = 15
c = 510
===
a = 6
b = 17
c = 102

On peut supposer a=5
on réitère la minoration par la borne sup pour a fixé :
4/17-1/a <= 2/b
on déduit b<=E(34*a/(4*a-17))

et enfin on calcule c=(17*a*b)/(b*(4*a-17)-17*a)
il s'agit de conserver les valeurs de c entières telles que l'équation 4/17=1/a+1/b+1/c soit valide

code octave

Code: Tout sélectionner

 
for a=5:12
  for b=a:34*a/(4*a-17)
    c=(17*a*b)/(b*(4*a-17)-17*a);
    if c<0
      continue
    else
      if 4*a*b*floor(c)-17*(a*b+b*floor(c)+a*floor(c))==0
        a
        b
        c
        disp('===')
      end
    end
  end
end


note: l'exclusion sur c<0 m'intrigue, pourquoi ya t il des c<0??, mais chui un peu torché, alors je passe

[SaintAmand]

Il me semble tout de même qu'il y a moins d'éléments dans l'ensemble des carrés des entiers naturels que dans l'ensemble des entiers naturels eux-mêmes.

Non, il y en a autant. Regarde l'application . Elle est injective et son image est l'ensemble des carrés parfaits.

[chan79]

slt

pour ma part, je n'en trouve que 4:
a = 5
b = 30
c = 510
===
a = 5
b = 34
c = 170
===
a = 6
b = 15
c = 510
===
a = 6
b = 17
c = 102

On peut supposer a=5
on réitère la minoration par la borne sup pour a fixé :
4/17-1/a <= 2/b
on déduit b<=E(34*a/(4*a-17))

et enfin on calcule c=(17*a*b)/(b*(4*a-17)-17*a)
il s'agit de conserver les valeurs de c entières telles que l'équation 4/17=1/a+1/b+1/c soit valide

code octave

Code: Tout sélectionner

 
for a=5:12
  for b=a:34*a/(4*a-17)
    c=(17*a*b)/(b*(4*a-17)-17*a);
    if c<0
      continue
    else
      if 4*a*b*floor(c)-17*(a*b+b*floor(c)+a*floor(c))==0
        a
        b
        c
        disp('===')
      end
    end
  end
end


note: l'exclusion sur c<0 m'intrigue, pourquoi ya t il des c<0??, mais chui un peu torché, alors je passe

Ah oui, bien vu !
J'avais ces résultats, mais sans savoir s'il y avait d'autres possibilités ...
Si tu parviens à démontrer que, pour tout n supérieur ou égal à 2, on peut écrire 4/n au moins d'une façon sous la forme 1/a+1/b+1/c, tu auras démontré la conjecture d'Erdös-Straus !lien

[Dlzlogic]

Non, il y en a autant. Regarde l'application . Elle est injective et son image est l'ensemble des carrés parfaits.

Exact, d'ailleurs quand j'ai écrit mon message, j'avais un petit doute, mais ça m'amusait tellement cette relation d'ordre dans les infinis que j'ai oublié d'être rigoureux.

Pour le sujet lui même; voila le code qui produit le résultat suivant. Bien-sûr, ce n'est qu'une partie de l'infinité des résultats.

Code: Tout sélectionner

int main()
{
  for (int a=1; a< 10000; a++)
  {
    for (int b=a; b<10000; b++)
    {
      for (int c=b; c<10000; c++)
      {
        if (a*b*c*4 == (a*b+b*c+a*c)*17)
        {
          printf("trouvé : a=%d, b=%d, c=%d\n",a,b,c);
        }
      }
    }
  }
  system("pause");
  return 0;
}


trouvé : a=5, b=30, c=510
trouvé : a=5, b=34, c=170
trouvé : a=6, b=15, c=510
trouvé : a=6, b=17, c=102
trouvé : a=416, b=2816, c=7424
trouvé : a=427, b=1950, c=9142
trouvé : a=664, b=7032, c=9036
trouvé : a=672, b=5456, c=7968
trouvé : a=744, b=5032, c=9820
trouvé : a=776, b=5644, c=8392
trouvé : a=784, b=6640, c=8305
trouvé : a=1040, b=4848, c=6211
trouvé : a=1092, b=5748, c=7738
trouvé : a=1148, b=5812, c=6955
trouvé : a=1172, b=2676, c=3790
trouvé : a=1175, b=7106, c=8786
trouvé : a=1460, b=4404, c=6710
trouvé : a=1480, b=6863, c=9976
trouvé : a=1568, b=7840, c=8592
trouvé : a=1872, b=2096, c=7150
trouvé : a=2152, b=5146, c=9144
trouvé : a=2160, b=6504, c=9200
trouvé : a=2240, b=3136, c=8592
trouvé : a=2274, b=2956, c=4652
trouvé : a=2352, b=3664, c=4878
trouvé : a=2466, b=3541, c=4074
trouvé : a=2472, b=2480, c=2992
trouvé : a=2700, b=4968, c=6504
trouvé : a=2744, b=7288, c=7860
trouvé : a=2881, b=6166, c=9878
trouvé : a=2914, b=4200, c=7480
trouvé : a=2936, b=5116, c=7384

Bien sûr c'est pas fini.

Concernant le code octave, personnellement, je trouve bizarre de traiter des entiers avec des flottants, et dans tout les cas, la comparaison de flottants avec le signe "==" a, en gros, une chance sur 2 de donner le résultat attendu. La raison est que deux groupes d'octets sont égaux si tous les bits sont égaux. Or, s'il y a eu des opérations arithmétiques, il y a une chance sur deux que le dernier bit ne soit pas pareil, puisqu'il y a eu forcément un arrondi.
Peut-être floor(c+0.5) donnerait toujours l'entier le plus proche, mais j'en sais rien. Si je traite des entiers, je travaille avec des entiers.

[chan79]

Exact, d'ailleurs quand j'ai écrit mon message, j'avais un petit doute, mais ça m'amusait tellement cette relation d'ordre dans les infinis que j'ai oublié d'être rigoureux.

Pour le sujet lui même; voila le code qui produit le résultat suivant. Bien-sûr, ce n'est qu'une partie de l'infinité des résultats.

Code: Tout sélectionner

int main()
{
  for (int a=1; a< 10000; a++)
  {
    for (int b=a; b<10000; b++)
    {
      for (int c=b; c<10000; c++)
      {
        if (a*b*c*4 == (a*b+b*c+a*c)*17)
        {
          printf("trouvé : a=%d, b=%d, c=%d\n",a,b,c);
        }
      }
    }
  }
  system("pause");
  return 0;
}


Bien sûr c'est pas fini.

Concernant le code octave, personnellement, je trouve bizarre de traiter des entiers avec des flottants, et dans tout les cas, la comparaison de flottants avec le signe "==" a, en gros, une chance sur 2 de donner le résultat attendu. La raison est que deux groupes d'octets sont égaux si tous les bits sont égaux. Or, s'il y a eu des opérations arithmétiques, il y a une chance sur deux que le dernier bit ne soit pas pareil, puisqu'il y a eu forcément un arrondi.
Peut-être floor(c+0.5) donnerait toujours l'entier le plus proche, mais j'en sais rien. Si je traite des entiers, je travaille avec des entiers.

Salut
Sauf erreur, le triplet (416,2816,7424) ne semble pas convenir
1/416+1/2816+1/7424 ne fait pas 4/17 mais 12/4147
Peut-être que la machine ne peut plus comparer des nombres trop grands ?
Par ailleurs, comme 17(bc+ac+ab)=4abc et que 17 est premier, l'un au moins des trois nombres a, b et c doit être divisible par 17

[Dlzlogic]

Exact, je regarde ça.
J'ai rajouté le test de divisibilité par 17. Dans les limites de 1000, il n'en reste que 9.

trouvé : a=5, b=30, c=510
trouvé : a=5, b=34, c=170
trouvé : a=6, b=15, c=510
trouvé : a=6, b=17, c=102
trouvé : a=744, b=5032, c=9820
trouvé : a=776, b=5644, c=8392
trouvé : a=1175, b=7106, c=8786
trouvé : a=2472, b=2480, c=2992
trouvé : a=2914, b=4200, c=7480

Ma vérification avec une calculette n'a rien donné.
Je pense que on dépasse des capacités de la machine qui ne sait calculer que des entiers à 10 chiffres.
Donc, je n'en sais rien et à mon avis seule une démonstration mathématique qu'il n'existe que 4 solutions resterait convaincante.
On pourrait peut-être y arriver en montrant que la somme de la forme (ab + ac + bc) x 17 est plus petite que abc x 4 à partir d'un certain rang, donc l'égalité n'est plus possible.
En fait je crois que c'est vrai, et ça doit être possible à démontrer, maximisant l'un en en minimisant l'autre.
Dans tous les cas, la précision des int dépend de la machine, pour moi, c'est 32 bits.

[fatal_error]

Peut-être que la machine ne peut plus comparer des nombres trop grands ?

un int c'est 2^31-1.
On dépasse avec le produit.

Pour la question des flottants et entier, j'insiste pas, ca relève plus de la spéculation sur la connaissance d'octave.

edit:

Par ailleurs, comme 17(bc+ac+ab)=4abc et que 17 est premier, l'un au moins des trois nombres a, b et c doit être divisible par 17

tjs en supposant a a<=17*3/4
de fait, le multiple de 17 c'est b ou c (mais c'est juste une parenthèse)

[Dlzlogic]

tjs en supposant a a<=17*3/4
de fait, le multiple de 17 c'est b ou c (mais c'est juste une parenthèse)

Là je suis d'accord.

[C.Ret]

Je ne veux pas être méchant, mais je pense qu'il faut revoir l'algorithme de recherche ou alors changer de compilateur ou de calculette, car les diffèrence sont toutes de l'ordre de 10^11 !

Les erreur d'arrondi ou la précision limité de nos calculettes, posckets et autres ordinateurs est une chose connue depuis fort longtemps. Il faut donc veiller à convenablement utiliser les tests pour ne pas élimier ou au contraire laisser passer des solutions qui n'en sont pas.

Dans les solutions proposée ci-dessus, j'ai utilisé mon SHARP PC-1211 de 1981 pour vérifier si les triplets {a,b,c} sont solution de
Pour cela, je calcule pour chaque triplet les deux menbres de l'égalité On obtient pour les derniers triplets des nombe entiers important, mais pas au point de créer des erreur d'arrondi (même sur mon équipement numérique personnel qui fête ses 31 ans de fonctionnement !). J'imagine que sur Excel ou sur les logiciels de vos Smart- et i-Phone ou portable 64bits il en est de même. Enfin il faut espérer, car un SHARP PC-1211 n'a qu'un dual chore (deux microprocesseurs couplé) de 4bits et pas de multi-threat (ni même d'IRQ en fait).

Code: Tout sélectionner

   a    b    c  17(ab+ac+bc)          4abc      DIFF
   5   30  510        306000        306000  0,00E+00   OK
   5   34  170        115600        115600  0,00E+00   OK
   6   15  510        183600        183600  0,00E+00   OK
   6   17  102         41616         41616  0,00E+00   OK
 744 5032 9820    1027890176  147056778240 -1,46E+11
 776 5644 8392     990358528  147019246592 -1,46E+11
1175 7106 8786    1378809072  293436585200 -2,92E+11
2472 2480 2992     356098048   73370542080 -7,30E+10
2914 4200 7480    1112675840  366184896000 -3,65E+11


Conclusion.
Seules les 4 premiers triplets sont solutions.
Et cela me parait logique car le plus petit des trois entiers ne peut être supérieur à 3*17/4.

[Dlzlogic]

Tout à fait d'accord.
Je ne vais certainement pas essayer de me justifier sur ce type d'exercice. J'ai fait un bout de code, mais à l'évidence, j'ai pas réfléchi plus loin que le bout de mon nez.
J'ai laissé les 4 dernières lignes pour montrer que je m'était effectivement remis en cause.
Pour être tout à fait franc, type d'exercice ne me branche pas vraiment, j'ai répondu il y a 10 jours, dans l'esprit "il vaut mieux participer".

Concernant le nombre de chiffres significatifs, il est vrai que le type double donne 15 chiffres et le type long double donne 19 chiffres, alors que le type unsigned long n'en donne que 10.
Cordialement.