Bon Dimanche,

Je tente une réponse pour voir si j'ai bien compris....

d=6  et  n=42 --->13+14+15--->181440
181440 /6x6x6 =840

Non
J'ai gardé le meilleur résultat de p(42) de l'exercice précédent...
Ici ce serait 2730/216 =12.64

Si j'ai bon donne moi un d et un  n ..pour tester mon outil

Pour (d,n)=(6,42), c'est bon.
Tu peux essayer par exemple (d,n)=(5,76)  ou (d,n)=(5,80)

A la fin, l'objectif, c'est de trouver une méthode plus ou moins automatique, sans trop de tâtonnements, pour trouver avec des données comme (d,n)=(100,10000)  ou (d,n)=(4000, 100000)

Je te réponds:

(d,n)  (5,76)     251.597
            (5,80)     355.462

Pour d>10   cela devient astronomique...

je donne un exemple encore dans les clous:
(8,2002)    1 654 616 668 781 ,37

Pour (5,76) ou (5,80), on est d'accord.

Pour (8,2002), ça nous emmène effectivement vers des nombres astronomiques, mais beaucoup plus grands que ce que tu donnes. Je ne sais pas quelle série de nombres tu as trouvée, mais ça ne colle pas.

Et avec des nombres comme (d,n)=(80,2002)  ou (d,n)=(4000, 100000) comme dans mon message précédent, on obtient des résultats tout à fait raisonnables, faciles à manipuler.

Effectivement (80,2002) est plus raisonnable--->98,616

pour d = 8 j'avais stoppé ma recherche à  i 12
en allant jusqu'à i20   on arrive à   7 371 379 921 492 070
je stoppe là....

Cela veut dire qu'il faut un d/n "raisonnable"

C'est effectivement le rapport d/n ou plutôt n/d qui permet de savoir si on va atteindre des nombres astronomiques, ou pas.
Pou(80,2002), on arrive à un nombre raisonnable, certes, mais beaucoup plus grand que ce 98.616.

Pour (16,80), on a n/d=5 et un résultat de 355.
Pour (80,2002), n/d vaut 25, et donc,ce serait surprenant d'obtenir seulement 98.616

Essaie peut-être avec des nombres plus petits
(d,n)=(7,50)
(d,n)=(9,75)
(d,n)=(10,90)

Là, je fais grandir d petit à petit, et n/d grandit aussi.  Normalement, le résultat obtenu devrait augmenter à peu près régulièrement ...

Pour (80,2002 ) avec  198+199+ 200 +202+ 203 soit  i5
on obtient bien  98.616
on part de  i=2--->39.219
à     i=  13--->0.61  ensuite autour de 0
98.616 est le maximum  .

(7,50)     meilleur score      15+17+18--->13.382    
(9,75)        24+25+26--->21.399
(10,90)     29+30+31---->26.97
Mon bidule à l'air de fonctionner......

Pour les 3 derniers, c'est bon.
Pour (80,2002), la bonne réponse donne un nombre proche de 10000.

J'avais un petit bug....

(80,2002) --->=218+219+220+221+222+224+225+226+227

soit   1 332 396 153 298 510 000 000
Et 80 ^9 = 134 217 728 000 000 000
--->9 927,125

Oui, c'est bon.
Donc pour (80, 2002), la solution comporte 9 nombres de 218 à 227, 223 est exclu.

Sans faire les calculs, combien faudra-t-il de nombres pour (80,4004) ?

Ou pour (105, 8000) ?
Ou pour (334, 2800000) ?
Ou pour (876, 999000) ?   Pour celui-ci, je ne sais pas... j'hésite entre 2 réponses. Et j'aurais besoin de calculs précis pour trancher.

Bonsoir ty59847

