Recopie d'un nombre de lignes espacées

Salut GT,

Ouais, bon, je me suis enthousiasmé un peu vite avec ton calculateur... Matheux comme je suis, je ne trouve pas les infos qu'il me faudrait...

Exemple pour un RANG Col.3 Val hte. 3 - Col. 2 Val hte. 5 (je ne me fais pas à tes Kn...)
- combi. 3/3 H2SO4 = 15 lignes ;
- combi. 2/5 H2SO4 = 6 lignes ;
- lors du tri, la macro doit trouver 11 lignes pauvres et 4 riches à dupliquer ;
- 11 + ( 4 * 6 ) = 35 lignes totales ;
- j'ai bien 35 lignes mais ton calculateur me donne 50 ;

Autre chose, en fait, j'ai besoin d'avoir dans le calculateur et, dès le 1er ordre, le nbre. de lignes pauvres et riches je vais rencontrer (ici dans un seul bloc puisque c'est le premier ordre) en fonction de l'ordre suivant !!
Je ne retrouve aucun de ces deux nombres dans ton calculateur et ne trouve pas comment associer les autres pour trouver cela.
L'idée est de pouvoir calculer, en début de boucle, la place qui sera nécessaire dans les tMIN (pauvres) et tMAX ( x riches X nb. lignes combi suivante) afin de ne lire l'instruction REDIM PRESERVE qu'UNE seule fois plutôt qu'à chaque test IF.

Tu peux me faire ça ?

EDIT : après un test sur le RANG K3n3 - K3n6 - K3n3 - K3n6, un gain de 50%, de +-13" à 6"5 pour 396.033 lignes générées !!
Il me faut absolument ces formules me permettant de calculer facilement l'espace mémoire à allouer à tMIN() et tMAX() !

A+

Salut Curulis57,

Super pour le nettoyage de la terrasse !

Je suis désolé j'ai été super débordé ces derniers temps et encore là je dois réaliser le déménagement de ma belle-soeur dans 30 min... Je ne serai quitte que tard le soir puisqu'ensuite vient les problématiques de la tapisserie de l'appartement que je dois rendre :(

Exemple pour un RANG Col.3 Val hte. 3 - Col. 2 Val hte. 5 (je ne me fais pas à tes Kn...)

- combi. 3/3 H2SO4 = 15 lignes (yes : 1 + (3-1)¹ + (3-1)² + (3-1)³ = 15 dont 8 défaites (soit 15-8 = 7 victoires) ;

- combi. 2/5 H2SO4 = 6 lignes ; ==> impossible on trouve 21 combinaisons. (Si tu parles de K=5 N=2 on a bien (1 + (5-1)¹ + (5-1)²) = 21 dont 16 défaites (soit 21-16 = 5 victoires)

- lors du tri, la macro doit trouver 11 lignes pauvres et 4 riches à dupliquer ==> ? Attention, il y a 8 défaites et 7 victoires à l'ordre 1. Il y a donc 8 lignes pauvres et 7-1 = 6 lignes à dupliquer.

- 11 + ( 4 * 6 ) = 35 lignes totales ; ==> En reprenant les calculs ça donne : les 8 lignes pauvres avortées de l'ordre 1 + les 7 x 21 lignes qui sont poursuivies à l'ordre 2, soit au total 8 + 147 = 155 combinaisons.

- j'ai bien 35 lignes mais ton calculateur me donne 50 ; ==> Le calculateur donne bien 155 combinaisons dans ce cas-là ;)

Je vois si j'arrive à avoir le temps de répondre à la suite mais le calculateur est bon ;)

Salut GT,

je vois que chacun a ses petits plaisirs : que du bonheur !

Déso, je me suis embrouillé moi-même avec tes Kn : il faut bien lire 5 colonnes et valeur haute 2 (puisque je n'ai pas d'autres combi préenregistrées!).

Donc, nous allons d'abord nous créer un petit lexique (il est temps, on arrive au bout...) :
- le RANG : le tableau contenant jusqu'à...
- 10 ORDRES (x), décrivant chacun ...
- la COMBI (x). H2SO4 en cours de traitement ;
- pour faire simple, je dirai dorénavant C5V2 pour C comme colonnes et V comme valeur haute ;
* C(x) = la variable Colonne d'un ordre ;
* V(x) = la variable Valeur haute d'un ordre
- pour les formules que je souhaite :
* P(x) = le nombre de lignes pauvres de l'ORDRE (x) en fonction de la valeur haute de l'ordre suivant ;
* R(x) = le nombre de lignes riches de l'Ordre (x) ... idem...:
* Lig(x) = le nombre de lignes d'une Combi(x) ;
* Bloc(x) = les "paquets" qu'une Combi(x) forme après un tri riche.

Or donc, pour le Rang dont je parlais hier, c'étaient bien les ordres C3V3 - C5V2.
- C3V3 = la Combi(1) de 15 lignes ;
- C5V2 = la Combi(2) de 6 lignes ;
- puisque V(2) = 2, nous avons donc :
* P(1) = 11 ;
* R(1) = 4 ;
* Lig(2) = 6

D'où : P(1) + ( R(1) * Lig(2) ) -> 11 + (4 * 6) = 35 lignes développées en 'GTHE' et non 50 comme annoncé par le calculateur.
Mais, pour moi, le plus important est d'avoir ces infos pour chaque ordre : - P(x) et R(x) en fonction V(x+1) !
N'ayant pas trouvé ces valeurs dans ton calculateur, je suis un peu bloqué !

A+

Hello !

C'était long mais je dispose d'une toute petite fenêtre avant de dormir (étant crevé je risque de ne pas être long ;) ).

Alors,

C3V3 = 15 combinaisons et C5V2 = 6 combinaisons : d'accord :)

Donc, nous allons d'abord nous créer un petit lexique (il est temps, on arrive au bout...) :

- le RANG : le tableau contenant jusqu'à... => le tableau contenant l'ensemble des combinaisons générées de l'ordre 1 à N où N est le nombre total d'ordres encodés du programme

- 10 ORDRES (x), décrivant chacun ... ==> décrivant chacun une étape du processus de l'arbre des probabilités, c'est-à-dire une succession de chiffres pouvant aller de 1 à V(x max) où V (x max) = k. Un ordre est séparé par une barre horizontale | à gauche (sauf si c'est le 1er ordre encodé) et à droite (sauf si c'est le dernier ordre encodé).

- la COMBI (x). H2SO4 en cours de traitement ; => R.A.S si ce n'est qu'il s'agit de la combinaison générée par le programme H2SO4, sachant k et n (ou C et V) avec ta nouvelle notation. La COMBI (x) est générée pour un ordre donné.

- pour faire simple, je dirai dorénavant C5V2 pour C comme colonnes et V comme valeur haute ;

* C(x) = la variable Colonne d'un ordre ; => Ou n(x)

* V(x) = la variable Valeur haute d'un ordre => Ou k(x)

- pour les formules que je souhaite :

* P(x) = le nombre de lignes pauvres de l'ORDRE (x) en fonction de la valeur haute de l'ordre suivant ; =>

* R(x) = le nombre de lignes riches de l'Ordre (x) ... idem...:

* Lig(x) = le nombre de lignes d'une Combi(x) ;

* Bloc(x) = les "paquets" qu'une Combi(x) forme après un tri riche. => Désolé mais rien compris là :(

Or donc, pour le Rang dont je parlais hier, c'étaient bien les ordres C3V3 - C5V2.

- C3V3 = la Combi(1) de 15 lignes ;

- C5V2 = la Combi(2) de 6 lignes ;

- puisque V(2) = 2, nous avons donc : => Ok donc k(2) = 2 [j'ai besoin de mes notations aussi]

* P(1) = 11 ; => P(1) = Combi (1) - R(1) et R(1) a été démontré plus bas. Par ailleurs il y a toujours kⁿ puissances combinaisons perdantes dans le programme H2SO4 donc ici P(1) = 2³ = 8 !!

* R(1) = 4 ; => Attention, tu parles du nombre lignes riches de l'ordre (X) ou tu parles du nombre de lignes riches et dont le dernière chiffre vaut V(x). Ce n'est pas pareil ! Si dans cet exemple on parle de la première option, alors on obtient les lignes :

1 1 1
1 1 2
1 2 1
1 2 2
2 1 1
2 1 2
2 2 1
2 2 2
1 1 3
1 2 3
1 3
2 1 3
2 2 3
2 3
3

==> La seule chose qui nous intéresse c'est de répondre à la question "quelles sont les combinaisons qui vont poursuivre ?" Ce sont TOUTES celles finissant par le chiffre final le plus élevé, il y en a 7 (elles sont en orange).

Il faut comprendre le sens orange, toujours.

* Lig(2) = 6 => Yes, en effet fait, Combi(x) = Lig(x) => on génèrera toujours autant de duplications [originale inclue] de lignes que le programme H2SO4

==> Donc ok, Lig(2) = 6, aucun problème.

D'où : P(1) + ( R(1) * Lig(2) ) -> 11 + (4 * 6) = 35 lignes développées en 'GTHE' et non 50 comme annoncé par le calculateur.

==> Si je reprends le calcul c'est égal à P(1) + R(1) * Ling (2) = 8 + (7 x 6) = 50, le compte est bon !

Mais, pour moi, le plus important est d'avoir ces infos pour chaque ordre : - P(x) et R(x) en fonction V(x+1) !

N'ayant pas trouvé ces valeurs dans ton calculateur, je suis un peu bloqué !

Désolé je tombe de sommeil, on en reparle demain ;)

Salut GT,

tu en as fait une bien longue, hier, dis donc. Quand je pense que tu dois encore te taper la tapisserie de l'appart' et l'idiot du village en math !

* R(1) = 4 ; => Attention, tu parles du nombre lignes riches de l'ordre (X) ou tu parles du nombre de lignes riches et dont le dernière chiffre vaut V(x).

Là, on a un (petit) problème car je n'ai pas écrit la macro ainsi et à force de ne jouer qu'avec des V3, nous sommes passés à côté !
Actuellement, je cherche dans un ordre (x) la valeur V (x+1) !!

Or, si je lis bien ton message de cette nuit, les lignes R (1) sont bien les lignes terminées par V (1) que l'on duplique et enrichit de la Combi (2).
Pas de souci, je vais étudier ton calculateur avec cette (euh, nouvelle ) donne puis corriger cela.

Comme les lignes V (x) sont toujours triées par H2SO4 en bas des Combi (x), j'imagine qu'il n'y a pas de contre-indication à ce que je commence le traitement d'un ordre (x) par le bas de la Combi ? Rien, idiotie... Oublie...
Connaissant le nombre de R(x), plus besoin d'un test à chaque ligne : deux boucles et l'affaire est faite.

Bon dimanche !
Aujourd'hui, je termine le rejointoyage de la terrasse. Ouf !

A+

Bon courage j'espère que le nettoyage de ta terrasse s'est bien passé ;)

Après t'inquiètes, tu as le temps :)

Salut GT,

- nouvelle version avec un seul REDIM pout tMIN() et tMAX() par ordre : ton calculateur devient indispensable au fonctionnement ! ;
- tu peux, en cliquant en [A5] choisir des résultats expurgés des tris pauvres ou non ;
- pour alléger le fichier, d'un RANG à l'autre ou pour le sauver : clic DROIT sur 'GTHE' efface les données.

Ce n'est pas le problème évoqué de V(x) qui m'a pris du temps (10") mais comme il me plaisait en outre de réorganiser le code, certaines subtilités ont pris un malin plaisir à se cacher.
Pour ce qui est des #NA, je pense que, quelle que soit la RAM disponible, cela vient d'une limite Excel pour ce genre de tableau dont je préfère ne pas discourir ici, n'ayant aucune certitude ni connaissance réelle.
Ce que je vois, c'est qu'il ne faut pas dépasser 60.000 lignes pour un tableau sinon... #NA.
Le RANG affiché fonctionne, Ordre 3 = +- 60.000 lignes mais si tu le changes en C6V2 -> +- 70.000 : bardaf.

Je peux passer à l'étape suivante : le jeu continue !

A+

Salut Curulis57,

Sorry je me suis endormi net hier et la journée étant chargée... je n'ai pu prendre connaissance de ce message que maintenant.

Je regarde ça ;)

merci !!!

Salut Curulis57,

De mieux en mieux ton programme, ça commence à prendre forme ! Pour les quelques remarques, il affiche en rouge les combinaisons qui ne marchent pas ? Pourquoi, pour une génération de 11300 combinaisons il est capable de mettre "N4V3" en rouge ? C'est pourtant une combinaison qui existe ;) Pas eu le temps de générer beaucoup d'essais tellement mon temps libre est raréfié actuellement :(

Je te rassure, j'ai fait quelques calculs de mon côté (ça m'a pris beaucoup de temps, même si je n'ai presque pas eu un moment pour moi cette semaine… d'où mes réponses devenues soudainement très espacées) et j'en ai déduit qu'il me faudrait une infinité de calculs à effectuer pour les gains possibles (en fait, presque toutes les combinaisons sont possibles). Et comme les probabilités ne servent à rien si les gains ne marchent pas…

Du coup, en réfléchissant, je pense qu'on peut normer ton programme avec les combinaisons que tu proposes (pas besoin d'aller plus loin). Il pourra me dépanner pour des petits arrangements. Le reste, je l'ai calculé à la force brute mathématique (genre repris de zéro : feuille + stylo et en avant pour détecter les suites logiques dans les enchaînements de combinaisons… J'ai pu en déduire que pour une espérance basée sur un gain minimal c.a.d tous les essais n(x) normés à n-1(x) essais effectifs… il me fallait utiliser une formule mathématique de propagation par récurrence !). J'ai galéré mais du coup je dispose des éléments suffisant pour faire une comparaison de probabilités.

