begin process at 2012 02 12 15:59:51
  Trouver un code source :
 
dans
 

12 commentaire(s) de Albedo039 sur des sources sur tout CodeS-SourceS

Déposé sur Trouver les diviseurs d'un nombre entier

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;
Posté le : 31/01/2008 16:25:58

Déposé sur Trouver les diviseurs d'un nombre entier

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...)

Posté le : 31/01/2008 15:34:48

Déposé sur Liberer de la mémoire pour firefox

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.
Posté le : 22/11/2007 10:40:17

Déposé sur Logiciel de traitement d'images

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;
++++++++++++++++++++++
Posté le : 08/11/2007 13:36:10

Déposé sur Calpi, maths amusantes

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"
Posté le : 05/11/2007 12:19:08

Déposé sur Réels et réalité

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 :)
Posté le : 01/11/2007 14:09:51

Déposé sur Réels et réalité

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... ;)
Posté le : 31/10/2007 12:16:40

Déposé sur Réels et réalité

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 ;)
Posté le : 31/10/2007 10:15:37

Déposé sur Effet d'eau avec scanline

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?
Posté le : 26/06/2007 14:10:56

Déposé sur Effet d'eau avec scanline

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 :))
Posté le : 25/06/2007 17:16:38

1 2


Nos sponsors


Sondage...

Comparez les prix

CalendriCode

Février 2012
LMMJVSD
  12345
6789101112
13141516171819
20212223242526
272829    

Consulter la suite du CalendriCode

Photothèque

 
Développement réalisé par Nicolas SOREL (Nix) avec l'aide de : Cyril DURAND et Emmanuel (EBArtSoft), Merci à Vincent pour ses précieux conseils.
CodeS-SourceS.com© Toute reproduction même partielle est interdite sauf accord écrit du Webmaster
CodeS-SourceS.com© est une marque déposée tous droits réservés

Google Coop CodeS-SourceS Google Coop CodeS-SourceS
Temps d'éxécution de la page : 0,359 sec (3)

Nous contacter | Annoncer sur CodeS-SourceS | Mentions légales