Rust: Unterstützung für hexadezimale Float-Literale hinzufügen

Ich habe mit diesem Problem gespielt und bin zu dem Schluss gekommen, dass dies leider das Problem Nr. 1306 wiederbelebt. Der aktuelle Lexer verbietet deshalb jedes Alpha-Zeichen nach . . Wir können sie selektiv zulassen, wenn das Muster 0x<digits>. gefunden wird, aber es erscheint zu inkonsistent und kann unendliches Vorausschauen erfordern, wenn wir eine Inkonsistenz beseitigen wollen.

Ich schlage vor, nach dem Punkt eine Ziffer oder 0x oder 0b zu verlangen. Dies vermeidet die Kollision und lässt Sie (kurioserweise) die Radix-Mitte literal wechseln, wenn Sie möchten. Und es ist nur geringfügig hässlicher als das, was C99 Sie schreiben lässt.

@graydon Oder wir können nach dem Punkt nur Nullen verlangen. (zB 0x1fffffffffffff.0p+972_f64 statt 0x1.fffffffffffffp+1023_f64 )

Ich glaube nicht, dass dies rückwärts inkompatibel ist, Renominierung.

für Meilenstein mit abgeschlossenem Funktionsumfang angenommen

besucht zur Triage vom 2013-07-15. Haben wir uns hier tatsächlich auf eine Syntax festgelegt? Dies scheint eine nette, einfache Aufgabe für einen neuen Mitwirkenden zu sein, _wenn_ wir ihnen eine klare Spezifikation für die Syntax geben können; Wenn sich die Syntax jedoch noch in der Entwurfsphase befindet, ist diese Behauptung weniger wahr.

Ich denke, wir haben die Syntax noch nicht ganz auf den Punkt gebracht, aber ich sollte darauf hinweisen, dass es notwendig wäre, Kollisionen mit Suffixen zu vermeiden (von denen einige mit f, einer Hex-Ziffer beginnen), also denke ich, wenn wir dies tun, sollte es nur für Angabe der Mantisse, und nur in Kombination mit einem vollen Exponenten (in Dezimal).

Dies muss noch umgesetzt werden.

Nicht 1.0

Hexadezimale Gleitkommazahlen sind unter C-Mathematikbibliotheken sehr beliebt. Und ich würde sie gerne auch in Rust verwenden.

Ich sehe, dass hexadezimales Float als Erweiterung in Rost implementiert wurde, dann in eine separate Kiste verschoben wurde und jetzt bei rust-deprecated und mit Nightlyrust nicht kompiliert werden kann.

Wie sieht die Zukunft dieser Funktion aus?

Daran auch interessiert. Ich möchte ein wiederholbares Physiksystem für ein Spiel implementieren, das konsistente Ergebnisse auf allen Computern erfordert. Hex-Float-Literale würden es mir ermöglichen, bitgenaue Gleitkommawerte in Tests und Konstanten zu schreiben.

Zumindest eine Erklärung, warum diese Funktion veraltet ist, wäre wünschenswert, da dieser Thread das erste Ergebnis ist, das ich für "Rost-Hex-Float-Literal" erhalte.

Die Situation ist im Moment etwas eklig. Prozedurale Makros werden gerade überarbeitet (#38356), und es wäre also zumindest Zeitverschwendung, hexfloat während dieser Zeit auf dem neuesten Stand zu halten. Aber ich weiß nicht, wie die Geschichte danach sein wird.

Wenn mein Verständnis richtig ist, gibt es hexadezimale Gleitkommazahlen in C/C++, weil es nicht garantiert ist, dass dezimale Gleitkommazahlen richtig runden [1]. In Rust jedoch sollten nach #27307 --- ich vermute, dass dies nicht unbedingt beabsichtigt ist! --- fast alle dezimalen Gleitkommazahlen (#31407 beschreibt Randfälle, die praktisch irrelevant sind) sollten auf den nächsten gerundet werden, also können Sie einfach rustc angeben eine geeignete Anzahl (z. B. 30) von Nachkommastellen und erhält die richtig gerundete Zahl. Dies wäre vorerst eine "praktische" Antwort.

Eine Sache, für die meiner Meinung nach immer noch hexadezimale Gleitkommazahlen relevant sind, ist eine Konvertierung von C/C++. Sie würden nicht alle hexadezimalen Gleitkommazahlen selbst in Dezimalzahlen umwandeln wollen :) Status quo war bisher nicht wirklich garantiert --- meiner Meinung nach ist es reines Glück. Wenn es eine Möglichkeit gibt, einen Float mit exaktem Bitmuster nur aus constexprs zu konstruieren, werde ich das anpassen.

