Je crois que c'est possible en C, mais je ne sais pas si ça l'est en VB.
 
Voici ma question :
J'ai un tableau de 500 éléments, en fonction de critères, je dois en additionner admettons de 200 à 300. Donc, je devrais faire une boucle du genre :
total=0
for i=200 to 300
   total=total+tableau(i)
next
 
Bon, le problème, c'est que je fais le même genre de chose près d'un million de fois (probas)... Donc, je cherche à optimiser l'ensemble, pour que ça ne dure pas toute la semaine.
 
Donc, existe-t'il une fonction qui ferait :
total = sum(tableau(200 à 300))
 
     

Bah ... moi je vois pas trop ...
Mais surtout je vois pas comment on peut optimiser une addition !!!
C'est ce qui prend le moins de temps au prosseceur !!!
En plus avec des For le compilo il doit optimiser le tout au pipeline ... alors ...

Bon, bah, si personne ne voit, je vais laisser tourner le prog toute la semaine !
 

Effectivement, une addition ne s'optimise pas. Par contre, si on doit répéter un plein de fois un différents sous-ensembles d'additions portant sur le même intervalle, mais à des positions différentes, il y a des cas où on peut optimiser ça pour éviter d'avoir à les refaire plein de fois.
Une solution simple: utiliser un second vecteur contenant la somme progressive des éléments: ce vecteur n'est calculé qu'une seule fois. Ensuite, si on a à prendre plein de fois la somme des éléments entre deux bornes aléatoires de cet ensemble, on n'a pas à refaire toutes les additions: il suffit de faire la différence entre les sommes progressives relatives à chaque borne: résultat 1 seule soustraction à chaque passage.
 
Mathématiquement cela s'écrit:
 
Pour tout i,j tel que 1 <= i <= j <= N,  
  Somme(valeur[i] à valeur[j])
= Somme(valeur[1] à valeur[j])
- Somme(valeur[1] à valeur[i - 1])
 
En posant:
  cumul[0] = 0, et
  cumul[i] = Somme(valeur[1] à valeur[i]), pour 1<=i<=N,
on a aussi:
  cumul[i] = cumul[i-1] + valeur[i]
Le vecteur cumul est calculable en une seule passe comptant N additions en tout pour un tableau de valeurs de longueur N.
 
On obtient alors:
  Somme(valeur[i] à valeur[j]) = cumul[j] - cumul[i - 1]
Cette somme est la différence de 2 cumuls déjà réalisés avant. Et il ne faut qu'une seule opération à chacune des fois.
 
Il y a encore des variantes, dans le cas où quelques éléments du tableau de valeurs ont pu changer: il suffit de garder la trace des valeurs qui ont été modifiées, en maintenant deux tables en parallèle du vecteur de valeurs: la table supplémentaire contient l'indice depuis lequel les cumuls ont été opérés totalement. On garde la trace des indices minimum et maximums pour lesquels les sommes ne sont plus valide car des valeurs ont été changées: à chaque changement, on enregistre la différence entre l'ancienne valeur et la nouvelle et lorsqu'on aura à faire à nouveau des sommes à bornes aléatoires, il suffit de regarder si ces bornes ont une intersection avec les valeurs modifiées. Si c'est le cas, on n'a qu'à recalculer uniquement les sommes progressives entre les bornesde l'intersection, en reportant la différence initiale aux extrémités de l'intersection, et en reportant les autres différences dans les cumuls progressifs.

[edit]--Message édité par verdy_p--[/edit]

Une addition ca peut s'optimiser:
Si l'un des termes est nul, on n'effectue pas l'operation.
A+,

gilou a écrit a écrit : Une addition ca peut s'optimiser: Si l'un des termes est nul, on n'effectue pas l'operation. A+,

Sauf que tester si un terme et nul et sauter l'addition si c'est le cas, prends plus de temps que de faire l'addition sur toutes les machines surtout si l'addition n'est pas effectuée car un saut coûte plus cher. Bref cela ne règle rien.
Je pense que ma solution est meilleure et dois correspondre au problème posé (bien qu'on ne nous a pas donné le détail de ce que devenait les valeurs entre deux évaluations de la somme, et comment étaient choisies les indices bornes des additions à effectuer...).
 
En tout cas ma solution, quand le nombre n de sommes à calculer dans un ensemble de valeur de cardinal N, tends vers l'infini tends vers 1 seule opération (une soustraction) par somme calculée: solution en O(n) et non O(n.N), ce qui indique une véritable optimisation algorithmique dans son cas puisqu'il indiquait qu'il allait devoir effectuer des millions de sommes.

Verdy, je sais bien cela. D'ou mon smilie en fin de reponse.
A+,

Merci, Verdy, mon traitement s'est terminé dans la nuit, mais si je dois refaire ce traitement, je ferai ce genre de tests, je ne manquerai pas d'utiliser ta méthode.  
 
Bye.  
 

[edit]--Message édité par waybee--[/edit]