J'ai utilisé le fait que la liste doit être extraite à partir de k+1 entiers successifs et ton indice sur le nombre k d'entiers (oui j'ai compris cette fois )

Si je ne me suis pas loupée :
4004=213+215+216+217+218+219+220+221+222+223+224+225+226+227+228+229+230+231 pour un produit de 98211006
8000=272+273+274+275+276+277+278+279+280+281+282+283+284+285+286+287+288+289+290+291+292+293+295+296+297+298+299+300 pour un produit de 1470868955612

Pour 999000, il me semble qu'il vaut mieux prendre la somme de 416 entiers pour un produit de 9.288134524856235e+181 (c'est beaucoup)

Tu vas plus loin que la question posée. On voulait (dans un premier temps) uniquement le nombre d'entiers utilisés.
Pour (80,4004) et (105,8000), je suis d'accord.
Pour (876,999000), j'hésitais entre 419 et 420 nombres, mais effectivement, avec les calculs précis, on obtient mieux avec 416 nombres.

Ca me perturbe un peu. Je savais qu'il y avait quelques effets de bord avec mon calcul approximatif, mais je ne pensais pas avoir de problème ici. Et surtout, je ne pensais pas que ces effets de bord créeraient un écart de 3 points.

Si ça peut te consoler, j'avais commencé par répondre 419 avant de me dire : "vérifions quand même que l'approximation ne nous met pas dedans" donc j'ai eu la même réaction que toi

On a donc bien la même démarche.
Et si on n'avait pas la contrainte que tous les doivent être différents 2 à 2, on aurait bien besoin de 420 nombres pour atteindre le maximum. 180 fois le nombre 2378 et 240 fois le nombre 2379.

Bonjour,

Pour (80,2004) je trouve comme vous  98 211 006.301

L'important c'est d'avoir compris le principe

On constate que le nombre de i   candidats augmente avec la racine carrée de n
ou quelque chose comme ça...

Sur les jeux de tests que j'ai proposés, ça peut donner cette impression, mais c'est parce que je faisais augmenter n 2 fois plus vite que d.

Dans les faits, c'est vraiment le rapport n/d qui pilote pratiquement tout.

Pour continuer, enlevons la contrainte que les doivent tous être différents 2 à 2. Je l'avais mise pour se rapprocher de l'autre sujet ... mais 'pédagogiquement', elle crée des difficultés.
Parce qu'il y a une histoire derrière cet exercice... il y a une chute qui est quand même assez intéressante.
Donc, sans la contrainte d'avoir les différents 2 à 2, comment trouver la bonne décomposition ?

Je laisse dpi chercher car je sais où tu veux en venir

 Cliquez pour afficher

En gros on va prendre fois la valeur de sorte que c'est à dire .
On veut maximiser en fonction de
On dérive

Cette dérivée s'annule en c'est à dire qui maximise donc la fonction

J'avoue avoir eu la flemme de faire le calcul proprement avec des entiers qu'ils soient distincts ou non.
Utiliser l'approximation et regarder ce qui se passe pour des "valeurs de k suffisamment proches" est surement moins glorieux mais tout aussi efficace de mon point de vue comme c'est l'ordinateur qui l'a fait pour moi

Mon petit grain de sel
En partant des réponses de ty59847 et Vassillia, j'ai obtenu ceci:

Pour donné, avec .
De là,

Et le produit est donné par .

Peut-on trouver une meilleure approximation du k optimal en utilisant des factorielles?

J'en ai fait un petit programme pour tester tout ça Tous les calculs intermédiaires sont en nombres entiers donc on peut aller loin dans les calculs astronomiques :

 Cliquez pour afficher

# See subject at https://www.ilemaths.net/sujet-decomposition-judicieuse-n-2-876853.html


def solve(d, n):
    """Find the maximum of prod(a[k]/d) such that sum(a[k]) = n"""
    k, best = 1, None
    while True:
        # We decompose n in a sum of k+1 consecutive terms (from a to a+k) minus r = (a+i) for some i, 0 <= i < k.
        a = (2*(n+k-1) - k*(k+1))//(2*k)
        r = (k+1)*(2*a+k)//2 - n

        # product = math.factorial(a+k) // math.factorial(a-1) // r     # Not efficient because k << a
        product = 1
        for i in range(a, a+k+1):
            if i != r:
                product *= i

        if best is None or product >= best[0] * d ** (k - best[1]):
            best = (product, k, a, r)
        else:
            break

        k += 1

    return best


