Non non, c'est juste que j'aide Mathias pour l'entrainement des candidats IOI.

22h ? dommage tu pourras pas participer a la partie de gonflage de matelas ou de 'testage' des machines..

Yes, a bientot !

ps: j'y suis deja en fait..

Ca fait plus de trois ans que cette source aurait dû être supprimée..
Que de temps a passé depuis

Désolé mais je n'assure plus le support sur les produits de plus de 2 ans n'ayant pas été mis à jour ;)

<mode:arf,chui arrivé _que_ 12ième>
Hoho.. faut arrêter d'encourager tout le monde à aller à Prologin, après ils font mieux que vous ;)
</mode>
En tout cas je suis content de t'avoir pu te faire découvrir cette aventure (ce périple ?)...
L'année va paraître longue jusqu'à avril prochain :)

En attendant, pensez à vous entrainer.
Et à l'année prochaine (ou pas.)

un point plutôt, non ?

He oui, Kirua, je te lis aussi, tu es une star ;)
(à quand une équipe de Belgique pour les IOI ?)

Et pour parcourir un arbre binaire sans fonction récursive, on peut se faire sa propre pile (en gros ça revient à faire un appel) pour une moitié et utiliser un while pour l'autre moitié, c'est assez barbare :)

Comme l'a dit Kirua, il vaut mieux utiliser un tableau complet indicé pour la fonction factorielle mais la méthode que tu montres (ne garder qu'une valeur) peut être intéressant si on est très limité en place et si les valeurs demandées sont assez proches (sinon ça revient quasiment à tout calculer et en pratique ça prendra même plus de temps), comme par exemple une courbe continue.

Un graphe connexe se dit d'un graphe non orienté dont tous les sommets sont accessibles depuis tout autre, il ne possède donc qu'une composante connexe. Pour un graphe orienté, il est connexe si le graphe non-orienté qui lui est associé est connexe.
Fortement connexe ne se dit que pour les graphes orientés, si depuis chaque sommet on peut atteindre tous les autres. Un graphe orienté fortement connexe est donc connexe et possède au moins un cycle.

Par contre je n'ai jamais rencontré "faiblement connexe".

Afyn:
&gt;&gt;Y a t-il une méthode qui permettrait d'accélerer l'affichage ou le rafraichissement des Controls VB (un label ou une ListView) ?
DarK Sidious:
&gt;&gt;Je ne pense pas que ce soit possible vu qu'on ne peut pas intercepter leurs appels aux API pour les réorienter, en tout cas, je pense pas !

Il y a un moyen, qui consiste à indiquer (à la création du contrôle) que l'on va traiter nous-même l'affichage des contrôles (style OWNERDRAW), ensuite des événements sont générés par l'appel à la WindowProc (pour le faire en VB, il faudrait faire un sous-classement), ce qui permet entre autres de dessiner ce que l'on veut comme controle . Mais je ne pense pas que l'on puisse vraiment accélérer ceci (surtout en VB !) car les fonctions de User32 et Gdi32 sont déjà bien optimisées.


DarK Sidious:
&gt;&gt;Dommage que ce soit une dll développée en C : le gain de performance se justifie par l'utilisation de ce langage aussi...si ca se trouve, ma source en C ferait mieux... lol. Faudras que j'essaie lorsque j'aurais plus de connaissance en C ;-)

C'est clair, si tu veux un peu d'aide pour le faire en C, n'hésite pas à me demander :)


DarK Sidious:
&gt;&gt;Finalement, c'est pas si rapide que cà !

Il faut prendre en compte également que les appels d'API par VB sont particulièrement lents comparés à d'autres langages.


Et enfin, mon test :
5297/684 = 8x sur mon AMD K6-II 450MHz
(2x en non-compilé)

j'avais compté 8, je ne sais plus pourquoi...
bon, en plus ce sont des unsigned short donc pas 32767 mais 65535, on a donc ... 64 * 65535 * 20 (on peut réduire Etat à 20 octets en faisant des champs de bits pour les opérations déjà effectuées) = 80 Mo :D
Je pourrai le lancer mais c'est tout lol

Si mes calculs sont bons, ça ne fait que 2645395200 possibilités au maximum :D
En dynamisant le tout, on peut réduire à 64 * valeur maxi (32767) = 2097088
Evidemment, 16 Mo de mémoire pour si peu, ça fait beaucoup :\