Rust: Ajout de la prise en charge des littéraux flottants hexadécimaux

J'ai joué avec ce problème et j'ai conclu que cela ravivait malheureusement le problème #1306. Le lexer actuel interdit tout caractère alpha après . cause de cela. Nous pouvons choisir de les autoriser de manière sélective lorsque le modèle 0x<digits>. est trouvé, mais il semble trop incohérent et peut nécessiter une prévision infinie si nous voulons éliminer une incohérence.

Je suggère d'exiger un chiffre ou 0x ou 0b après le point. Cela évite la collision et (curieusement) vous permet de changer la base du littéral moyen si vous le souhaitez. Et ce n'est que légèrement plus laid que ce que C99 vous fait écrire.

@graydon Ou nous ne pouvons exiger que des zéros après le point. (par exemple 0x1fffffffffffff.0p+972_f64 au lieu de 0x1.fffffffffffffp+1023_f64 )

Je ne crois pas que ce soit rétrocompatible, la renomination.

accepté pour le jalon de fonctionnalité complète

visité pour le triage datant du 2013-07-15. Avons-nous réellement choisi une syntaxe ici? Cela semble être une tâche facile et agréable pour un nouveau contributeur _si_ nous pouvons leur donner une spécification claire pour la syntaxe ; mais si la syntaxe est encore en phase de conception, alors cette affirmation est moins vraie.

Je pense que nous n'avons pas tout à fait compris la syntaxe, mais je dois souligner qu'il serait nécessaire d'éviter d'entrer en collision avec des suffixes (dont certains commencent par f, un chiffre hexadécimal), donc je pense que si nous faisons cela, cela ne devrait fonctionner que pour en spécifiant la mantisse, et uniquement lorsqu'il est combiné avec un exposant complet (en décimal).

Cela doit encore être mis en œuvre.

Pas 1.0

Les flottants hexadécimaux sont très populaires parmi les bibliothèques mathématiques C. Et j'aimerais aussi les utiliser dans Rust.

Je vois que le flotteur hexadécimal a été implémenté dans rust en tant qu'extension, puis déplacé vers une caisse séparée et maintenant il est au rust-deprecated et ne parvient pas à compiler avec nightly rust.

Quel est l'avenir de cette fonctionnalité ?

Également intéressé par cela. Je cherche à mettre en œuvre un système de physique rejouable pour un jeu, ce qui nécessite des résultats cohérents sur tous les ordinateurs. Les littéraux flottants hexadécimaux me permettraient d'écrire des valeurs à virgule flottante exactes au bit dans les tests et les constantes.

À tout le moins, une déclaration expliquant pourquoi cette fonctionnalité est dépréciée serait appréciée, car ce fil est le premier résultat que j'obtiens pour "rust hex float literal".

La situation est un peu compliquée en ce moment. Les macros procédurales subissent actuellement une refonte (#38356), et ce serait donc au moins une perte de temps de garder hexfloat à jour pendant que cela se produit. Mais je ne sais pas quelle sera l'histoire après ça.

Si ma compréhension est correcte, les flottants hexadécimaux en C/C++ sont là car les flottants décimaux ne sont pas garantis pour arrondir correctement [1]. Dans Rust, cependant, après # 27307 --- Je soupçonne que ce n'est pas nécessairement intentionnel! --- presque tous les nombres décimaux (# 31407 décrit les cas limites qui ne sont pratiquement pas pertinents) devraient arrondir au plus proche, vous pouvez donc simplement donner rustc un nombre approprié (disons, 30) de chiffres fractionnaires et obtiendra le nombre correctement arrondi. Ce serait une réponse "pratique" pour l'instant.

Une chose pour laquelle je pense toujours que les flottants hexadécimaux sont pertinents est une conversion de C/C++. Vous ne voudriez pas convertir tous les flottants hexadécimaux en nombres décimaux vous-même :) J'ai récemment écrit une macro procédurale expérimentale qui fait exactement cela, en convertissant les flottants hexadécimaux en flottants décimaux (que rustc peut comprendre), mais j'étais réticent à en publier un parce que le le statu quo n'était pas réellement garanti jusqu'à présent --- c'est une pure chance à mon avis. S'il existe un moyen de construire un flotteur avec un motif de bits exact uniquement à partir de constexprs, je l'adapterai.

