rounding hyper rapide en c/c++

Bonjour,

Question a priori simple si il en est, mais quand même:

quelle est la routine la plus rapide en C/C++ pour calculer un arrondi à n décimales?

pour le moment j'utilise ça:
inline double round(double dNum, double dStep)
{ // rounds to closest dStep increment
double dVal = dStep * ((dStep > 0) ? (int)(dNum / dStep) : 0);
if (dNum-dVal<dStep/2) return dVal;
else return dVal + dStep;
}

il doit exister mieux.

d'avance merci,

bv

est-ce que :

Code:

---

1 2	return ( dStep * floor(dNum/dStep) ) ;

---

irait plus vite ?

Merci, mais sauf erreur de ma part:

floor(dNum/dStep) ~ (int)(dNum/dStep)

donc c'est un arrondi à l'incrément inférieur, n'est ce pas?
Je cherche l'arrondi au plus proche et vraiment le plus rapide.


bv

oui mais si tu fais floor((dNum+0.5)/dStep) ça le fait pas ??

le 0.5 serait un dStep/2 pour moi, mais ça peut le faire.
'floor' est plus rapide qu'un cast en int ?

merci
bv

aucune idée....

Salut,

Je tenterais bien

Code:

---

1 2 3 4 5 6

double round_double( double d , unsigned long precision ) { double r = (floor( d* precision + 0.5)) ; return r ; }

---

précision 7 chiffres = 10000000L ;

ça ne fait pas ce qu'il veut....

Salut,

Ben oui je me suis trompé...

J'ai testé jusqu'à plus de 10^10 itérations et aucune différence entre floor et un cast en int. 'floor' me paraît toutefois plus "propre".

J'en reste donc à:

inline double round(double dNum, double dStep)
{ // rounds to closest dStep increment
double dVal = dStep * ((dStep > 0) ? floor(dNum / dStep) : 0);
return (dNum-dVal<dStep/2) ? dVal : dVal + dStep;
}

au moins pour éviter la div/0

Merci,

bv

Citation:

---

Envoyé par me_myself

au moins pour éviter la div/0

Merci,

bv

---

euhhhh ????

si tu veux du sûr et rapide , il me semble que :

Code:

---

1 2 3 4 5 6 7 8

inline double round(double dNum, double dStep) { if ( dStep < DBL_EPSILON ) return 0.0 ; // ou return Nan else return (dStep*floor((dNum+0.5)/dStep)); }

---

est beaucoup plus rapide...

Au pire :

1 test +
1 addition +
1 division +
1 multiplication


Alors que dans ta solution :

1ère ligne :

1 test +
1 division +
1 multiplication

2ième ligne :

partie gauche
1 division +
1 soustraction +
1 test +

partie droite
1 addition


Ce qui, comparé entre les 2, fait (1 division + 1 soustraction + 1 test) de plus dans ta solution que dans la mienne....

:aie:

:P

ok, you win... :lol:

Bonjour,

Je me demande (c'est un euphémisme) si c'est bien de nommer votre fonction round(), qui existe dans <math.h> avec certes une interface différente.
Vous devriez donner plus de précisions sur votre problème. Est-il "quelle est la routine la plus rapide en C/C++ pour calculer un arrondi à n décimales?" ou doit-on respecter le comportement de la fonction que vous proposez:

Code:

---

1 2 3 4 5 6

inline double round(double dNum, double dStep) { double dVal = dStep * ((dStep > 0) ? (int)(dNum / dStep) : 0); if (dNum-dVal<dStep/2) return dVal; else return dVal + dStep; }

---

quel que soit dStep ?

Déjà, vous ne pouvez pas être plus lent en validant dStep > 0 dès l'acquisition de cette variable, avant la fonction.
Vous pouvez ensuite réécrire le machin sans tests, ce qui à priori n'est pas toujours mieux qu'un test (et même parfois loin de là) mais ici sans doute mieux qu'un test à branches déséquilibrées. Enfin, c'est à voir ...

Code:

---

1 2 3 4

inline double round2(double dNum, double dStep) { return (dStep * (int)((dNum + (dStep / 2)) / dStep)); }

---

Facilement macrotable, comme ça on est sûr de l'inlinage (inlinitude, Ségolène ?) :

Code:

---

#define ROUND(x, y) ((y) * (int)(((x) + ((y) / 2)) / (y)))

---

Maintenant, il me parait évident que si vous avez un tel souci d'optimisation, c'est que vous êtes dans une méchante boucle. Imaginons que vous ayez plusieurs niveaux de boucles, et que au dernier niveau seul dNum change, en d'autres termes que dStep change "peu souvent". Vous pouvez peut-être améliorer un peu en prémâchant le boulot à chaque changement de valeur de dStep:

Code:

---

1 2 3 4

inline double round3(double dNum, double dStep, double demiStep, int invStep) { return (dStep * (int)((dNum + demiStep) * invStep)); }

---

ou (parce que là la non inlinitude serait dramatitude):

Code:

---

#define ROUND(x, y, z, t) ((y) * (int)(((x) + (z)) * (t)))

---

A vous de tester et de voir si un int est suffisant et si la multiplication par un entier est mieux que la division par un double.

Enfin, il est possible que ne puissiez avoir qu'un nombre fini et raisonnable de valeurs de dStep, correspondant bien entendu à un nombre de décimales. Vous pourriez alors multipliquer la boucle en-dessous de l'acquisition de dStep et aiguiller selon la valeur de dStep. Vous ne pouvez pas vous contenter de multipliquer la fonction round() puiqu'en utilisant un tel tableau de fonctions, vous ne pourriez plus inliner. Vous auriez donc des fonctions du type:

Code:

---

1 2 3 4

inline double round3(double dNum) { return (0.001 * (int)((dNum + 0.0005) * 1000)); }

---

ou

Code:

---

#define ROUND3(x) (0.001 * (int)(((x) + 0.0005) * 1000))

---

Vous pouvez panacher, en ne codant en constantes que les cas les plus fréquent et en conservant une branche paramétrée, bref en utilisant ce que vous savez de vos données et que le compilateur ne peut savoir d'avance.

Citation:

---

Envoyé par Pierre Maurette

beaucoup de choses avec lesquelles je suis d'accord

---

Sauf l'introduction du cast (int) à la place du floor.

Comme le paramètre de sortie est un double, faire un cast dans l'opération impose de re-faire un cast inverse pour effectuer la multiplication.

Donc un peu plus lent (je pense, mais je ne suis pas sûr) que utiliser directement floor.

D'un autre côté, si floor n'est pas définie comme un #define, il y a appel de fonction, donc plus lent...

8O

Merci à vous deux.

Pour le moment je garde:

inline double round(double dNum, double dStep)
{
return (dStep * (int)((dNum + (dStep / 2)) / dStep));
}

Il y a sans doute aussi possibilité de tout calculer en integer, shifter un bit plutôt que diviser dStep par deux, etc... Mais pas sûr d'y gagner en rapidité

bv

* floor plutot que le cast permet que ca fonctionne aussi pour les nombres negatifs
*a noter que ca arrondi a un multiple de dStep, mais que les valeurs probables de dStep risquent bien de n'etre qu'approximativement representees en flottant. Leurs inverses par contre ont des chances d'etre un entier.

Code:

---

return floor(num*part+0.5)/part;

---