Calcul de tableurs avec (au moins) la précision D'un double C

j'ai fait quelques calculs pour planifier une meilleure mise en oeuvre de mon tamis prime quand j'ai remarqué que le tableur Libre Office montrait les mauvaises valeurs pour les nombres bien en dessous de 2^53, qui est la limite pour des calculs d'entiers précis dans FoxPro et une multitude d'autres langues qui utilisent intérieurement un C double (A. K. A. IEEE 754 double).

quelques vérifications rapides ont montré des résultats erronés pour des nombres aussi bas que 2^50. Ce qui est pire, l'feuilletée morceau de le logiciel n'a pas averti qu'il fonctionnait au-delà de ses limites opérationnelles et que les valeurs affichées n'étaient qu'approximatives (même si les bonnes valeurs étaient entrées manuellement). Je suppose qu'ils ont pensé que ce qui est assez bon pour les points de vente comme Excel alors doit être assez bon pour eux (mais ils auraient dû l'avoir nommé "Guesstimate" à la place de "Calc" alors).

de toute façon, est - il possible de mettre le tableur dans une sorte de mode précis qui donne au moins la précision d'un double, et / ou le faire afficher une sorte d'avertissement quand un calcul dépasse ses capacités numériques?

ou y a-t-il une autre feuille de calcul disponible qui convient aux programmeurs à une époque où même les téléphones et les grille-pain sont alimentés par des puces 64 bits?

Background: dans ce cas particulier, le besoin de précision se pose parce que l'exactitude des formules est vérifiée en comparant certaines colonnes de résultats avec des listes de nombres bien connus (comme les nombre de nombres premiers jusqu'à 2 ^ k, OEIS) ou avec des nombres dérivés du code instrumenté. L'idée est de corriger les formules en les vérifiant pour des fourchettes réalisables - jusqu'à quelque part entre 2^32 et 2^40 - et ensuite d'utiliser ces formules pour étudier le comportement pour des fourchettes jusqu'à 2^64 (où il est impossible d'obtenir une image complète en effectuant des tests exhaustifs).

P.S.: j'ai trouvé que le problème a été analysé largement dans sur L'exactitude numérique des tableurs ( pdf). Il semble que gnumeric supporte un peu mieux que les autres mais c'est plus un cas de borgne parmi les aveugles que de muster vraiment de passage; en outre, il n'est pas disponible pour Windows et il faudrait donc une VM Linux pour démarrer sur la plate-forme que je développe sur et pour...

UPDATE/WORKAROUNDAROUND

Jusqu'à 2^49 il n'y a pas de problèmes, il est donc possible de travailler normalement. C'est suffisant pour avoir une idée précise des choses. Dans les tableaux finaux, les grands nombres et les résultats de haute précision (calculés ailleurs) sont entrés sous forme de texte pré-formaté (ou plutôt importé/collé) de sorte que Calc ne peut pas bork l'affichage. Les nombres peuvent encore être référencés en appliquant le <!-La précision interne est tout à fait suffisante pour de nombreux calculs en ligne, en particulier pour le graphage.

l'image ci-dessous montre ce que je posté dans un des commentaires, qui est que la précision interne est plus élevé que ce qui est affiché. Comment sommes-nous censés découvrir alors quelles sont les valeurs réelles si le programme ne les montre pas? Jouer avec l'addition / soustraction de petites valeurs, regarder les changements, créer et tester des hypothèses concernant la relation des valeurs réelles, comportement supposé d'arrondissement et valeurs affichées? L'esprit véritablement saisi de vertige.

je suis en offrant un prime pour ce qui suit:

• un moyen pratique de restaurer Calc à un comportement sain dans le sens de WYSIWI (ce que vous voyez est ce qui est à l'intérieur, ou plutôt si C'est à l'intérieur alors il peut être affiché) sans réduire la précision interne et sans bifurquer tout l'arbre source sanglant et le fixer soi-même

• un pointeur vers une feuille de calcul avec plus de précision que IEEE 754 double (de préférence une précision arbitraire, comme GP / PARI mais sous forme de tableur) c'est du domaine public ou du shareware; un truc en ligne/cloud serait acceptable

la raison pour le premier point est double: d'une part, c'est une nuisance sanglante quand la précision du tableur est inférieure à l'universel IEEE 754 double parce que cela signifie que l'expérience/connaissances concernant l'exactitude/précision/stabilité à ce niveau de référence n'est pas reporté. Pour un autre, c'est une nuisance encore plus grande si nous n'avons plus confiance que les valeurs affichées sont correctes, même lorsque nous savons que les valeurs réelles sont.

la raison du second point est le simple fait qu'il est plutôt encombrant d'avoir à script des choses dans un autre programme pour calculer des choses à haute précision ou avec des bignums, ou d'avoir à éditer/compiler/exécuter des programmes pour le but. Outre le fractionnement délicat dans une feuille de calcul et un tas de scripts ou de fichiers source, il serait plus naturel et confortable de travailler juste à l'intérieur du tableur, point.