Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > fr.comp.sys.mac.programmation > #2081 > unrolled thread

Y a comme un défaut

Back to article view | Back to fr.comp.sys.mac.programmation

Contents

  Y a comme un défaut josephb@nowhere.invalid (Joseph-B) - 2021-12-04 00:54 +0100
    Re: Y a comme un défaut pehache <pehache.7@gmail.com> - 2021-12-04 02:14 +0100
      Re: Y a comme un défaut josephb@nowhere.invalid (Joseph-B) - 2021-12-04 10:14 +0100
        Re: Y a comme un défaut Olivier Miakinen <om+news@miakinen.net> - 2021-12-04 12:48 +0100
          Re: Y a comme un défaut josephb@nowhere.invalid (Joseph-B) - 2021-12-04 13:16 +0100
            Re: Y a comme un défaut Olivier Miakinen <om+news@miakinen.net> - 2021-12-04 13:23 +0100
              Calculette IEEE754 (was: Y a comme un défaut) Olivier Miakinen <om+news@miakinen.net> - 2021-12-04 14:39 +0100
        Re: Y a comme un défaut pehache <pehache.7@gmail.com> - 2021-12-04 13:46 +0100
          Re: Y a comme un défaut josephb@nowhere.invalid (Joseph-B) - 2021-12-04 15:25 +0100
            Re: Y a comme un défaut "M.V." <mv@gmail.com.invalid> - 2021-12-04 14:49 +0000
              Re: Y a comme un défaut josephb@nowhere.invalid (Joseph-B) - 2021-12-04 19:21 +0100
                Re: Y a comme un défaut "M.V." <mv@gmail.com.invalid> - 2021-12-04 18:58 +0000
            Re: Y a comme un défaut Benoit <benoit@com.invalid> - 2021-12-04 16:35 +0000
            Re: Y a comme un défaut pehache <pehache.7@gmail.com> - 2021-12-04 17:39 +0100
              Re: Y a comme un défaut josephb@nowhere.invalid (Joseph-B) - 2021-12-04 19:21 +0100
                Re: Y a comme un défaut pehache <pehache.7@gmail.com> - 2021-12-04 20:28 +0100
                Re: Y a comme un défaut JPP <jpp@findelmundo.invalid> - 2021-12-05 03:24 -0300
        Re: Y a comme un défaut Julien Salort <listes@salort.eu> - 2021-12-05 09:51 +0100
    Re: Y a comme un défaut Fleuger <g4fleurot@free.fr.invalid> - 2021-12-04 08:27 +0000
      Re: Y a comme un défaut Fleuger <g4fleurot@free.fr.invalid> - 2021-12-04 09:00 +0000
        Re: Y a comme un défaut "M.V." <mv@gmail.com.invalid> - 2021-12-04 09:25 +0000
          Re: Y a comme un défaut Fleuger <g4fleurot@free.fr.invalid> - 2021-12-04 13:01 +0000
            Re: Y a comme un défaut "M.V." <mv@gmail.com.invalid> - 2021-12-04 14:27 +0000
      Re: Y a comme un défaut josephb@nowhere.invalid (Joseph-B) - 2021-12-04 10:14 +0100
        Re: Y a comme un défaut "M.V." <mv@gmail.com.invalid> - 2021-12-04 09:30 +0000
          Re: Y a comme un défaut josephb@nowhere.invalid (Joseph-B) - 2021-12-04 12:57 +0100
            Re: Y a comme un défaut pehache <pehache.7@gmail.com> - 2021-12-04 14:16 +0100
            Re: Y a comme un défaut "M.V." <mv@gmail.com.invalid> - 2021-12-04 14:18 +0000
        Re: Y a comme un défaut "M.V." <mv@gmail.com.invalid> - 2021-12-04 10:30 +0000
    Re: Y a comme un défaut "M.V." <mv@gmail.com.invalid> - 2021-12-04 08:45 +0000
    Re: Y a comme un défaut JPP <jpp@findelmundo.invalid> - 2021-12-04 14:16 -0300
    Re: Y a comme un défaut "Néo, l'Élu" <neo-de-matrix@meta-science.fr> - 2022-02-07 10:56 +0000

Page 1 of 2  [1] 2  Next page →

#2081 — Y a comme un défaut

Bonjour,

Sauf erreur de ma part, je viens de faire une découverte déstabilisante.
Des volontaires pour exécuter le petit script que je vous mets en dessous ?
Après le premier test avec la valeur 2.54 pour diviseur
refaites l'essai avec 25.4
Dites-moi si des résultats obtenus chez vous sont conformes ou délirants ?
Je ne me rappelle pas avoir jamais rencontré cette "anomalie" depuis que je tripote appleScript*. 
Le bug provient-il de El Cap ou se perpétue-t-il encore ?
* Ce qui ne veut pas dire qu'elle n'était pas déjà là ?