def main():
    print(f"{'d':>4} {'n':>6} {'k':>3} {'a':>5} {'r':>5} {'n/kd':>5} {'p/d^k':>13} {'p'}")
    for d, n in (
            (5, 39),
            (6, 42),
            (5, 76),
            (5, 80),
            (100, 10000),
            (4000, 100000),
            (8, 2002),
            (80, 2002),
            (16, 80),
            (7, 50),
            (9, 75),
            (10, 90),
            (80, 4004),
            (105, 8000),
            (876, 999000),
            # (334, 2800000),   # Cannot convert (p / d ** k) in float
    ):
        p, k, a, r = solve(d, n)
        # print(k, a, r, p)
        print(f"{d:4} {n:6} {k:3} {a:5} {r:5} {n / (k * d):.3f} {p / d ** k:<13e} {p}")


if __name__ == "__main__":
    main()

   d      n   k     a     r  n/kd         p/d^k p
   5     39   3    11    11 2.600 1.747200e+01  2184
   6     42   3    12    12 2.333 1.263889e+01  2730
   5     76   5    13    17 3.040 2.515968e+02  786240
   5     80   6    10    11 2.667 3.354624e+02  5241600
 100  10000  37   252   279 2.703 9.186944e+15  918694361686745172353655175480729146092033659149525654367929853163885669081363251200000000
