On peut opérer les tests de "haut en bas" (du plus grand au plus petit diviseur possible)
puisqu'on sait déjà que le plus grand diviseur possible est le nombre en entrée divisé par 2.

Si ce premier "diviseur à tester" est pair, alors après l'avoir tester, on peut le diviser par 2 de nouveau: c'est le prochain "diviseur possible".... et ainsi de suite.

Faire le test p.e. avec 2717908992: 81 x 2 x 2 x... (25 fois 'par2')
on pourrait alors optimiser cette partie du code:
- chercher les combinaisons possibles des 25 fois 'par2' (2, 4, 8, 16, 32... 33554432)
- le résultat de la dernière division par 2 est 81. calculer les combinaisons de ce nombre avec les combis précédentes.
- étudier "81" pour voir s'il est lui-même "divisible" : s'il est divisible, alors les diviseurs peuvent être "combinés" avec les nombres précédents...
Par exemple ici:
81 = 9x9
81 = 3x3x3x3
81 = 27x3
on sait donc que 3, 9 et 27 sont des diviseurs
mais donc aussi que
3x2
3x4
3x8
3x16
...
3x33554432
et ainsi de suite avec 9 et 27.

++++++++++++++++++++++++++++++++++
Je pense que l'on peut optimiser beaucoup plus encore :)

Par exemple en utilisant des embranchements de code:

if JeSuisPair then
TrouveDiviseursProc:= Ma_Proc_Speciale_Nombres_Pairs
else
TrouveDiviseursProc:= Ma_Proc_Speciale_Nombres_Impairs;
TrouveDiviseursProc(...);

et bien sûr qqc comme:

procedure Ma_Proc_Speciale_Nombres_Pairs(...);
Begin
...
End;

Heuuuu... juste un petit mot en passant ;)
Si le nombre à étudier est impair, alors on peut optimiser encore.

En effet, on peut tester en "sautant" les diviseurs potentiels qui sont pairs, puisque les nombres pairs ne "génèrent" (à la multiplication) que des nombres pairs.
Dans ce cas
DivisorA := DivisorA + 2;
fait l'affaire.

Statistiquement parlant, c'est un gain de 25% (50% de tests en moins pour 50% des nombres à étudier possibles...)

Salut,

je n'ai pas testé en Live et ne peux juger de l'utilité/du bien-fondé de l'appli...
mais en tout cas, le code est bien formaté et commenté (API_LiberationProcessus.pas)
Cheers,
L.

Pas mal... même si l'utilisation de Pixel[...] est assez lente.

Moi, j'aime bien "simplifier le code", alors je te propose de remplacer

++++++++++++++++++++++
begin
     if Sens_NB.Text='->' then
        Sens_NB.Text:='<-'
     else
        Sens_NB.Text:='->';
end;
++++++++++++++++++++++

par

++++++++++++++++++++++
const
     cSensBouton: array[0..1] of String = ('->','<-');

Begin
     Sens_NB.Text:= cSensBouton[ ord(Sens_NB.Text = '->') ];  
End;
++++++++++++++++++++++

Est-ce que ça marche avec des grains de blé?
Et du blé en éPI ?
:))

Et comme disait Confucius (avé l'axant):

"Plus il y a de fous, moins il y a de riz"

Pour programmer un algo dans son langage de prédilection, il faut toujours suivre le "mode d'emploi" :)
c.a.d. il faut toujours considérer le contexte et les règles de son utilisation, qui sont en général livrés avec la description formelle de l'algo.

Par exemple, le contexte bancaire et les règles (lois et/ou décrets) régissant la manière d'arrondir et la précision des nombres à virgule.
Dans ce cas, 5 lignes peuvent à priori parfaitement suffirent.

La méthode de WhiteHippo est utile ... lorsqu'il n'existe pas de telles règles :)

Matière à réflexion:
--------------------

Il existe un autre problème bien plus subtil en ce qui concerne les "finances":
le calcul de la TVA.

En l'occurrence, beaucoup de logiciels affichent des factures ayant plusieurs produits et leurs prix...
??? Mais quand doivent-ils calculer la TVA ???
:)
1) (somme des prix HT)* Taux de TVA
2) (Prix HT 1)*TVA + (Prix HT 2)*TVA + ...

Dans beaucoup de cas, le résultat est identique. Mais (parcequ'il y a un "mais") pas toujours !
C'est dû à la manière et le moment d'arrondir les montants et au nombre de chiffres significatifs utilisés....

AFAIK, seul la solution de type 2) est valable:
http://www.legalbiznext.com/droit/La-facturation-electronique-la
http://rfcomptable.grouperf.com/article/0298/ms/rfcompms0298fisfac01.html
http://www.legifrance.gouv.fr/WAspad/UnTexteDeJorf?numjo=BUDF0300016D

Il reste le problème de l'arrondi... ;)

Ben en fait non.
(je suis pas banquier, mais j'ai déjà progé des logiciels financiers)

Le banquier, y travaille au burin! Y découpe tout ce qui dépasse au moins une fois par an.
en d'autres termes, il utilise seulement un nombre restreint de chiffres significatifs et il arrondit au besoin.
Donc:
pour tout problème périodique (annuaire/mensuel...), la formule de calcul "simple" (purement mathématique) n'est pas utilisable.

Conclusion:
ce n'est pas un problème de type de flottant, c'est une erreur de logique du programmeur ;)

Naalsoo :)) Sieht schon viel besser aus.

Habe noch "eine" Bitte (um Zeilen 427-432):
5 Mal "rect(1,1,wi-2,he-2)"
kann man doch irgendwie aufmotzen, oder?

je n'ai pas vérifié en détail... mais il y a bcp de calculs répetitifs qui doivent pouvoir se rationaliser.

ex. 1:
#  nw:=((vagues[cp+wn-wi-1]+
# vagues[cp+wn-wi ]+
# vagues[cp+wn-wi+1]+
# vagues[cp+wn -1]+
# vagues[cp+wn +1]+
# vagues[cp+wn+wi-1]+
# vagues[cp+wn+wi ]+
# vagues[cp+wn+wi+1]) div 4)-vagues[sp+wn];
=> il y a 8 fois le calcul cp+wn ou encore il y a 3 fois les calculs "cp+wn+wi" et "cp+wn-wi"
En utilisant des vars supplementaires, on devrait gagner un peu, non?

ex. 2:
les indexages à "img" sont assez fréquents.
Il est peut-être possible d'améliorer la vitesse.
Considérant "result:=im[x+(he-y)*wi];" (ligne 105):
=> créer un tableau suppl. dans lequel on a précalculé les combinaisons possibles c.a.d.
for x:=0 to wi do for y:=0 to he do TabSuppl[x,y]:=x+(he-y)*wi;
et après on obtient
result:=im[TabSuppl[x,y]];
ce qui économise 2 additions et une multipl.

et

"im[i+(2*he-j-1)*wi]:=getpix(dx,dy);"
peut être traité de la même manière :)


ex.3:
je n'ai tjs pas vérifié ;) le code assembleur produit, mais je propose que toooouuus les "*2" et les "div 4" etc... soit remplacés par
"*2" => shl 1
"div 4" => shr 2


Sinon: moi j'aime bien les vagues :))