De toute façon, il faut définir soi-même le delta. J'aimerais tellement voir un langage de programmation qui gère des réel avec range et prévision. Tout un tas de transformation resterait valide (de mémoire, c'est encore un anneau ou un corps). Une fois simplifié, tout est transformé en code flottant.
"total à diviser en pourcentage (ça fait 1/quelque chose)…)"
C'est vrai, mais si c'est pour un affichage, tu te fou d'une erreur inférieur à 10-3. La division par zéro, c'est encore autre chose. L'erreur existe, avec des maths pure, les entiers, ce n'est pas spécifiques au flottant.
Je me rappelle des discussions de codeurs audio qui vantaient les entiers 64 bits, avec lequel ils faisaient du virgule fixe, avec 16 bit sous la virgule et donc tout un tas de contraintes sur les opérations.(j'ai codé de la trigonométrie en virgule fixe sur µP, c'était pas drôle) Tout cela parce que les float 32 bits, avec 24 bits de mantisse ont forcément des erreurs inclus. Aujourd'hui, vu la demande de puissance, des algos audio peuvent entièrement être codé en double, avec un code beaucoup plus simple.
"(note que je n'ai rien contre le fait d'utiliser les float en science, où il faudra incorporer leur imprécision dans la détermination de l'imprécision du résultat)."
Demande à Alenvers, de mémoire, c'est son boulot, et évidement qu'il en tient compte.
"qu'un centime d'erreur dans un compte de plusieurs centaines de milliers de franc ce n'est rien. Mais mon tympant se souvient encore du mécontentement d'une cliente, qui a passé avec moi des heures au téléphone pour un centime d'erreur, simplement parce que les bons comptes font les bons services publics. :D"
254 (un double), c'est 1016, ce n'est pas une erreur sur 100 000 ! De plus, les erreurs de centimes (toujours dans le même sens) pour faire croire à une erreur informatique, les grosses boites appellent cela du "pricing". On a un prix annoncé de 30€ ttc, puis il donne le prix HT, puis calcul des taxes, et le prix à payé devient 30.01€ et non plus le prix ttc de la pub.
C'est pourtant 2 commentaires au dessus. Les arrondis en question sont très bien définit, et garantisse une sorte d'annulation de l'erreur. Les vrais problèmes se posent lors d'addition/soustraction de nombre de taille très différente.
Ce que tu ne comprends pas, et que pourtant quelqu'un à très bien résumé avec une citation de Linus, est que la plus part du temps, on s'en fout que 1/3*3 != 1.0. En général on veut 1/3*3 - 1.0 < delta, avec delta = 10-6 ou 10-10. Cela dépend des usages. Toutes les maths sont faite ainsi sur ordinateur, regardes comment est codé la libm. Regardes l'astuce de la multiplication par une constante pour Doom pour éviter une division, c'est toujours le même principe : la précision est-elle suffisante ou pas.
L'imprécision est même inclus dans les données d'entrée : il n'existe aucun "capteur absolue", il y a toujours une erreur estimable. Idem pour les effecteurs qui n'ont jamais de précision infini. Même les algorithmes de calcul sont souvent des approximations de la réalité (en simulation par exemple). Quel intérêt de faire des résultats avec 15 chiffres, quand l'algo ne peut en sortir que 6 ?
Dans le cas de calcul monétaire, on veut juste que les résultats de compte finaux soit juste à quelques fractions de centime pret, mais c'est vrai qu'il est plus simple d'utiliser des grand entiers pour y arriver.
"Comme si je ne saivais pas qu'on avait inventé les nombres flottant parce que les ordinateurs ne comprennent pas les décimaux du système décimal de manière native"
En plus, c'est complètement faux. Les premières machines savaient compter en base 10 (cf les calculs BCD). Le calcul binaire est simplement plus efficace d'un point de vue hardware (en taille/vitesse/consomation).
C'est plus simple pour ne pas faire de bétises, d'avoir des nombres flottant décimaux pour faire des applications financières, d'ou le support par IBM sur leur grosse machine.
Oui, mais c'est de la capiloquadrisectomie. β = 10 en hardware ne doit exister que pour le machine Power d'IBM. Sur x86, cela doit être plus simple d'utiliser une bibliothèque numérique de précision étendu.
Par flottant, j'entendais double ou float, dans le sens de C. :)
Bah non, justement (et là, je peux te prendre pour un con, ce qui n'était le cas avant). Excel s'amuse (s'amusait ?)à écrire et relire ses cases, des chaine de caractère, et donc à faire les conversions pour faire des calculs en flottant en base 2. Je n'ai jamais parler de la raison d'être des flottants, encore heureux que tu saches à quoi cela sert.
Les décimaux flottant existent mais sont très peu utilisé (sauf machine IBM) et je serais curieux de voire comment elles sont supporté sous x86.
C'est vachement utile d'avoir le chiffre exact ! Avec 1/3, tu va avoir l'air malin pour faire tes sommes. Sinon, tu va en faire quoi de tes 10-15 centimes ? Relis la citation de Linus posté ailleurs, (des fois, pi=3.14 suffit !)
Donc, "et là", et bien on s'en tape, dans la vrai vie on a besoin d'un résultat final en 10-5 euro.
Et il n'y a pas besoin de "tout connaitre", il suffit de se renseigner un minimum sur ce que sont les nombres IEEE754.
J'ai été un plus loin que ce document qui je connais depuis quelques années.
C'est toujours agaçant de se faire moinser par des gens qui ne comprennent pas ce qu'ils font.
Si ton nombre rentre dans la mantisse, tu as aucun soucis de plus que tu n'en aurais avec un entier. Point à la ligne. C'est si compliqué à comprendre ?
Les arrondis round-to-even te répartissent au mieux les erreurs de calcul garanti à 1/2 LSB par calcul. C'est sûr que si tu t'amuses à mélanger des nombres énorme et tout petit, ton nombre ne rentre plus dans la mantisse et l'exposant rentre en jeu avec toutes les annulations de bits qui vont avec.
Ensuite, les nombres IEEE, c'est de la "grosse merde", car ce n'est pas un corp, ni un anneau, tu ne peux pas faire des maths avec. C'est beaucoup plus simple de faire l'inverse : raisonner avec des nombres ayant un range et une précision à mapper sur des nombres flottants.
Il y a bien des gens qui font des comptes avec excel sachant qu'excel rajoute une couche intermédiaire de sérialisation/déserialisation vers du décimal (pour rappel 0.1 ne s'exprime pas en nombre flottant).
C'est le fait que la mantisse est de 54 (je n'ai pas mis ce chiffre par hasard…) ou 24 bits qui te fait perdre des bis de précision, et cela n'a rien à voir avec le min et le max. Les arrondis de calcul sont assez bien maitrisés.
Faire une architecture correct et simple, ou recoder une fonction qui existe déjà pour aller plus vite, ce n'est pas la même démarche. Pas du tout.
Si tu recodes String.split, alors que tu n'utilises cette fonction uniquement pour lire une configuration à l'init, cela ne sert à rien. Par exemple.
_"Quand ton produit est à taille humaine, on est tout à fait capable d'estimer "au pif" si telle ou telle solution est viable et de le POCé/testé en quelques minutes si on a besoin de chiffre." _
Sauf pour le gros grain, mais une fois ton archi faite, en général les estimations aux doigts mouillés des "bottlenecks" de performance, sont en général fausses.
"Si tu n'as plus junior devant ton nom tu sais aussi commencer à estimer ce qui va coûter cher ou non et le mesurer corriger ASAP pour ne pas cumuler des choses non-rattrapables."
En général, ceux qui disent ça, n'ont plus "junior" devant leur titre, mais par encore "senior" ou "expert".
Je confirme, il y a 2 moyens de gagner du temps :
- avoir une bonne archi (ne pas faire 2 fois le même boulot couteux, éviter un parcours exponentiel.)
- hacker (refaire les trucs à la main, …)
Le 1er se fait en amont, avec des gains monstrueux à la clef (x1000). Le 2ième te fait gagner x10 maxi.
En général, les optimisations prématurées ne font rien gagné du tout, et rajoutent des bugs. C'est plus difficile de faire marcher un truc le plus simplement du monde (== moins de code, moins de bug, plus petit,…), que de le faire aller plus vite ensuite.
[^] # Re: quelques points
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 3.
De toute façon, il faut définir soi-même le delta. J'aimerais tellement voir un langage de programmation qui gère des réel avec range et prévision. Tout un tas de transformation resterait valide (de mémoire, c'est encore un anneau ou un corps). Une fois simplifié, tout est transformé en code flottant.
"La première sécurité est la liberté"
[^] # Re: quelques points
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 4.
Utiliser "==" avec un float ?! Ouch. C'est à éviter.
"La première sécurité est la liberté"
[^] # Re: quelques points
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 3.
"total à diviser en pourcentage (ça fait 1/quelque chose)…)"
C'est vrai, mais si c'est pour un affichage, tu te fou d'une erreur inférieur à 10-3. La division par zéro, c'est encore autre chose. L'erreur existe, avec des maths pure, les entiers, ce n'est pas spécifiques au flottant.
Je me rappelle des discussions de codeurs audio qui vantaient les entiers 64 bits, avec lequel ils faisaient du virgule fixe, avec 16 bit sous la virgule et donc tout un tas de contraintes sur les opérations.(j'ai codé de la trigonométrie en virgule fixe sur µP, c'était pas drôle) Tout cela parce que les float 32 bits, avec 24 bits de mantisse ont forcément des erreurs inclus. Aujourd'hui, vu la demande de puissance, des algos audio peuvent entièrement être codé en double, avec un code beaucoup plus simple.
"La première sécurité est la liberté"
[^] # Re: Mouarf
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Linus is evil…. Évalué à 10.
Il est juste énorme ce poste :)
That's the spirit.
Greg has taught you well. You have controlled your fear. Now, release
your anger. Only your hatred can destroy me.
Come to the dark side, Sarah. We have cookies.
Linus_
"La première sécurité est la liberté"
[^] # Re: quelques points
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 3.
"(note que je n'ai rien contre le fait d'utiliser les float en science, où il faudra incorporer leur imprécision dans la détermination de l'imprécision du résultat)."
Demande à Alenvers, de mémoire, c'est son boulot, et évidement qu'il en tient compte.
"qu'un centime d'erreur dans un compte de plusieurs centaines de milliers de franc ce n'est rien. Mais mon tympant se souvient encore du mécontentement d'une cliente, qui a passé avec moi des heures au téléphone pour un centime d'erreur, simplement parce que les bons comptes font les bons services publics. :D"
254 (un double), c'est 1016, ce n'est pas une erreur sur 100 000 ! De plus, les erreurs de centimes (toujours dans le même sens) pour faire croire à une erreur informatique, les grosses boites appellent cela du "pricing". On a un prix annoncé de 30€ ttc, puis il donne le prix HT, puis calcul des taxes, et le prix à payé devient 30.01€ et non plus le prix ttc de la pub.
"La première sécurité est la liberté"
[^] # Re: quelques points
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 3.
"Le problème que tu n'as pas l'air de comprendre (ou qui te semble trop évident), c'est qu'il faut faire des arondi après chaque opération"
http://linuxfr.org/news/de-tout-de-rien-des-bookmarks-du-bla-bla-29#comment-1471335
C'est pourtant 2 commentaires au dessus. Les arrondis en question sont très bien définit, et garantisse une sorte d'annulation de l'erreur. Les vrais problèmes se posent lors d'addition/soustraction de nombre de taille très différente.
Ce que tu ne comprends pas, et que pourtant quelqu'un à très bien résumé avec une citation de Linus, est que la plus part du temps, on s'en fout que 1/3*3 != 1.0. En général on veut 1/3*3 - 1.0 < delta, avec delta = 10-6 ou 10-10. Cela dépend des usages. Toutes les maths sont faite ainsi sur ordinateur, regardes comment est codé la libm. Regardes l'astuce de la multiplication par une constante pour Doom pour éviter une division, c'est toujours le même principe : la précision est-elle suffisante ou pas.
L'imprécision est même inclus dans les données d'entrée : il n'existe aucun "capteur absolue", il y a toujours une erreur estimable. Idem pour les effecteurs qui n'ont jamais de précision infini. Même les algorithmes de calcul sont souvent des approximations de la réalité (en simulation par exemple). Quel intérêt de faire des résultats avec 15 chiffres, quand l'algo ne peut en sortir que 6 ?
Dans le cas de calcul monétaire, on veut juste que les résultats de compte finaux soit juste à quelques fractions de centime pret, mais c'est vrai qu'il est plus simple d'utiliser des grand entiers pour y arriver.
"La première sécurité est la liberté"
[^] # Re: moef
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Et moi qui croyais que le client lourd serait gagnant.... Évalué à 2.
intégrer un truc comme camlistore, c'est trop difficile ? pas assez mature ?
"La première sécurité est la liberté"
[^] # Re: quelques points
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 2.
Oui mais dans la réalité, ce n'est pas le cas.
"La première sécurité est la liberté"
[^] # Re: quelques points
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 1.
"Comme si je ne saivais pas qu'on avait inventé les nombres flottant parce que les ordinateurs ne comprennent pas les décimaux du système décimal de manière native"
En plus, c'est complètement faux. Les premières machines savaient compter en base 10 (cf les calculs BCD). Le calcul binaire est simplement plus efficace d'un point de vue hardware (en taille/vitesse/consomation).
C'est plus simple pour ne pas faire de bétises, d'avoir des nombres flottant décimaux pour faire des applications financières, d'ou le support par IBM sur leur grosse machine.
"La première sécurité est la liberté"
[^] # Re: quelques points
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 3.
Oui, mais c'est de la capiloquadrisectomie. β = 10 en hardware ne doit exister que pour le machine Power d'IBM. Sur x86, cela doit être plus simple d'utiliser une bibliothèque numérique de précision étendu.
Par flottant, j'entendais double ou float, dans le sens de C. :)
"La première sécurité est la liberté"
[^] # Re: quelques points
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 2.
Bah non, justement (et là, je peux te prendre pour un con, ce qui n'était le cas avant). Excel s'amuse (s'amusait ?)à écrire et relire ses cases, des chaine de caractère, et donc à faire les conversions pour faire des calculs en flottant en base 2. Je n'ai jamais parler de la raison d'être des flottants, encore heureux que tu saches à quoi cela sert.
Les décimaux flottant existent mais sont très peu utilisé (sauf machine IBM) et je serais curieux de voire comment elles sont supporté sous x86.
"La première sécurité est la liberté"
[^] # Re: quelques points
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 3.
C'est vachement utile d'avoir le chiffre exact ! Avec 1/3, tu va avoir l'air malin pour faire tes sommes. Sinon, tu va en faire quoi de tes 10-15 centimes ? Relis la citation de Linus posté ailleurs, (des fois, pi=3.14 suffit !)
Donc, "et là", et bien on s'en tape, dans la vrai vie on a besoin d'un résultat final en 10-5 euro.
Et il n'y a pas besoin de "tout connaitre", il suffit de se renseigner un minimum sur ce que sont les nombres IEEE754.
"La première sécurité est la liberté"
[^] # Re: quelques points
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 2.
J'ai été un plus loin que ce document qui je connais depuis quelques années.
C'est toujours agaçant de se faire moinser par des gens qui ne comprennent pas ce qu'ils font.
Si ton nombre rentre dans la mantisse, tu as aucun soucis de plus que tu n'en aurais avec un entier. Point à la ligne. C'est si compliqué à comprendre ?
Les arrondis round-to-even te répartissent au mieux les erreurs de calcul garanti à 1/2 LSB par calcul. C'est sûr que si tu t'amuses à mélanger des nombres énorme et tout petit, ton nombre ne rentre plus dans la mantisse et l'exposant rentre en jeu avec toutes les annulations de bits qui vont avec.
Ensuite, les nombres IEEE, c'est de la "grosse merde", car ce n'est pas un corp, ni un anneau, tu ne peux pas faire des maths avec. C'est beaucoup plus simple de faire l'inverse : raisonner avec des nombres ayant un range et une précision à mapper sur des nombres flottants.
"La première sécurité est la liberté"
[^] # Re: quelques points
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 2.
Il y a bien des gens qui font des comptes avec excel sachant qu'excel rajoute une couche intermédiaire de sérialisation/déserialisation vers du décimal (pour rappel 0.1 ne s'exprime pas en nombre flottant).
"La première sécurité est la liberté"
[^] # Re: Partout pareil
Posté par Nicolas Boulay (site web personnel) . En réponse au journal L'Open Source chez OVH. Évalué à 10.
Mais c'est la crise mon bon monsieur, on ne peut pas tout avoir, sur les 10 junior exploité, il y en a qu'1 ou 2 qui partent…
"La première sécurité est la liberté"
[^] # Re: quelques points
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à -6.
C'était purement gratuit. Java doit avoir le même genre de performance que "gcc -O0" et encore, tant que le garbage collector n'entre pas en compte.
"La première sécurité est la liberté"
[^] # Re: quelques points
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 0.
C'est le fait que la mantisse est de 54 (je n'ai pas mis ce chiffre par hasard…) ou 24 bits qui te fait perdre des bis de précision, et cela n'a rien à voir avec le min et le max. Les arrondis de calcul sont assez bien maitrisés.
"La première sécurité est la liberté"
[^] # Re: quelques points
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à -4.
Si tu as sur ton compte de quoi faire des overflow à 54 bits, cela commence à faire pas mal…
"La première sécurité est la liberté"
[^] # Re: quelques points
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à -3.
Si tu as d'énorme besoin de perf, tu ne commences pas par coder en java, et pourtant tout le monde le fait.
"La première sécurité est la liberté"
[^] # Re: Sécurité du DES
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Microsoft : pbpg a-t-il eu une attaque ? "Votre vie privée est notre priorité". Évalué à 3.
Ou dans le générateur aléatoire dans le cas de crypto à clef publique…
"La première sécurité est la liberté"
[^] # Re: non-libre
Posté par Nicolas Boulay (site web personnel) . En réponse au journal une mise en demeure de la part de TF1, pour l'auteur de Captvty. Évalué à 4.
Je pense que les restrictions géographique peuvent être vu comme un DRM, et donc un proxy contourne ce genre de DRM.
Faut-il encore que ce DRM soit "efficace".
"La première sécurité est la liberté"
[^] # Re: quelques points
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 4.
Faire une architecture correct et simple, ou recoder une fonction qui existe déjà pour aller plus vite, ce n'est pas la même démarche. Pas du tout.
Si tu recodes String.split, alors que tu n'utilises cette fonction uniquement pour lire une configuration à l'init, cela ne sert à rien. Par exemple.
_"Quand ton produit est à taille humaine, on est tout à fait capable d'estimer "au pif" si telle ou telle solution est viable et de le POCé/testé en quelques minutes si on a besoin de chiffre." _
Sauf pour le gros grain, mais une fois ton archi faite, en général les estimations aux doigts mouillés des "bottlenecks" de performance, sont en général fausses.
"La première sécurité est la liberté"
[^] # Re: quelques points
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 2.
"Si tu n'as plus junior devant ton nom tu sais aussi commencer à estimer ce qui va coûter cher ou non et le mesurer corriger ASAP pour ne pas cumuler des choses non-rattrapables."
En général, ceux qui disent ça, n'ont plus "junior" devant leur titre, mais par encore "senior" ou "expert".
"La première sécurité est la liberté"
[^] # Re: quelques points
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 5.
Je confirme, il y a 2 moyens de gagner du temps :
- avoir une bonne archi (ne pas faire 2 fois le même boulot couteux, éviter un parcours exponentiel.)
- hacker (refaire les trucs à la main, …)
Le 1er se fait en amont, avec des gains monstrueux à la clef (x1000). Le 2ième te fait gagner x10 maxi.
En général, les optimisations prématurées ne font rien gagné du tout, et rajoutent des bugs. C'est plus difficile de faire marcher un truc le plus simplement du monde (== moins de code, moins de bug, plus petit,…), que de le faire aller plus vite ensuite.
"La première sécurité est la liberté"
[^] # Re: Intérêt de la chose
Posté par Nicolas Boulay (site web personnel) . En réponse au journal A quand la prochaine secousse sismique dans le monde High-Tech ?. Évalué à 2.
y'a pas de "finger gesture" pour remplacer le bouton "home" ?
"La première sécurité est la liberté"