4000 100000   9 11107 11115 2.778 9.846398e+03  2581174071589336141522205837121384960
   8   2002  52    12    12 4.812 2.900017e+33  264898764818080282202467359890157946868790242401163570641104109830144000000000000
  80   2002   9   218   223 2.781 9.927125e+03  1332396153298514304000
  16     80   2    39    40 2.500 6.246094e+00  1599
   7     50   3    15    16 2.381 1.338192e+01  4590
   9     75   3    23    23 2.778 2.139918e+01  15600
  10     90   3    28    28 3.000 2.697000e+01  26970
  80   4004  18   213   214 2.781 9.821101e+07  1769212205531184877706672675259658444800000
 105   8000  28   272   294 2.721 1.470869e+12  576599625174984276821665959852494827381771013959021244920627200000000
 876 999000 416  2193  2217 2.741 9.288135e+181 112108014961271105393106904436580814332049405882624787358657158421002082335708009085777218028260742364893743400720450450942952372390811988546786813224979289769041534206282134088139725076409778182140707039054107815062346302912227833527047148864014943566434526589263480560315438505795118604300004398367164555554435458326913578147812139664053706334606436095796954669682455387805993651341889169717404645385674860563570592172683382877882625662223320314289110267195662633302987669632498689888450696096077433963992136210347086892743353110146859004008281105571397145812713286332703037390064339070523321624765055779170320835881089283263677574137975256626321308946002793300420613214080089317379799079789148825012533840376103348163928606244222519140798510825195540281450641836285690807420010684629677796755735871580509592634275136101771042659564640215973996468298567073601036854227256761076690154649385976566725319466473785568937919732824332203257718816495940382569852477226791030316650872582100997416689519382610407574661435456595738790189476538839743121328702195101103126483561265747358947906155783462937372758195365607333907239174860010418403481741793244133694351885649534209051573316078584842585366033224373302701657590658305303916690889926820506875614722175506678934782210109915707213815142989030772596696678400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Le cas d=1 nous ramène exactement dans le sujet initial ( Décomposition judicieuse
Quand vaut , ou quand est très grand de manière générale, la série des devient la série de tous les entiers de à ... l'entier qui va bien, avec éventuellement un trou dans la série.

Moi, ça m'avait beaucoup amusé de voir apparaître dans cette énigme.
Des fois, des gens demandent pourquoi c'est qui a été choisi comme base 'universelle', et pas 10 ou autre chose. On a la réponse, une réponse de plus.

Bonsoir,

Mon niveau est trop modeste pour comprendre pourquoi  e
est entré dans cet exercice.
Pouvez-vous me donner une réponse  simpliste    ?

Qu'est-ce que tu ne comprends pas dans ma démonstration dpi ?
Elle est du niveau lycée, on fait juste une étude de fonction, un peu déstabilisante car il y a plusieurs paramètres mais uniquement l'un d'entre eux peut varier.

Sans surprise le code de LittleFox est plus joli que le mien mais globalement je faisais la même chose.
Je pense quand même gagner du temps de calcul en initialisant avec le bon ordre de grandeur.

Je viens de voir ln dans ta démo ,mon niveau a baissé depuis 1961

Pourquoi intervient ?  
Quand j'avais croisé (créé ?) cette énigme il y a longtemps, j'avais certainement trouvé l'explication. Mais samedi, quand j'ai lancé cette discussion, je n'ai pas du tout cherché à retrouver cette explication.

Comment intervient ?
Ca, c'est plus facile.
Par exemple pour les dernières données (d,n)=(876, 999000).
On commence par calculer 999000/876, on trouve 1140.4.
En fait, l'exercice devient : comment trouver une série de nombres dont la somme donne 1140.4, et dont le produit donne un résultat aussi grand que possibles.
Avec comme contrainte, c'est que les nombres utilisables sont à choisir parmi , , ...

Bien évidemment, dans notre série de nombre qu'on va choisir, on ne retiendra pas des nombres comme   ou . Dans la somme, ils bouffent un petit peu d'espace, et dans la multiplication demandée, ils sont contre-productifs. ils sont plus petits que 1, donc ils font diminuer le résultat de la multiplication.
Tous les nombres jusqu'à    sont contre productifs.

A partir de , les nombres participent un peu dans le calcul de la somme, et sont productifs de valeur ajoutée dans le calcul de la multiplication ( est un peu plus grand que 1).
Mais ils sont très peu productifs.

Il se trouve que les nombres qui sont les plus productifs, ce sont les nombres proches de .  C'est un constat factuel, et en plus, la démo de Vassilia le prouve.

C'est en choisissant plein de nombres proches de 2.718 que l'on obtient la meilleure rentabilité. La somme monte vite, certes, mais la multiplication monte très vite.

2 petits exemples :
: sommes égales
Mais est beaucoup plus grand que

: sommes égales
Mais est beaucoup plus grand que

Si on pouvait choisir une série de nombres quelconques (sans contrainte que les nombres soient différents 2 à 2), on ferait simplement ce calcul :
999000/876=1140.4
1140.4/2.718 = 419.53
Et du coup, la décomposition la plus efficace va contenir environ 419 nombres, tous proches de 2.718.
On essaie avec 419 nombres identiques, tous égaux à 999000/876/419 , et on essaie avec 420 nombres identiques,tous égaux à 999000/876/420 . Et on compare ces 2 résultats.
Et on a la solution.

Là, ça se complique sensiblement, on a en plus la contrainte de prendre des nombres parmi les , et différents 2 à 2.
Si on veut prendre 419 nombres centrés autour de 2.718 et espacés de 1/876, ça nous oblige à descendre à des nombres comme 2174/876, soit 2.48
Et 2.48, c'est loin de 2.718, on est dans une zone où les nombres sont peu productifs.
2.718, c'est là où les nombres sont les plus productifs.
2.718+0.25, c'est un peu moins productif que 2.718, mais ça va encore.
Par contre 2.718-0.25, ça n'est vraiment pas bon.
2.718 est le point le plus haut de la courbe 'productivité', mais la courbe n'est pas du tout symétrique.
Si on doit ratisser large, si on doit prendre un intervalle large autour de 2.718, alors, pour éviter les nombres comme 2.5, on doit choisir une zone centrée autour de 2.73 ou 2.74, et non autour de 2.718.

>ty59847  
Voici une démonstration matérialiste qui me convient
Il faut reconnaitre que Littlefox  avec son programme et Vassilia avec
sa démo sont très forts.
Une autre fois ce sera qui se rappellera à notre bon souvenir....