> http://www.zorgloob.com/2009/11/google-lance-go-son-langage-de.asp
Je trouve le support de la virgule flottante tr�s d�cevant.
En tout cas, on est tr�s loin de la norme IEEE 754 (version
actuelle, i.e. 2008).
D'autre part, sur
http://golang.org/doc/go_spec.html#Constant_expressions
"Constant expressions are always evaluated exactly; intermediate
values and the constants themselves may require precision
significantly larger than supported by any predeclared type in
the language."
Ce qu'est une expression constante n'est pas tr�s clair, et m�me
en supposant que les appels de fonction ne peuvent pas faire
partie d'une telle expression, je me demande comment ils font.
� cause de la division, ils ont probablement besoin d'une
arithm�tique rationnelle en multipr�cision, mais mixer rationnels
et flottants du style 1.7e4913 de mani�re exacte *et* efficace
(convertir le flottant en rationnel n'est pas forc�ment une bonne
solution) me semble compliqu�... Et faire du calcul approch� (avec
analyse d'erreur et une m�thode style Ziv) risque de ne pas �tre
satisfaisant en cas de grosses cancellations. Par exemple, dans
un cas extr�me:
(1.7e4913 - 0.1) / 3 * 3 - 1.7e4913 + 0.1
m�me si ce n'est pas le genre d'expression qu'on rencontre
habituellement...
--
Vincent Lef�vre <vin...@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Ar�naire project (LIP, ENS-Lyon)
> (1.7e4913 - 0.1) / 3 * 3 - 1.7e4913 + 0.1
Il n'est pas clair si 1.7e4913 doit �tre accept� comme constante
(parce que �a ne tient pas dans un float64), mais en attendant,
avec 1.7e300 / 3 * 3 - 1.7e300, �a bugge. Je viens de faire un
rapport:
http://code.google.com/p/go/issues/detail?id=214