Discussion :

[ZaaN]

salut,

je me demandais si il faut calculer les valeures tel que Pi ou e. Ou alors si on peut les trouver dans une bibliothèque...

[Laurent Gomila]

Pourquoi ne pas simplement définir toi-même les constantes dont tu as besoin ? Pour ce qui est de les calculer, ce sont des constantes alors l'intérêt me paraît plutôt limité.

[ZaaN]

ben comme je vais aborder une grosse phase de math. j aurais voulu savoir les habitudes en la matière, eventuellement des bibliothèques pour l'agèbre, etc...

pour ce qui est du pi, il est clair que je vais le redefinir plus precis que le PI existant. (quand je disais calculer, c'était pas forcement dans le programme...)

[nicroman]

Perso, j'ai redéfini les constantes (mais plus par flemme de les chercher):

Code c++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
namespace rw::math {
 
#define PI_VALUE  3.141592653589793238462643
const float32_t f32_pi = DECLARE_FLOAT32(PI_VALUE);
const float64_t f64_pi = DECLARE_FLOAT64(PI_VALUE);
const float80_t f80_pi = DECLARE_FLOAT80(PI_VALUE);
 
}

A noter que c'est la précision maximale (à moins que je ne me sois gourré, mais le float64 a bien l'air de 'perdre' la derniere décimale ).
Et c'est une librairie ou l'utilisateur peut choisir de tout faire en long double, double ou en float (et la constante de PI utilisée dépend de ce choix).

En même temps... ces constantes sont toujours limitées intraséquement par l'utilisation des flottants, et ca n'empêche pas les utilisateurs de devoir être "intelligents":
Par exemple, on incrémente pas un flottant sans arrêt pour simuler plusieurs tours sur lui même...

[valefor]

Et je crois que dans math.h il y a des constantes comme M_PI et autre. C'est du C mais bon.

[Laurent Gomila]

Et je crois que dans math.h il y a des constantes comme M_PI et autre. C'est du C mais bon.

Il n'y a que M_PI, et encore, pas toujours.

[aoyou]

C'est du C mais bon.

En C++, il y a l'header cmath... qui grosso modo ne fait que inclure que math.h.

[valefor]

Il n'y a que M_PI, et encore, pas toujours.

Tu veux dire sur l'ensemble des implémentations que tu as eux l'occasion de voir ?

Parce que si j'en crois le lien, il y a aussi pas mal d'autre trucs...

[Luc Hermitte]

Il veut dire que c'est une extension propriétaire.

[valefor]

Ha d'accord.

Pourtant un man math.h me donne les mêmes informations, et aussi man math.h

[Jean-Marc.Bourguet]

Il veut dire que c'est une extension propriétaire.

"Proprietaire" n'est pas le mot que je choisirai pour qualifier ce qui est demande par POSIX.

[Luc Hermitte]

Ah! Au temps pour moi.
Je ne savais pas que c'était POSIX en fait.

[JolyLoic]

Perso, j'ai redéfini les constantes (mais plus par flemme de les chercher):

Code c++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
namespace rw::math {
 
#define PI_VALUE  3.141592653589793238462643
const float32_t f32_pi = DECLARE_FLOAT32(PI_VALUE);
const float64_t f64_pi = DECLARE_FLOAT64(PI_VALUE);
const float80_t f80_pi = DECLARE_FLOAT80(PI_VALUE);
 
}

Si je devais faire ainsi, je pense que je tenterais de les mettre dans un template, à la numeric_limits, avec pour but de pouvoir d'un simple typedef passer mon code d'un mode de représentation des flottants à l'autre, afin de voir s'il me sort les mêmes résultats.

[nicroman]

Oui... probablement... Je ne vais pas exposer toute la problématique sur les types 32/64/80... mais le cahier des charge était:
- Toutes les fonctions utilisant des flottant doivent être disponibles dans les trois formats, et exportées (DLL).
- Chaque fonction possède une précision prédéfinie (1% d'erreur max par exemple).

Du coup on a été ammenés à faire 1 fonction pour chaque type dans 95% des cas.
Le template nous aurait été d'une utilité nulle (il aurait fallu spécialiser pour chaque type) sans compter les erreurs à ralonge additionelles, et les problêmes d'exportation en DLL.

Et ca marche tout aussi bien.... en C