Et comme mx1 est un long , je m'attendais à ce qu'il prenne la valeur 1 , or il prend la valeur 2 . Si je mets mx.l , là c'est ok , ça marche comme attendu . Bon pourquoi pas ,il suffit de le savoir , mais j'étais étonné , et surtout j'ai cherché un moment pourquoi j'avais des erreurs
car au dessus de 1.500 c'est egale a 2
et en dessous c'est egale a 1
c'est le principe de l'arrondi ça !!
moi je trouve ça normal !! (et mem pratique !! pour la compta !! )
car au dessus de 1.500 c'est egale a 2
et en dessous c'est egale a 1
c'est le principe de l'arrondi ça !!
moi je trouve ça normal !! (et mem pratique !! pour la compta !! )
un arrondi "au dessus" c'est à partir de 1.5 et pas au delà
Sinon je pense qu'une division d'entier devrait etre entiere... Et pas arrondie... Mais comme dis comtois l'essentiel c'est de le savoir... Et je crois que ca m'a fait comprendre pourquoi un de mes portages DB vers PB ne fonctionne pas du tout...
dans le debugger ce qui correspond bien à un comportement cohérent :
- si la division est basée sur des entiers en totalité le calcul se fait en entiers et donc le résultat est bien équivalent à Int().
- si la division contient un ou plusieurs flottants, le calcul est réalisé en flottant et le résultat est arrondi à la valeur entière la plus proche avant d'être affecté à la variable.
Le code généré en ASM montre bien ce comportement.
Slts
Mon avatar reproduit l'image de 4x1.8m présentée au 'Salon international du meuble de Paris' en janvier 2004, dans l'exposition 'Shades' réunisant 22 créateurs autour de Matt Sindall. L'original est un stratifié en 150 dpi.