[1] Zum Beispiel verlangt ISO C99 nur, dass dezimale Gleitkommazahlen innerhalb von ±1,5 ulps in eine darstellbare Zahl umgewandelt werden sollen („das Ergebnis ist entweder der nächste darstellbare Wert oder der größere oder kleinere darstellbare Wert unmittelbar neben dem nächsten darstellbaren Wert“ ).

@lifthrasiir , früher oder später möchte ich https://github.com/jameysharp/corrode/issues/73 beheben, indem ich C-Hex-Floats korrekt in Rust übersetze, daher würde ich Ihren Kommentar gerne besser verstehen. Ich habe noch nicht genug über Gleitkomma-Probleme gelesen, um zu verstehen, worum es hier geht.

Wollen Sie damit sagen, dass, Modulo Rust-Compiler-Bugs, jedes Hex-Float-Literal in ein dezimales Float-Literal umgewandelt werden kann, das der Rust-Compiler in dasselbe Bitmuster umwandelt? Wenn ja, würde ich mich freuen, wenn Corrode diese Konvertierung durchführen lässt. Können Sie eine Referenz empfehlen, die ich für einen Algorithmus lesen sollte, um diese Konvertierung korrekt durchzuführen? (Ein Hinweis auf Ihr prozedurales Makro wäre toll, aber idealerweise hätte ich auch gerne eine Arbeit oder ein Buch zum Zitieren.)

Allerdings nehme ich an, dass die genaue dezimale Version eines Hex-Float deutlich mehr Ziffern benötigt (richtig?), also ist die Hex-Float-Version vielleicht einfacher zu lesen und zu verstehen, zumindest für Leute, die sich genug für numerische Genauigkeit interessieren, um sie zu verwenden . Wenn Hex-Floats die von Menschen bevorzugte Form für diese Zahlen sind, würde ich argumentieren, dass Rust sie unterstützen sollte. Also IMO, mehr Feedback von Leuten, die Hex-Floats verwendet haben, würden hier helfen.

Wollen Sie damit sagen, dass, Modulo Rust-Compiler-Bugs, jedes Hex-Float-Literal in ein dezimales Float-Literal umgewandelt werden kann, das der Rust-Compiler in dasselbe Bitmuster umwandelt?

Mein Glaube ist ja.

Können Sie eine Referenz empfehlen, die ich für einen Algorithmus lesen sollte, um diese Konvertierung korrekt durchzuführen?

Sie müssen das nicht implementieren, da der aktuelle Rust-Compiler und die Standardbibliothek alle notwendigen Algorithmen implementiert (was schwieriger ist :-). Wenn Sie wirklich Referenzen benötigen, sehen Sie sich Folgendes an:

• Die Umrechnung von Binär in Dezimal ("flt2dec", #24612) ist eine Mischung aus [Dragon4] und [Grisu3].

  • [Dragon4]: Burger, RG und Dybvig, RK 1996. Fließkommazahlen schnell und genau drucken. SIGPLAN Nicht. 31, 5 (Mai 1996), 108-116.
  • [Grisu3]: Florian Loitsch. 2010. Gleitkommazahlen schnell und genau mit Ganzzahlen drucken. SIGPLAN Nicht. 45, 6 (Juni 2010), 233-243.

• Die Konvertierung von dezimal in binär ("dec2flt", #27307) ist ein paar von [Clinger] beschriebene Algorithmen. (Ich habe sie nicht selbst implementiert, daher ist mein Wissen über sie begrenzt.)

  • [Clinger]: William D. Clinger. 1990. Wie man Gleitkommazahlen richtig liest. SIGPLAN Nicht. 25, 6 (Juni 1990), 92-101.

Fürs Protokoll, meine Implementierung ist lifthrasiir/hexf (im

Allerdings nehme ich an, dass die genaue dezimale Version eines Hex-Floats deutlich mehr Ziffern benötigt (richtig?), [...] Wenn Hex-Floats die von Menschen bevorzugte Form für diese Zahlen sind, würde ich argumentieren, dass Rust sie unterstützen sollte . […]

Nicht genau, zum Beispiel 0x1.999999999999bp-4 = 0.10000000000000002 . Ich habe keine Meinung dazu, ob Rust Hex-Floats unterstützen sollte oder nicht.

Ich habe hexf jetzt offiziell in crates.io veröffentlicht . @jameysharp , ich denke, Sie können wahrscheinlich Hexf-Parse für Ihre Arbeit verwenden? (Die Syntax ohne Unterstrichen sollte fast gleich C99 identisch sein hexadecimal-floating-constant nicht-Terminal sans - wahlweise floating-suffix .)

Edit: Aargh, ich habe einen Fall übersehen. 0x1p1 sollte gültig sein, aber hexf erkennt es nicht; wahrscheinlich ist es aber leicht zu erklären.

Ähnlicher Anwendungsfall für mich auch; Ich möchte in der Lage sein, Rostcode aus einem Compiler zu generieren, ohne Genauigkeitsverlust für Float-Literale.