Vous ne trouvez pas de réponse à votre problème ? Alors posez la question dans le forum. Souvenez-vous qu'il n'y a jamais de question bête, mais rester dans l'ignorance parce que l'on n'ose pas poser une question, ça c'est une erreur !

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

Le : 31/01/2008 16:25:58
Source : 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;


Le : 31/01/2008 15:34:48
Source : 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...)



Le : 22/11/2007 10:40:17
Source : 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.


Le : 08/11/2007 13:36:10
Source : 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;
++++++++++++++++++++++


Le : 05/11/2007 12:19:08
Source : 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"


Le : 01/11/2007 14:09:51
Source : 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 :)


Le : 31/10/2007 12:16:40
Source : 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... ;)


Le : 31/10/2007 10:15:37
Source : 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 ;)


Le : 26/06/2007 14:10:56
Source : 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?


Le : 25/06/2007 17:16:38
Source : 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 :))



1 2


Nos sponsors

Sondage...

CalendriCode

Juillet 2009
LMMJVSD
  12345
6789101112
13141516171819
20212223242526
2728293031  

Consulter la suite du CalendriCode

Comparez les prix Nouvelle version

Photothèque Nouveau !



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
Temps d'éxécution de la page : 0,187 sec

Google Coop CodeS-SourceS Google Coop CodeS-SourceS


Certaines images présentes sur le site (notament certains avatars) sont issues des collections IconShock, donc si vous souhaitez utiliser ces icons vous devez les acheter, ne les copiez pas et ne utilisez pas dans vos sites et applications sans les avoir commandé.