[1] Par exemple, ISO C99 exige uniquement que les nombres décimaux soient convertis en un nombre représentable à ±1,5 ulps ("le résultat est soit la valeur représentable la plus proche, soit la valeur représentable plus grande ou plus petite immédiatement adjacente à la valeur représentable la plus proche" ).

@lifthrasiir , tôt ou tard, j'aimerais corriger https://github.com/jameysharp/corrode/issues/73 en traduisant correctement C hex floats en Rust, donc j'aimerais mieux comprendre votre commentaire. Je n'ai pas encore assez lu sur les problèmes à virgule flottante pour comprendre ce qui est impliqué ici.

Êtes-vous en train de dire que, modulo les bogues du compilateur Rust, chaque littéral hexadécimal flottant peut être converti en un littéral flottant décimal que le compilateur Rust convertira en le même motif binaire ? Si c'est le cas, je serais heureux que Corrode fasse cette conversion. Pouvez-vous recommander une référence que je devrais lire pour qu'un algorithme effectue correctement cette conversion ? (Un pointeur vers votre macro procédurale serait bien, mais idéalement, j'aimerais aussi avoir un article ou un livre à citer.)

Cela dit, je suppose que la version décimale exacte d'un flottant hexadécimal peut prendre beaucoup plus de chiffres (n'est-ce pas?), alors peut-être que la version flottante hexadécimale est plus facile à lire et à comprendre, du moins pour les personnes qui se soucient suffisamment de la précision numérique pour les utiliser . Si les flotteurs hexagonaux sont la forme préférée des humains pour ces nombres, je dirais que Rust devrait les prendre en charge. Donc, IMO, plus de retours de personnes qui ont utilisé des flotteurs hexagonaux aideraient ici.

Êtes-vous en train de dire que, modulo les bogues du compilateur Rust, chaque littéral hexadécimal flottant peut être converti en un littéral flottant décimal que le compilateur Rust convertira en le même motif binaire ?

Ma conviction est oui.

Pouvez-vous recommander une référence que je devrais lire pour qu'un algorithme effectue correctement cette conversion ?

Vous n'avez pas à implémenter cela, car le compilateur Rust actuel et la bibliothèque standard implémentent tous les algorithmes nécessaires (ce qui est plus difficile :-). Si vous avez vraiment besoin de références, consultez ce qui suit :

• La conversion du binaire en décimal ("flt2dec", #24612) est un hybride de [Dragon4] et [Grisu3].

  • [Dragon4] : Burger, RG et Dybvig, RK 1996. Impression rapide et précise de nombres à virgule flottante. SIGPLAN Non. 31, 5 (mai 1996), 108-116.
  • [Grisu3] : Florian Loitsch. 2010. Impression rapide et précise de nombres à virgule flottante avec des nombres entiers. SIGPLAN Non. 45, 6 (juin 2010), 233-243.

• La conversion de décimal en binaire ("dec2flt", #27307) est un couple d'algorithmes décrits par [Clinger]. (Je ne les ai pas mis en œuvre moi-même, donc mes connaissances à leur sujet sont limitées.)

  • [Clinger] : William D. Clinger. 1990. Comment lire avec précision les nombres à virgule flottante. SIGPLAN Non. 25, 6 (juin 1990), 92-101.

Pour mémoire, mon implémentation est lifthrasiir/hexf (publié en ce moment, pas encore dans crates.io). N'hésitez pas à ramasser.

Cela dit, je suppose que la version décimale exacte d'un flottant hexadécimal peut prendre beaucoup plus de chiffres (n'est-ce pas?), [...] Si les flottants hexadécimaux sont la forme préférée de l'homme pour ces nombres, je dirais que Rust devrait les prendre en charge . [...]

Pas exactement, par exemple, 0x1.999999999999bp-4 = 0.10000000000000002 . Je n'ai aucune opinion sur le fait que Rust devrait prendre en charge les flotteurs hexadécimaux ou non.

J'ai maintenant officiellement publié hexf sur crates.io . @jameysharp , je pense que vous pouvez probablement utiliser hexf-parse pour votre travail ? (La syntaxe sans underscores doit être identique presque identique à C99 hexadecimal-floating-constant sans non connexion en option floating-suffix .)

Edit : Aargh, j'ai raté un cas. 0x1p1 devrait être valide mais hexf ne le reconnaît pas ; c'est probablement facile à expliquer, cependant.

Cas d'utilisation similaire pour moi aussi; J'aimerais pouvoir générer du code rouille à partir d'un compilateur, sans perte de précision pour les littéraux flottants.