*******************
set diviseur to 2.54
set serie to {0.254, 2.54, 25.4, 254, 2540}
set restes to {}
set text item delimiters to " - "
set commentaire to "Restes de la division par " & (diviseur as text) & "  de" & linefeed & (serie as string)

repeat with value in serie
   copy (value mod diviseur) to the end of restes
end repeat
display alert (restes's every item as text) message commentaire

*********************

AppleScript operator             Description
mod                        Remainder.
A binary arithmetic operator that divides the number to its left by the number to its right and returns the remainder as its
result.
Class of operands: integer, real    Class of result: integer, real

*********************
pour info, avec 2,54  j'obtiens 
0,254 - 0,0 - 2,54 - 2,54 - 2,54

et avec 25,4
0,254 - 2,54 - 0,0 - 1,42108547152E-14 - 1,42108547152E-13

-- 
J. B.

[toc] | [next] | [standalone]

#2082

Le 04/12/2021 à 00:54, Joseph-B a écrit :
> Bonjour,
> 
> Sauf erreur de ma part, je viens de faire une découverte déstabilisante.
> Des volontaires pour exécuter le petit script que je vous mets en dessous ?
> Après le premier test avec la valeur 2.54 pour diviseur
> refaites l'essai avec 25.4
> Dites-moi si des résultats obtenus chez vous sont conformes ou délirants ?
> Je ne me rappelle pas avoir jamais rencontré cette "anomalie" depuis que je tripote appleScript*.
> Le bug provient-il de El Cap ou se perpétue-t-il encore ?
> * Ce qui ne veut pas dire qu'elle n'était pas déjà là ?
> 
> *******************
> set diviseur to 2.54
> set serie to {0.254, 2.54, 25.4, 254, 2540}
> set restes to {}
> set text item delimiters to " - "
> set commentaire to "Restes de la division par " & (diviseur as text) & "  de" & linefeed & (serie as string)
> 
> repeat with value in serie
>     copy (value mod diviseur) to the end of restes
> end repeat
> display alert (restes's every item as text) message commentaire
> 
> *********************
> 
> AppleScript operator             Description
> mod                        Remainder.
> A binary arithmetic operator that divides the number to its left by the number to its right and returns the remainder as its
> result.
> Class of operands: integer, real    Class of result: integer, real
> 
> *********************
> pour info, avec 2,54  j'obtiens
> 0,254 - 0,0 - 2,54 - 2,54 - 2,54
> 
> et avec 25,4
> 0,254 - 2,54 - 0,0 - 1,42108547152E-14 - 1,42108547152E-13
> 

Il n'y a pas forcément de défaut, calculer des restes en arithmétique 
flottante est forcément casse-gueule quand le résultat de la division 
est censé être une valeur entière. Quand tu écris "2,54" (ou n'importe 
quelle autre valeur) la représentation en machine est une approximation 
de cette valeur, ce n'est pas la valeur exacte (sauf coup de chance).

-- 
"...[la moto] un engin qui par les lois de la physique ne peut pas
freiner en courbe.", SLD sur fr.rec.bricolage
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine

[toc] | [prev] | [next] | [standalone]

#2086

pehache <pehache.7@gmail.com> wrote:

> Il n'y a pas forcément de défaut, calculer des restes en arithmétique
> flottante est forcément casse-gueule quand le résultat de la division
> est censé être une valeur entière. Quand tu écris "2,54" (ou n'importe
> quelle autre valeur) la représentation en machine est une approximation
> de cette valeur, ce n'est pas la valeur exacte (sauf coup de chance).

Ton argument serait recevable, encore que très dérangeant dans les
calculs pratiques, pour  (254 mod 25.4) ==> 1.4210854715202E-14

Là où il n'est plus soutenable c'est pour (254 mod 2.54) ==> 2.54

Si le copro-arithmétique du Mac n'a pas été écrit pour retourner la
valeur correcte (± epsilon d'après ton argument) de la FONCTION "RESTE"
d'une divison, il y a un GROS SOUCI !! 
Pour preuve, toujours dans l'éditeur de script si j'essaie cette fois en
javascript

254 % 2.54 ==> 2.5399999999999965
ou 
7412 % 74.12 ==> 74.11999999999955

résultats totalement inacceptables, et je ne me satisfais pas vraiment
que 
7412 % 7.412 ==> 7.815970093361102e-14
tende vers zéro

d'ailleurs, voici en dessous une fonction Modulo() écrite en
AppleScript, qui fort heureusement retourne "ZÉRO" comme reste de  (par
exemple…)
254 par 2.54 ou 
789452.18 par 789.45218
ou toutes autres valeurs du domaine de précison du copro.

on Modulo(dividende, diviseur)
   set partieEntiere to (dividende div diviseur)
   set reste to (dividende - (partieEntiere * diviseur))
   return reste
end Modulo

-- 
J. B.

[toc] | [prev] | [next] | [standalone]

#2091

Bonjour,

Le 04/12/2021 10:14, Joseph-B a écrit :
> pehache <pehache.7@gmail.com> wrote:
> 
>> Il n'y a pas forcément de défaut, calculer des restes en arithmétique
>> flottante est forcément casse-gueule quand le résultat de la division
>> est censé être une valeur entière. Quand tu écris "2,54" (ou n'importe
>> quelle autre valeur) la représentation en machine est une approximation
>> de cette valeur, ce n'est pas la valeur exacte (sauf coup de chance).
> 
> Ton argument serait recevable, encore que très dérangeant dans les
> calculs pratiques, pour  (254 mod 25.4) ==> 1.4210854715202E-14

L'argument *est* recevable et *est* dérangeant mais c'est un problème
très connu depuis toujours avec les représentations des nombres en
binaire avec virgule flottante.

La solution consiste à travailler en nombres entiers dans une unité de
mesure suffisamment petite pour tous tes besoins. Par exemple, si tu
as besoin de représenter exactement 2,54 cm, il faut que ton unité de
mesure soit aussi petite que le dixième de millimètre. Pour être sûr
de ne pas avor de problème, tu peux même travailler au micron (non, je
n'ai pas parlé de variant).

Tu coup, tes 2,54 cm par pouce, ça devient 25400 µm par pouce et c'est
tout à fait gérable en nombres entiers.

> Là où il n'est plus soutenable c'est pour (254 mod 2.54) ==> 2.54

C'est la même chose. La valeur la plus proche de zéro doit être un
nombre négatif, probablement quelque chose comme -1.4210854715202E-14.
Pour en faire un nombre entre 0 et 2,54 le résultat calculé est alors
2,54 - 1.4210854715202E-14, et à l'affichage ça donne 2,54.

> Si le copro-arithmétique du Mac n'a pas été écrit pour retourner la
> valeur correcte (± epsilon d'après ton argument) de la FONCTION "RESTE"
> d'une divison, il y a un GROS SOUCI !! 

Le Mac n'est pas en cause, ce qui est en cause est inhérent aux calculs
en nombres flottants binaires, probablement IEEE 754. Passe en nombres
entiers et tes problèmes disparaitront.

> Pour preuve, toujours dans l'éditeur de script si j'essaie cette fois en
> javascript
> 
> 254 % 2.54 ==> 2.5399999999999965
> ou 
> 7412 % 74.12 ==> 74.11999999999955

C'est la même chose.

> résultats totalement inacceptables

C'est à toi de ne *pas* les accepter, en utilisant des nombres entiers.
Ou alors il te faut une représentation décimale et non pas binaire, mais
je ne sais pas si c'est utilisable simplement dans tes programmes.


-- 
Olivier Miakinen

[toc] | [prev] | [next] | [standalone]

#2093

Olivier Miakinen <om+news@miakinen.net> wrote:

> C'est à toi de ne *pas* les accepter, en utilisant des nombres entiers.

Tu me donnes des ordres ou c'est une formule réthorique ?
Dans tous les cas l'argument est irrecevable et je n'ai pas envie
d'épiloguer. 
Merci de tes efforts, mais au mieux ça me donne à penser au sketch du
tailleur et du costume de Fernand Raynaud.

-- 
J. B.

[toc] | [prev] | [next] | [standalone]

#2094

Le 04/12/2021 13:16, Joseph-B a écrit :
> 
>> C'est à toi de ne *pas* les accepter, en utilisant des nombres entiers.
> 
> Tu me donnes des ordres ou c'est une formule réthorique ?

Ah non, ça c'est seulement si tu veux des résultats justes. Si tu
acceptes d'avoir des résultats aléatoirement faux, tu peux continuer
comme avant.

Pour info, le nombre 2,54 n'est pas représentable dans un flottant.

Les nombres les plus proches sont :
2 + 1215971899390033/2^51 =~ 2,539999999999999591437926
2 + 1215971899390034/2^51 =~ 2,540000000000000035527136

Je précise que ma réponse n'est pas liée au Mac, d'ailleurs je n'ai
jamais utilisé un Mac de ma vie (seulement des Windows et des Linux
depuis des décennies, et avant un Apple 2).

-- 
Olivier Miakinen

[toc] | [prev] | [next] | [standalone]

#2098 — Calculette IEEE754 (was: Y a comme un défaut)

Le 04/12/2021 13:23, j'écrivais :
> 
> Pour info, le nombre 2,54 n'est pas représentable dans un flottant.
> 
> Les nombres les plus proches sont :
> 2 + 1215971899390033/2^51 =~ 2,539999999999999591437926
> 2 + 1215971899390034/2^51 =~ 2,540000000000000035527136

Pour ceux que ça amuse, une petite calculette IEEE754 :
<http://www.miakinen.net/vrac/ieee754/>

Il n'y a pas de doc, sauf celle intégrée aux scripts en Javascript :
<http://www.miakinen.net/vrac/ieee754/ieee754.js>
<http://www.miakinen.net/vrac/ieee754/ieee754-test.js>

Cela dit, il suffit de savoir que « x » est le nombre IEEE754 à manipuler,
et que « n » est un nombre entier qui peut servir à des manipulations sur
le nombre « x » en fonction des boutons disponibles.

Les nombres IEEE754 sont bien sûr ceux de Javascript, c'est-à-dire codés
sur 64 bits (1 bit de signe, 11 bits d'exposant et 52 bits de mantisse).


Sans surprise, le nombre 1215971899390034 est celui qui apparaît comme
mantisse (plus exactement comme partie fractionnaire de la mantisse)
quand on donne à x la valeur 2.54.

-- 
Olivier Miakinen

[toc] | [prev] | [next] | [standalone]

#2095

Le 04/12/2021 à 10:14, Joseph-B a écrit :
> pehache <pehache.7@gmail.com> wrote:
> 
>> Il n'y a pas forcément de défaut, calculer des restes en arithmétique
>> flottante est forcément casse-gueule quand le résultat de la division
>> est censé être une valeur entière. Quand tu écris "2,54" (ou n'importe
>> quelle autre valeur) la représentation en machine est une approximation
>> de cette valeur, ce n'est pas la valeur exacte (sauf coup de chance).
> 
> Ton argument serait recevable, encore que très dérangeant dans les
> calculs pratiques, pour  (254 mod 25.4) ==> 1.4210854715202E-14

Il n'est pas dérangeant à partir du moment où on a conscience de ce qui 
se passe à bas niveau en machine pour les calculs sur des flottants, et 
qu'on en tient compte quand on écrit du code.

Le truc classique c'est (1+1e-16)-1 dont le résultat est zéro 
exactement, parce que la représentation d'un flottant 64 bits ne peut 
pas différencier (1+1e-16) de 1


> 
> Là où il n'est plus soutenable c'est pour (254 mod 2.54) ==> 2.54

Si, car comme l'a expliqué OM c'est exactement le même problème. Suivant 
que le résultat de la division flottante tombe juste au-dessus ou juste 
au-dessous de la valeur entière à cause des approximations inhérentes au 
calculs en précision limitée, ça va changer le résultat du tout au tout.

Quand tu écris 254/2.54, ce qui se passe en machine c'est
(254+eps1)/(2.54+eps2)
En première approximation (mathématique celle-là) ça donne
100 + (eps1-100*eps2)/2.54

Suivant les valeurs de eps1 et eps2 (qui peuvent être >0 ou <0) le 
résultat peut être juste supérieur ou juste inférieur à 100, et de façon 
non prédictible (*). Donc en prenant la partie entière ça va donner 100 
ou 99. Si c'est un problème il faut que tu écrives ton code différemment.

(*) mais quand même reproductible :)... Du moins tant qu'on ne change 
pas de machine.

> 
> Si le copro-arithmétique du Mac n'a pas été écrit pour retourner la
> valeur correcte (± epsilon d'après ton argument) de la FONCTION "RESTE"
> d'une divison, il y a un GROS SOUCI !!

Je ne suis pas certain qu'il existe une telle fonction câblée en 
hardware dans le processeur pour les flottants. Elle doit être logicielle.

> Pour preuve, toujours dans l'éditeur de script si j'essaie cette fois en
> javascript
> 
> 254 % 2.54 ==> 2.5399999999999965
> ou
> 7412 % 74.12 ==> 74.11999999999955
> 
> résultats totalement inacceptables, et je ne me satisfais pas vraiment
> que
> 7412 % 7.412 ==> 7.815970093361102e-14
> tende vers zéro
> 
> d'ailleurs, voici en dessous une fonction Modulo() écrite en
> AppleScript, qui fort heureusement retourne "ZÉRO" comme reste de  (par
> exemple…)
> 254 par 2.54 ou
> 789452.18 par 789.45218
> ou toutes autres valeurs du domaine de précison du copro.
> 
> on Modulo(dividende, diviseur)
>     set partieEntiere to (dividende div diviseur)
>     set reste to (dividende - (partieEntiere * diviseur))
>     return reste
> end Modulo
> 

Dans ce cas utilise cette fonction écrite par tes soins si tu estimes 
qu'elle se comporte mieux que la fonction proposée par le langage. Ceci 
étant ça reste de l'arithmétique flottante, et *rien* ne peut garantir 
que le résultat sera *toujours* conforme à ce que tu attends.

Comme l'a dit OM la seule façon de garantir le résultat que tu attends 
est de passer en arithmétique entière.

-- 
"...[la moto] un engin qui par les lois de la physique ne peut pas
freiner en courbe.", SLD sur fr.rec.bricolage
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine

[toc] | [prev] | [next] | [standalone]

#2100

pehache <pehache.7@gmail.com> wrote:

> Le truc classique c'est (1+1e-16)-1 dont le résultat est zéro 
> exactement, parce que la représentation d'un flottant 64 bits ne peut
> pas différencier (1+1e-16) de 1

Je me moque éperdument que les limites du calcul en virgule flottante à
e-14 ou e-16 les confondent à zéro, ce que vous n'avez pas l'air de
comprendre c'est qu'il n'est pas admissible de la part d'ingénieurs de
laisser faire en sorte que leur bijou d'intelligence et de science ne
soit pas cohérent avec la réalité triviale.

 Pour reprendre l'exemple de MV,
(2.001 -2) avec une calculette à moins d'un euro retournera 0,001
Ouais, mais c'est moche et trivial tandis que 
(2.001 -2) dans AppleScript retournera 9.9999999999989E-4
et ça c'est dû à une science tellement supérieure qu'elle devrait clore
le bec des ignorants même si c'est en contradiction avec l'enseignement
de l'arithmétique élémentaire.
Mac, PC, Supercalculateur ou calculette à 2 balles, ne sont que des put…
d'outils./
Il n'est pas acceptable que ce soit à l'utilisateur lambda dans le cadre
de son utilisation basique (2.001 -2 sur un Mac) de ne s'en prendre qu'à
lui même parce qu'il a eu l'impudence de soumettre un calcul dont le
résultat affiché (pour "légitime" qu'il soit) est en contradiction avec
ce que ces pauvres ignorantins de maîtres d'école ont passé des vies à
enseigner.

D'après toi et OM ce serait au clampin utilisateur d'établir des
procédures de tests de validité des librairies mathématiques que les
ingénieurs d'Apple n'ont pas prix la peine de faire ?

Si oui, restons-en là, nos points de vue sont irréconciliables.

-- 
J. B.

[toc] | [prev] | [next] | [standalone]

#2103

[Supersedes: <sofuv0$lof$1@dont-email.me>]

Le 4 décembre 2021 à 15 h 25, Joseph-B a tenu les propos suivants :

> Pour reprendre l'exemple de MV,
> (2.001 -2) avec une calculette à moins d'un euro retournera 0,001
> Ouais, mais c'est moche et trivial tandis que 
> (2.001 -2) dans AppleScript retournera 9.9999999999989E-4

En même temps on n'est pas loin de la vérité mathématique car, si tu te
rappelles tes cours de math du siècle dernier :
1 = 0,99999999999999999999999999999999… (ad libitum) ! ;-)

Ceci dit, je partage ton courroux (coucou) surtout quand je vois le
script que j'ai dû pondre pour obtenir un résultat correct (jusqu'à
preuve du contraire) pour éviter des résultats à la mords-moi le nœud.
J'en suis là :
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
set diviseur to 25.4
set serie to {0.254, 2.54, 25.4001, 254, 2540}
set restes to {}
set text item delimiters to " - "
set commentaire to "Restes de la division par " & (diviseur as text) & "  de" & linefeed & (serie as string)

set exp0 to exp_value(diviseur)
log "exp0 : " & exp0

repeat with value in serie
  set exp1 to exp_value(value)
  log "exp1 : " & exp1
  
-- pour transformer 25.4 et 25.4001 par exemple en 254000 et 254001
  if exp1 ≥ exp0 then
    set exp to exp1
  else
    set exp to exp0
  end if
  
  set new_value to (value * (10 ^ exp)) as integer
  
  set new_diviseur to (diviseur * (10 ^ exp)) as integer
  
  set reste to (new_value mod new_diviseur) / (10 ^ exp)
  if reste = (reste as integer) then set reste to reste as integer
  
  copy reste to the end of restes
end repeat
set text item delimiters to " - "
display alert (restes's every item as text) message commentaire

-- combien de chiffres dans la partie décimale
on exp_value(nombre)
  set nombre_str to nombre as string
  log "nombre_str : " & nombre_str
  set text item delimiters to ","
  try
    set exp to count characters of second text item of nombre_str
  on error
    set exp to 0
  end try
  return exp
end exp_value
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
-- 
Michel VAUQUOIS - <http://michelvauquois.fr>

[toc] | [prev] | [next] | [standalone]

#2108

M.V. <mv@gmail.com.invalid> wrote:

> Ceci dit, je partage ton courroux (coucou) surtout quand je vois le
> script que j'ai dû pondre pour obtenir un résultat correct (jusqu'à
> preuve du contraire) pour éviter des résultats à la mords-moi le nœud.
> J'en suis là :
Snip du script qui fonctionne… jusqu'à un certain point : 

set serie to {0.254, 2.54, 25.4001, 254, 2540}
Tu auras beau rentrer la valeur en integer, à partir d'un moment
AppleScript va décider de passer en notation exponentielle et ça va
capoter.
Mets 254000000 en dernier et regarde ce qu'il se passe. 
Pire si tu mets directement 2.54E+4 au lieu de 25400.

Je n'ai pas cherché à savoir si ça vient de ta procédure, mais c'est
probablement encore une histoire de tournevis Vs marteau, donc c'est ta
faute ;-)


-- 
J. B.

[toc] | [prev] | [next] | [standalone]

#2109

Le 4 décembre 2021 à 19 h 21, Joseph-B a tenu les propos suivants :

> Je n'ai pas cherché à savoir si ça vient de ta procédure

Pour 254000000 et 2.54E+4 ça vient de ma procédure.
Mais si je la modifie pour que ça fonctionne, alors pour 254 j'obtiens
9,999999999709E-5 !

Je m'arrête là : si les virgules continuent de flotter, elles vont se
transformer en verglas au contact des sols gelés de par chez moi.

Bonne soirée.
-- 
Michel VAUQUOIS - <http://michelvauquois.fr>

[toc] | [prev] | [next] | [standalone]

#2104

Avec enthousiasme, le 4 décembre 2021 à 15:25, Joseph-B écrivit :

>  Pour reprendre l'exemple de MV,
> (2.001 -2) avec une calculette à moins d'un euro retournera 0,001
> Ouais, mais c'est moche et trivial tandis que 
> (2.001 -2) dans AppleScript retournera 9.9999999999989E-4

Moi c’est 0.0009999999999998899.

Pas loin de 1/3000 * 3

-- 
Ce qui manque aux Français, c'est une solide culture historique pour 
comprendre les grands enjeux du monde actuel, mais c'est pas avec notre 
président actuel Sarkozy qu'on va avancer. -+- GR en août 2021 dans
« L’histoire c’est il y a longtemps. » -+-

[toc] | [prev] | [next] | [standalone]

#2105

Le 04/12/2021 à 15:25, Joseph-B a écrit :
> pehache <pehache.7@gmail.com> wrote:
> 
>> Le truc classique c'est (1+1e-16)-1 dont le résultat est zéro
>> exactement, parce que la représentation d'un flottant 64 bits ne peut
>> pas différencier (1+1e-16) de 1
> 
> Je me moque éperdument que les limites du calcul en virgule flottante à
> e-14 ou e-16 les confondent à zéro, 

Si tu n'essayes pas de comprendre ça, la discussion ne peut en effet pas 
aller bien loin.

> ce que vous n'avez pas l'air de
> comprendre c'est qu'il n'est pas admissible de la part d'ingénieurs de
> laisser faire en sorte que leur bijou d'intelligence et de science ne
> soit pas cohérent avec la réalité triviale.

Les bijoux en question sont tout à fait cohérents avec la "réalité 
triviale" à condition d'être utilisés avec discernement. En l'occurrence 
ce que tu considères comme étant ta "réalité triviale" est plus du 
ressort des calculs sur des nombres entiers ou en virgule fixe qu'en 
virgule flottante. A chaque problème le bon outil, on peut arriver à 
planter un clou avec un tournevis mais ce n'est pas top.

Je te signale qu'à ma connaissance tout ce qui est informatique 
financière/comptable n'utilise pas les calculs en virgule flottante mais 
en virgule fixe, justement pour ne pas tomber dans les problèmes 
d'arrondis inhérents à la représentation en virgule flottante. Certains 
langage ont des types en virgule fixe (typiquement le COBOL), et 
certains systèmes informatiques avaient même le support de la virgule 
fixe en hardware.

> 
>   Pour reprendre l'exemple de MV,
> (2.001 -2) avec une calculette à moins d'un euro retournera 0,001
> Ouais, mais c'est moche et trivial tandis que
> (2.001 -2) dans AppleScript retournera 9.9999999999989E-4

Historiquement, les calculettes basiques travaillaient en virgule fixe, 
justement. En virgule fixe, 2.001 ou 2.54 ont une représentation exacte.

Après, même quand un système/langage travaille en virgule flottante il 
ne faut pas confondre ce qu'il affiche et ce qu'il représente en 
interne. Par exemple dans Octave (Matlab-like) :

 >> (2.001-2)
ans =    1.0000e-03
 >> (2.001-2)*1e18
ans =    1.0000e+15
 >> int64((2.001-2)*1e18)
ans = 999999999999890

Il peut y avoir une mise en forme du résultat pour que ceux qui seraient 
choqués par le résultat informatique ne crient pas au scandale :)

> et ça c'est dû à une science tellement supérieure qu'elle devrait clore
> le bec des ignorants même si c'est en contradiction avec l'enseignement
> de l'arithmétique élémentaire.

Le truc c'est *jamais* personne n'a prétendu que l'arithmétique en 
virgule flottante était de l'arithmétique exacte. Dans l'enseignement du 
calcul numérique sur ordinateur c'est une des premières choses qu'on 
apprend (ou qu'on devrait apprendre) : en virgule flottante on fait des 
calculs FAUX. Tout l'enjeu est alors de maîtriser les pertes de 
précision au cours des calcul (car les erreurs d'arrondis ont la 
désagréable propriété de se cumuler et même parfois d'exploser), et de 
savoir écrire du code de façon à les minimiser.


> Mac, PC, Supercalculateur ou calculette à 2 balles, ne sont que des put…
> d'outils./
> Il n'est pas acceptable que ce soit à l'utilisateur lambda dans le cadre
> de son utilisation basique (2.001 -2 sur un Mac) de ne s'en prendre qu'à
> lui même parce qu'il a eu l'impudence de soumettre un calcul dont le
> résultat affiché (pour "légitime" qu'il soit) est en contradiction avec
> ce que ces pauvres ignorantins de maîtres d'école ont passé des vies à
> enseigner.

"A chaque problème le bon outil". Si tu plante ton clou avec un 
tournevis ce n'est pas au fabricant du tournevis qu'il faut t'en prendre 
si ça ne va pas.

> 
> D'après toi et OM ce serait au clampin utilisateur d'établir des
> procédures de tests de validité des librairies mathématiques que les
> ingénieurs d'Apple n'ont pas prix la peine de faire ?

Non mais déconner tu penses vraiment que les ingénieurs d'Apple sont 
idiots à ce point ?


-- 
"...[la moto] un engin qui par les lois de la physique ne peut pas
freiner en courbe.", SLD sur fr.rec.bricolage
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine

[toc] | [prev] | [next] | [standalone]

#2107

pehache <pehache.7@gmail.com> wrote:

> 
> "A chaque problème le bon outil". Si tu plante ton clou avec un 
> tournevis ce n'est pas au fabricant du tournevis qu'il faut t'en prendre
> si ça ne va pas.

Aussi longtemps qu'Applescript ne laissera pas le choix de travailler en
floatting-point ou fixed-point, obligeant à des contorsions insensées
pour s'assurer qu'une opération aussi banale que 2.001-2 = 0.001 est
réalisée, 
ou pour ne pas se retrouver avec le reste égal au diviseur dans une
fonction de division native de l'OS, 
j'estimerai à bon droit que l'outil est partiellement défaillant et que
la responsabilité ne m'en incombe pas.

-- 
J. B.

[toc] | [prev] | [next] | [standalone]

#2110

Le 04/12/2021 à 19:21, Joseph-B a écrit :
> pehache <pehache.7@gmail.com> wrote:
> 
>>
>> "A chaque problème le bon outil". Si tu plante ton clou avec un
>> tournevis ce n'est pas au fabricant du tournevis qu'il faut t'en prendre
>> si ça ne va pas.
> 
> Aussi longtemps qu'Applescript ne laissera pas le choix de travailler en
> floatting-point ou fixed-point, 

A part les outils dédiés à la compta/finance comme dit plus haut, les 
langages proposant des types fixed-point ne courent pas les rues. Sans 
vouloir trop m'avancer ça n'a l'air présent en natif dans aucun des 
langages de programmation "populaires", signe que le besoin est très limité.

> obligeant à des contorsions insensées
> pour s'assurer qu'une opération aussi banale que 2.001-2 = 0.001 est
> réalisée,
> ou pour ne pas se retrouver avec le reste égal au diviseur dans une
> fonction de division native de l'OS,

Un simple changement d'unité est la solution dans la plupart des cas. 
Sacré contorsion en effet !

> j'estimerai à bon droit que l'outil est partiellement défaillant et que
> la responsabilité ne m'en incombe pas.

Oh tu peux bien estimer tout ce que tu veux, y compris qu'un tournevis 
est défaillant parce que ça ne va pas pour planter un clou.

(me voilà en train de défendre AS alors que je trouve plein de défauts à 
ce langage par ailleurs...)


-- 
"...[la moto] un engin qui par les lois de la physique ne peut pas
freiner en courbe.", SLD sur fr.rec.bricolage
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine

[toc] | [prev] | [next] | [standalone]

#2111

On 04/12/21 15:21, Joseph-B wrote:
> Aussi longtemps qu'Applescript ne laissera pas le choix de travailler en
> floatting-point ou fixed-point, obligeant à des contorsions insensées
> pour s'assurer qu'une opération aussi banale que 2.001-2 = 0.001 est
> réalisée,

La Calculette de HSierra donne bien 2.001-2 = 0.001
Idem pour PCalc et même Excel  :-)

(Ma) conclusion : le problème évoqué par JB est bien du côté d'AppleScript.

[toc] | [prev] | [next] | [standalone]

#2112

Le 04/12/2021 à 10:14, Joseph-B a écrit :

>> Il n'y a pas forcément de défaut, calculer des restes en arithmétique
>> flottante est forcément casse-gueule quand le résultat de la division
>> est censé être une valeur entière. Quand tu écris "2,54" (ou n'importe
>> quelle autre valeur) la représentation en machine est une approximation
>> de cette valeur, ce n'est pas la valeur exacte (sauf coup de chance).
> 
> Ton argument serait recevable, encore que très dérangeant dans les
> calculs pratiques, pour  (254 mod 25.4) ==> 1.4210854715202E-14
> 
> Là où il n'est plus soutenable c'est pour (254 mod 2.54) ==> 2.54

C'est un problème de IEEE-754.
On le voit par exemple en Python, si on compare le résultat entre le 
calcul avec des flottants natifs, ou avec des décimaux:

% python
Python 3.10.0 (default, Nov 12 2021, 18:16:44) [Clang 13.0.0 
(clang-1300.0.29.3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> 254 % 2.54
2.5399999999999965
 >>> from decimal import Decimal
 >>> Decimal("254") % Decimal("2.54")
Decimal('0.00')

Bien sûr, les décimaux peuvent avoir le même genre de problèmes. Mais la 
différence c'est que les nombres qui s'écrivent exactement en décimal 
seront représentés exactement. Pour les flottants, il faut que la 
représentation en base 2 soit exacte.

[toc] | [prev] | [next] | [standalone]

#2083

Le 4 décembre 2021 à 00:54, Joseph-B a écrit ceci :

> pour info, avec 2,54  j'obtiens 
> 0,254 - 0,0 - 2,54 - 2,54 - 2,54
>
> et avec 25,4
> 0,254 - 2,54 - 0,0 - 1,42108547152E-14 - 1,42108547152E-13

Bonjour Joseph,

Mojave,

Restes de la division par 2,54
0,254 - 0,0 - 2,54 - 2,54 - 2,54

Restes de la division par 25,4
0,254 - 2,54 - 0,0 - 1,42108547152E-14 - 1,42108547152E-13

Le défaut provient du Système
Même calcul avec Excel :
Nombre  0,254  2,54  25,4  254  2540
Diviseur  2,54  2,54  2,54  2,54  2,54
Reste  0,254  0  2,54  2,54  2,54
                    
Nombre  0,254  2,54  25,4  254  2540
Diviseur  25,4  25,4  25,4  25,4  25,4
Reste  0,254  2,54  0  1,42109E-14  1,42109E-13

Résultats identiques avec BigSur

En revanche, , si j'utilise la formule =CONVERT(A2;"cm";"in") puis B2,
etc, j'obtiens des nombres entiers, 
0,254  2,54  25,4  254  2540
0,1  1  10  100  1000
donc pas de restes. (sauf pour 0,1 bien sûr) qui correspond à 1/10ème.

Il  faudrait que tu trouves l'équivalent de cette formule en AS
-- 
Gérard FLEUROT

[toc] | [prev] | [next] | [standalone]

#2085

Le 4 décembre 2021 à 09:27, Fleuger a écrit ceci :

> Il  faudrait que tu trouves l'équivalent de cette formule en AS

++++++++++
set diviseur to 2.54
set serie to {0.254, 2.54, 25.4, 254, 2540}
set resultat to {}
set text item delimiters to " - "
set commentaire to "Résultat de la division par " & (diviseur as text) &
"  de" & linefeed & (serie as string)

repeat with value in serie
  copy (value div diviseur) to the end of resultat
end repeat
display alert (resultat's every item as text) message commentaire
+++++++++++
donne :
display alert "0 - 1 - 10 - 100 - 1000" message "Résultat de la division
par 2,54  de
0,254 - 2,54 - 25,4 - 254 - 2540"

C'est bien la formule mod qui crée ce résultat.
-- 
Gérard FLEUROT

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | fr.comp.sys.mac.programmation

csiph-web