Du coup, ton programme, même s'il n'opère que sur 60 000 lignes, me servira à faire des analyses partielles plus précises que je normerai à k=3 (j'aurais bien aimé k=4, mais je ne veux pas t'embêter plus ;) ). En tout cas il va me servir pour faire de l'affinage ou du calcul brut sur un panel de combinaisons réduit ou dit "d'initialisation". C'est très technique, mais tout ça pour me dire que ce que tu as fait va me servir :)

Merci beaucoup, désolé si jamais je passe moins en ce moment, j'ai eu beaucoup moins de temps cette semaine… Et j'ai plus que 2 W.E pour finir la tapisserie… Quelle chienlit !

Salut GT,

je me doutais bien que tes travaux devaient te bouffer le temps... T'inquiète pas !
Pour ce qui est de l'utilité de ce programme qui relève de sa seule expertise, je doutais aussi : reste pour moi, et c'est bien là l'essentiel de ma motivation, la satisfaction de l'avoir mené à bien !

Prochaines étapes :
- te permettre tous les RANGS que tu désires en utilisant la macro de H2SO4 : tu pourras indiquer n'importe quel ordre CxVx. Il y aura probablement des blocages dûs aux limites que je pourrai atteindre ;
- atteindre ces fameuses limites ! C'est en (bonne ?) voie...

