Je trouve ce script qui fonctionne très bien et qui est en accord avec
(n²+n)/2 :
def addition(x):
return sum([i for i in range(0,x+1)])
print (addition(int(input('Fin de la sommielle '))))
Est-ce propre ?
Chercher la concision Í tout prix est-ce un bon pari ? Je suis de
l'ancienne école : j'ai commencé Í programmer avec un Sharp PC1211 qui
avait 1 KO de RAM. On apprenait Í compacter...
Bonjour, Le 24/05/2022 Í 20:50, Benoit Izac a écrit :
Bonjour, Le 24/05/2022 Í 14:33, Alain Ketterlin a écrit dans le message  :
(Ça ne concerne pas Python, mais c'est la même idée qu'un bug qui a été célèbre en Java, dont la correction a consisté Í remplacer (a+b)/2 par a + (b-a)/2.)
Il y a intérêt a avoir un beau commentaire juste Í cÍ´té car il y a fort Í parier que quelqu'un qui passe sur le code sans être courant risque de simplifier (et c'est logique). Question bête : si c'est (a+b) qui provoque le dépassement, pourquoi pas «Â a/2 + b/2 »Â ? Perte de précision ?
Tout Í fait. Avec des calculs sur des entiers : (5 + 7) // 2 = 12 // 2 = 6 (5//2) + (7//2) = 2 + 3 = 5 Note : J'ai mis la notation Python pour du calcul sur les entiers, pas la notation mathématique (qui ne se différencie pas de la notation des calculs sur les réels).
Et pour ma culture, il vient d'o͹ ce bug ?
Ce "bug" n'existe pas avec les versions de Python qui font du calcul sur des entiers de taille indéfinie. Il ne s'agit en fait pas d'un bug au sens que l'on donne Í ce terme habituellement mais du fonctionnement des processeurs depuis l'origine de leur création. Pour simplifier, disons que nous utilisons un processeur 8 bits. Les nombres manipulés par ce processeur, avec des entiers positifs, vont de 0 Í (2**8)-1. En binaire : 00000000 Í 11111111 En décimal : 0 Í 255 Soit une variable V qui contient la valeur 240 (11110000 en binaire). Ajoutons la valeur 16 : V = V + 20 En binaire, cela donne : 11110000 + 00010100 ---------- 100000100 Le résultat est sur 9 bits. Comme le processeur ne sait manipuler que des nombres sur 8 bits, le résultat est tronqué Í 8 bits ce qui donne 4. Pour reprendre le problème d'origine (avec des nombres sur 8 bits) : (130 + 200) / 2 = 300 /2 -> 44 / 2 = 22 ==> !!! BUG !!! 130 + (200-130) / 2 = 130 + 70 / 2 = 165 ==> OK Les processeurs actuels manipulent des nombres sur 32 bits ou 64 bits (voire plus) ce qui permet une plus grande latitude d'utilisation mais le phénomène de troncature est toujours présent. J'espère avoir été clair dans mes explications ;) Bonne journée, Nicolas
Bonjour,
Le 24/05/2022 Í 20:50, Benoit Izac a écrit :
Bonjour,
Le 24/05/2022 Í 14:33, Alain Ketterlin a écrit dans le message
<87zgj7xg89.fsf@universite-de-strasbourg.fr.invalid>Â :
(Ça ne concerne pas Python, mais c'est la même idée qu'un bug qui a été
célèbre en Java, dont la correction a consisté Í remplacer (a+b)/2 par
a + (b-a)/2.)
Il y a intérêt a avoir un beau commentaire juste Í cÍ´té car il y a fort
Í parier que quelqu'un qui passe sur le code sans être courant risque de
simplifier (et c'est logique).
Question bête : si c'est (a+b) qui provoque le dépassement, pourquoi pas
«Â a/2 + b/2 »Â ? Perte de précision ?
Tout Í fait.
Avec des calculs sur des entiers :
(5 + 7) // 2 = 12 // 2 = 6
(5//2) + (7//2) = 2 + 3 = 5
Note : J'ai mis la notation Python pour du calcul sur les entiers, pas
la notation mathématique (qui ne se différencie pas de la notation des
calculs sur les réels).
Et pour ma culture, il vient d'o͹ ce bug ?
Ce "bug" n'existe pas avec les versions de Python qui font du calcul sur
des entiers de taille indéfinie.
Il ne s'agit en fait pas d'un bug au sens que l'on donne Í ce terme
habituellement mais du fonctionnement des processeurs depuis l'origine
de leur création.
Pour simplifier, disons que nous utilisons un processeur 8 bits. Les
nombres manipulés par ce processeur, avec des entiers positifs, vont de
0 Í (2**8)-1.
En binaire : 00000000 Í 11111111
En décimal : 0 Í 255
Soit une variable V qui contient la valeur 240 (11110000 en binaire).
Ajoutons la valeur 16 :
V = V + 20
En binaire, cela donne :
11110000
+ 00010100
----------
100000100
Le résultat est sur 9 bits. Comme le processeur ne sait manipuler que
des nombres sur 8 bits, le résultat est tronqué Í 8 bits ce qui donne 4.
Pour reprendre le problème d'origine (avec des nombres sur 8 bits) :
Les processeurs actuels manipulent des nombres sur 32 bits ou 64 bits
(voire plus) ce qui permet une plus grande latitude d'utilisation mais
le phénomène de troncature est toujours présent.
Bonjour, Le 24/05/2022 Í 20:50, Benoit Izac a écrit :
Bonjour, Le 24/05/2022 Í 14:33, Alain Ketterlin a écrit dans le message  :
(Ça ne concerne pas Python, mais c'est la même idée qu'un bug qui a été célèbre en Java, dont la correction a consisté Í remplacer (a+b)/2 par a + (b-a)/2.)
Il y a intérêt a avoir un beau commentaire juste Í cÍ´té car il y a fort Í parier que quelqu'un qui passe sur le code sans être courant risque de simplifier (et c'est logique). Question bête : si c'est (a+b) qui provoque le dépassement, pourquoi pas «Â a/2 + b/2 »Â ? Perte de précision ?
Tout Í fait. Avec des calculs sur des entiers : (5 + 7) // 2 = 12 // 2 = 6 (5//2) + (7//2) = 2 + 3 = 5 Note : J'ai mis la notation Python pour du calcul sur les entiers, pas la notation mathématique (qui ne se différencie pas de la notation des calculs sur les réels).
Et pour ma culture, il vient d'o͹ ce bug ?
Ce "bug" n'existe pas avec les versions de Python qui font du calcul sur des entiers de taille indéfinie. Il ne s'agit en fait pas d'un bug au sens que l'on donne Í ce terme habituellement mais du fonctionnement des processeurs depuis l'origine de leur création. Pour simplifier, disons que nous utilisons un processeur 8 bits. Les nombres manipulés par ce processeur, avec des entiers positifs, vont de 0 Í (2**8)-1. En binaire : 00000000 Í 11111111 En décimal : 0 Í 255 Soit une variable V qui contient la valeur 240 (11110000 en binaire). Ajoutons la valeur 16 : V = V + 20 En binaire, cela donne : 11110000 + 00010100 ---------- 100000100 Le résultat est sur 9 bits. Comme le processeur ne sait manipuler que des nombres sur 8 bits, le résultat est tronqué Í 8 bits ce qui donne 4. Pour reprendre le problème d'origine (avec des nombres sur 8 bits) : (130 + 200) / 2 = 300 /2 -> 44 / 2 = 22 ==> !!! BUG !!! 130 + (200-130) / 2 = 130 + 70 / 2 = 165 ==> OK Les processeurs actuels manipulent des nombres sur 32 bits ou 64 bits (voire plus) ce qui permet une plus grande latitude d'utilisation mais le phénomène de troncature est toujours présent. J'espère avoir été clair dans mes explications ;) Bonne journée, Nicolas
Olivier Miakinen
Le 24/05/2022 14:33, Alain Ketterlin a écrit :
Cela étant, ta version est mieux adaptée aux contextes o͹ la précision est limitée, parce qu'elle évite les overflows quand n*(n+1) n'est pas représentable mais que n*(n+1)/2 l'est. (Ça ne concerne pas Python, mais c'est la même idée qu'un bug qui a été célèbre en Java, dont la correction a consisté Í remplacer (a+b)/2 par a + (b-a)/2.)
Et lÍ , si on prend pour a et b un très grand nombre positif et un très grand nombre négatif, c'est la correction qui fait planter alors que la version d'origine fonctionne très bien. ;-) -- Olivier Miakinen
Le 24/05/2022 14:33, Alain Ketterlin a écrit :
Cela étant, ta version est mieux adaptée aux contextes o͹ la précision
est limitée, parce qu'elle évite les overflows quand n*(n+1) n'est pas
représentable mais que n*(n+1)/2 l'est.
(Ça ne concerne pas Python, mais c'est la même idée qu'un bug qui a été
célèbre en Java, dont la correction a consisté Í remplacer (a+b)/2 par
a + (b-a)/2.)
Et lÍ , si on prend pour a et b un très grand nombre positif et un très
grand nombre négatif, c'est la correction qui fait planter alors que la
version d'origine fonctionne très bien. ;-)
Cela étant, ta version est mieux adaptée aux contextes o͹ la précision est limitée, parce qu'elle évite les overflows quand n*(n+1) n'est pas représentable mais que n*(n+1)/2 l'est. (Ça ne concerne pas Python, mais c'est la même idée qu'un bug qui a été célèbre en Java, dont la correction a consisté Í remplacer (a+b)/2 par a + (b-a)/2.)
Et lÍ , si on prend pour a et b un très grand nombre positif et un très grand nombre négatif, c'est la correction qui fait planter alors que la version d'origine fonctionne très bien. ;-) -- Olivier Miakinen
Alain Ketterlin
Olivier Miakinen <om+ writes:
Le 24/05/2022 14:33, Alain Ketterlin a écrit :
Cela étant, ta version est mieux adaptée aux contextes o͹ la précision est limitée, parce qu'elle évite les overflows quand n*(n+1) n'est pas représentable mais que n*(n+1)/2 l'est. (Ça ne concerne pas Python, mais c'est la même idée qu'un bug qui a été célèbre en Java, dont la correction a consisté Í remplacer (a+b)/2 par a + (b-a)/2.)
Et lÍ , si on prend pour a et b un très grand nombre positif et un très grand nombre négatif, c'est la correction qui fait planter alors que la version d'origine fonctionne très bien. ;-)
Oui, tu as tout Í fait raison : on ne peut pas avoir le beurre et l'argent du beurre. J'aurais du préciser que le bug auquel je faisais allusion concernait la recherche dichotomique dans un très grand tableau, et donc mettant en jeu des valeurs positives uniquement. Voici une description https://ai.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html Il semble que le rapport de bug original (du temps ou Sun Microsystems s'occupait de Java) est perdu... -- Alain.
Olivier Miakinen <om+news@miakinen.net> writes:
Le 24/05/2022 14:33, Alain Ketterlin a écrit :
Cela étant, ta version est mieux adaptée aux contextes o͹ la précision
est limitée, parce qu'elle évite les overflows quand n*(n+1) n'est pas
représentable mais que n*(n+1)/2 l'est.
(Ça ne concerne pas Python, mais c'est la même idée qu'un bug qui a été
célèbre en Java, dont la correction a consisté Í remplacer (a+b)/2 par
a + (b-a)/2.)
Et lÍ , si on prend pour a et b un très grand nombre positif et un très
grand nombre négatif, c'est la correction qui fait planter alors que la
version d'origine fonctionne très bien. ;-)
Oui, tu as tout Í fait raison : on ne peut pas avoir le beurre et
l'argent du beurre.
J'aurais du préciser que le bug auquel je faisais allusion concernait la
recherche dichotomique dans un très grand tableau, et donc mettant en
jeu des valeurs positives uniquement. Voici une description
Cela étant, ta version est mieux adaptée aux contextes o͹ la précision est limitée, parce qu'elle évite les overflows quand n*(n+1) n'est pas représentable mais que n*(n+1)/2 l'est. (Ça ne concerne pas Python, mais c'est la même idée qu'un bug qui a été célèbre en Java, dont la correction a consisté Í remplacer (a+b)/2 par a + (b-a)/2.)
Et lÍ , si on prend pour a et b un très grand nombre positif et un très grand nombre négatif, c'est la correction qui fait planter alors que la version d'origine fonctionne très bien. ;-)
Oui, tu as tout Í fait raison : on ne peut pas avoir le beurre et l'argent du beurre. J'aurais du préciser que le bug auquel je faisais allusion concernait la recherche dichotomique dans un très grand tableau, et donc mettant en jeu des valeurs positives uniquement. Voici une description https://ai.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html Il semble que le rapport de bug original (du temps ou Sun Microsystems s'occupait de Java) est perdu... -- Alain.
Alain Ketterlin
Benoit Izac writes:
(Ça ne concerne pas Python, mais c'est la même idée qu'un bug qui a été célèbre en Java, dont la correction a consisté Í remplacer (a+b)/2 par a + (b-a)/2.)
Il y a intérêt a avoir un beau commentaire juste Í cÍ´té car il y a fort Í parier que quelqu'un qui passe sur le code sans être courant risque de simplifier (et c'est logique). Question bête : si c'est (a+b) qui provoque le dépassement, pourquoi pas «Â a/2 + b/2 »Â ? Perte de précision ?
Oui, parce que dans ce cas le milieu de 3 et 5 est 3 (3//2 == 1 et 5//2 = 2), ce qui n'est pas utile dans les algos dichotomiques. (Si tu penses Í la division flottante, alors tu as un problème encore plus grave, puisqu'on a alors en général seulement 53 bits de précision -- pour les double IEEE 754. Sans compter les blagues du genre 0.1+0.1+0.1 != 0.3)
Et pour ma culture, il vient d'o͹ ce bug ?
Voici ce que j'ai trouvé de plus ancien sur le bug dans la bibliothèque standard de Java : https://ai.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html -- Alain.
(Ça ne concerne pas Python, mais c'est la même idée qu'un bug qui a été
célèbre en Java, dont la correction a consisté Í remplacer (a+b)/2 par
a + (b-a)/2.)
Il y a intérêt a avoir un beau commentaire juste Í cÍ´té car il y a fort
Í parier que quelqu'un qui passe sur le code sans être courant risque de
simplifier (et c'est logique).
Question bête : si c'est (a+b) qui provoque le dépassement, pourquoi pas
«Â a/2 + b/2 »Â ? Perte de précision ?
Oui, parce que dans ce cas le milieu de 3 et 5 est 3 (3//2 == 1 et 5//2
= 2), ce qui n'est pas utile dans les algos dichotomiques.
(Si tu penses Í la division flottante, alors tu as un problème encore
plus grave, puisqu'on a alors en général seulement 53 bits de précision
-- pour les double IEEE 754. Sans compter les blagues du genre
0.1+0.1+0.1 != 0.3)
Et pour ma culture, il vient d'o͹ ce bug ?
Voici ce que j'ai trouvé de plus ancien sur le bug dans la bibliothèque
standard de Java :
(Ça ne concerne pas Python, mais c'est la même idée qu'un bug qui a été célèbre en Java, dont la correction a consisté Í remplacer (a+b)/2 par a + (b-a)/2.)
Il y a intérêt a avoir un beau commentaire juste Í cÍ´té car il y a fort Í parier que quelqu'un qui passe sur le code sans être courant risque de simplifier (et c'est logique). Question bête : si c'est (a+b) qui provoque le dépassement, pourquoi pas «Â a/2 + b/2 »Â ? Perte de précision ?
Oui, parce que dans ce cas le milieu de 3 et 5 est 3 (3//2 == 1 et 5//2 = 2), ce qui n'est pas utile dans les algos dichotomiques. (Si tu penses Í la division flottante, alors tu as un problème encore plus grave, puisqu'on a alors en général seulement 53 bits de précision -- pour les double IEEE 754. Sans compter les blagues du genre 0.1+0.1+0.1 != 0.3)
Et pour ma culture, il vient d'o͹ ce bug ?
Voici ce que j'ai trouvé de plus ancien sur le bug dans la bibliothèque standard de Java : https://ai.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html -- Alain.
Benoit Izac
Bonjour, Le 25/05/2022 Í 13:41, Alain Ketterlin a écrit dans le message  :
(Ça ne concerne pas Python, mais c'est la même idée qu'un bug qui a été célèbre en Java, dont la correction a consisté Í remplacer (a+b)/2 par a + (b-a)/2.)
Il y a intérêt a avoir un beau commentaire juste Í cÍ´té car il y a fort Í parier que quelqu'un qui passe sur le code sans être courant risque de simplifier (et c'est logique). Question bête : si c'est (a+b) qui provoque le dépassement, pourquoi pas «Â a/2 + b/2 »Â ? Perte de précision ?
Oui, parce que dans ce cas le milieu de 3 et 5 est 3 (3//2 == 1 et 5//2 = 2), ce qui n'est pas utile dans les algos dichotomiques. (Si tu penses Í la division flottante, alors tu as un problème encore plus grave, puisqu'on a alors en général seulement 53 bits de précision -- pour les double IEEE 754. Sans compter les blagues du genre 0.1+0.1+0.1 != 0.3)
En fait, j'étais focalisé sur la division flottante. Pour la division entière c'est plus évident.
Et pour ma culture, il vient d'o͹ ce bug ?
Voici ce que j'ai trouvé de plus ancien sur le bug dans la bibliothèque standard de Java : https://ai.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html
Je vois, du coup les autres qui ont fait des bibliothèques dans d'autres langages (C par exemple) ont rencontrés le même problème (bien avant Java). -- Benoit Izac
Bonjour,
Le 25/05/2022 Í 13:41, Alain Ketterlin a écrit dans le message
<87r14hyh3a.fsf@universite-de-strasbourg.fr.invalid>Â :
(Ça ne concerne pas Python, mais c'est la même idée qu'un bug qui a été
célèbre en Java, dont la correction a consisté Í remplacer (a+b)/2 par
a + (b-a)/2.)
Il y a intérêt a avoir un beau commentaire juste Í cÍ´té car il y a fort
Í parier que quelqu'un qui passe sur le code sans être courant risque de
simplifier (et c'est logique).
Question bête : si c'est (a+b) qui provoque le dépassement, pourquoi pas
«Â a/2 + b/2 »Â ? Perte de précision ?
Oui, parce que dans ce cas le milieu de 3 et 5 est 3 (3//2 == 1 et 5//2
= 2), ce qui n'est pas utile dans les algos dichotomiques.
(Si tu penses Í la division flottante, alors tu as un problème encore
plus grave, puisqu'on a alors en général seulement 53 bits de précision
-- pour les double IEEE 754. Sans compter les blagues du genre
0.1+0.1+0.1 != 0.3)
En fait, j'étais focalisé sur la division flottante. Pour la division
entière c'est plus évident.
Et pour ma culture, il vient d'o͹ ce bug ?
Voici ce que j'ai trouvé de plus ancien sur le bug dans la bibliothèque
standard de Java :
Bonjour, Le 25/05/2022 Í 13:41, Alain Ketterlin a écrit dans le message  :
(Ça ne concerne pas Python, mais c'est la même idée qu'un bug qui a été célèbre en Java, dont la correction a consisté Í remplacer (a+b)/2 par a + (b-a)/2.)
Il y a intérêt a avoir un beau commentaire juste Í cÍ´té car il y a fort Í parier que quelqu'un qui passe sur le code sans être courant risque de simplifier (et c'est logique). Question bête : si c'est (a+b) qui provoque le dépassement, pourquoi pas «Â a/2 + b/2 »Â ? Perte de précision ?
Oui, parce que dans ce cas le milieu de 3 et 5 est 3 (3//2 == 1 et 5//2 = 2), ce qui n'est pas utile dans les algos dichotomiques. (Si tu penses Í la division flottante, alors tu as un problème encore plus grave, puisqu'on a alors en général seulement 53 bits de précision -- pour les double IEEE 754. Sans compter les blagues du genre 0.1+0.1+0.1 != 0.3)
En fait, j'étais focalisé sur la division flottante. Pour la division entière c'est plus évident.
Et pour ma culture, il vient d'o͹ ce bug ?
Voici ce que j'ai trouvé de plus ancien sur le bug dans la bibliothèque standard de Java : https://ai.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html
Je vois, du coup les autres qui ont fait des bibliothèques dans d'autres langages (C par exemple) ont rencontrés le même problème (bien avant Java). -- Benoit Izac
Benoit Izac
Bonjour, Le 25/05/2022 Í 08:51, Nicolas a écrit dans le message <628dd1d5$0$2996$Â :
J'espère avoir été clair dans mes explications ;)
Très clair mais je savais déjÍ ce qu'était un overflow, je voulais juste savoir o͹ était le bug dans la bibliothèque standard de Java. Réponse : binarySearch() du module java.util.Arrays. -- Benoit Izac
Bonjour,
Le 25/05/2022 Í 08:51, Nicolas a écrit dans le message
<628dd1d5$0$2996$426a74cc@news.free.fr>Â :
J'espère avoir été clair dans mes explications ;)
Très clair mais je savais déjÍ ce qu'était un overflow, je voulais juste
savoir o͹ était le bug dans la bibliothèque standard de Java. Réponse :
binarySearch() du module java.util.Arrays.
Bonjour, Le 25/05/2022 Í 08:51, Nicolas a écrit dans le message <628dd1d5$0$2996$Â :
J'espère avoir été clair dans mes explications ;)
Très clair mais je savais déjÍ ce qu'était un overflow, je voulais juste savoir o͹ était le bug dans la bibliothèque standard de Java. Réponse : binarySearch() du module java.util.Arrays. -- Benoit Izac
Nicolas
Le 25/05/2022 Í 14:04, Benoit Izac a écrit :
Bonjour, Le 25/05/2022 Í 08:51, Nicolas a écrit dans le message <628dd1d5$0$2996$Â :
J'espère avoir été clair dans mes explications ;)
Très clair mais je savais déjÍ ce qu'était un overflow, je voulais juste savoir o͹ était le bug dans la bibliothèque standard de Java. Réponse : binarySearch() du module java.util.Arrays.
Ha bah mince alors. Bon, ben mon message pourra éventuellement éclairer quelqu'un d'autre...
Le 25/05/2022 Í 14:04, Benoit Izac a écrit :
Bonjour,
Le 25/05/2022 Í 08:51, Nicolas a écrit dans le message
<628dd1d5$0$2996$426a74cc@news.free.fr>Â :
J'espère avoir été clair dans mes explications ;)
Très clair mais je savais déjÍ ce qu'était un overflow, je voulais juste
savoir o͹ était le bug dans la bibliothèque standard de Java. Réponse :
binarySearch() du module java.util.Arrays.
Ha bah mince alors.
Bon, ben mon message pourra éventuellement éclairer quelqu'un d'autre...
Bonjour, Le 25/05/2022 Í 08:51, Nicolas a écrit dans le message <628dd1d5$0$2996$Â :
J'espère avoir été clair dans mes explications ;)
Très clair mais je savais déjÍ ce qu'était un overflow, je voulais juste savoir o͹ était le bug dans la bibliothèque standard de Java. Réponse : binarySearch() du module java.util.Arrays.
Ha bah mince alors. Bon, ben mon message pourra éventuellement éclairer quelqu'un d'autre...
Alain Ketterlin
Benoit Izac writes:
Voici ce que j'ai trouvé de plus ancien sur le bug dans la bibliothèque standard de Java : https://ai.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html
Je vois, du coup les autres qui ont fait des bibliothèques dans d'autres langages (C par exemple) ont rencontrés le même problème (bien avant Java).
Oh oui. En C le problème est doublé, parce que l'overflow sur le type int provoque un comportement indéfini. Mais de toute façon, le problème s'était posé il y a longtemps, quand les fichiers ont pu avoir une taille supérieure Í 2^31, et donc toutes les tailles et position doivent être de type size_t (avec les variantes POSIX dans sys/types.h). -- Alain.
Je vois, du coup les autres qui ont fait des bibliothèques dans d'autres
langages (C par exemple) ont rencontrés le même problème (bien avant
Java).
Oh oui. En C le problème est doublé, parce que l'overflow sur le type
int provoque un comportement indéfini. Mais de toute façon, le problème
s'était posé il y a longtemps, quand les fichiers ont pu avoir une
taille supérieure Í 2^31, et donc toutes les tailles et position doivent
être de type size_t (avec les variantes POSIX dans sys/types.h).
Voici ce que j'ai trouvé de plus ancien sur le bug dans la bibliothèque standard de Java : https://ai.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html
Je vois, du coup les autres qui ont fait des bibliothèques dans d'autres langages (C par exemple) ont rencontrés le même problème (bien avant Java).
Oh oui. En C le problème est doublé, parce que l'overflow sur le type int provoque un comportement indéfini. Mais de toute façon, le problème s'était posé il y a longtemps, quand les fichiers ont pu avoir une taille supérieure Í 2^31, et donc toutes les tailles et position doivent être de type size_t (avec les variantes POSIX dans sys/types.h). -- Alain.