Après quelques petites récréations excelliennes sur le forum, histoire de de me rafraîchir les neurones, je reprends le collier de ton programme ce soir, probablement...

Courage pour l'appart'

A+

Salut GT,

première étape franchie même si je mets des limites à tes délires mathématiques.
J'ai abandonné mes tMIN et tMAX as Byte pour les utiliser comme tableaux fixes et Variant à l'instar de tTab : bingo, plus de #NA !! mais une vitesse d'exécution moindre... Faut choisir !

Tu as deux limites malgré tout, la version présente n'étant pas capable d'encaisser plus d'1.000.000 de combinaisons totales pour un RANG.
- même si, théoriquement, je te laisse maintenant encoder les Ordres(x) comme tu l'entends, tu ne devras pas dépasser, par Ordre(x), le nombre de lignes H2SO4 indiqué en [C17].
Pour le fun, tu peux changer ce nombre : les cellules d'un nombre supérieur changeront de couleur

If Not Intersect(Target, [C17]) Is Nothing Then
    For Each rCel In [C23:L31]
        If rCel.Interior.Color <> RGB(255, 200, 205) Then _
            rCel.Interior.Color = IIf(rCel.Value > [C17], RGB(255, 190, 0), RGB(255, 255, 255)): _
            rCel.Font.Color = IIf(rCel.Value > [C17], RGB(255, 0, 0), RGB(90, 155, 215))
    Next
End If

- autre limite impossible à éviter cette fois : le nombre total théorique de combinaisons d'un RANG ne pourra pas dépasser le nombre de lignes d'une feuille Excel.
Et, ça, tu peux changer la valeur autant que tu veux en [C18], c'est dans le code avec un petit message à la clef !

Tu remarqueras que j'ai supprimé la feuille 'BDD' : les Combi(x) H2SO4 se calculent maintenant en live durant l'exécution du RANG au fur et à mesure des besoins.
Et, toujours, un clic droit sur 'GTHE' efface les résultats pour soulager la RAM.

Joyeux tests !

A+

Salut Curulis57,

Je suis désolé je n'ai absolument eu le temps de ne rien faire cette semaine, et la prochaine risque d'être compliqué aussi... En vrai j'attends mes vacances (23 Décembre au soir) pour vraiment pouvoir y consacrer plus de temps.

Je prends note de toutes tes remarques, je vais regarder ton tout nouveau programme ;) Merci pout tout :D

Je te ferai des remarques dans les jours qui suivent (mais peut être pas immédiatement).

En tout cas merci d'avoir bien avancer le schmilblick, sans toi je n'aurais pas réussi ;)