Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# WDL-Motoränderungsprotokoll für HealthOmics
<a name="wdl-engine-change-log"></a>

Diese Seite enthält das Änderungsprotokoll für die WDL-Engine sowohl für den strikten WDL-Modus als auch für den milden WDL-Modus. In jedem Abschnitt werden neue Funktionen, Verbesserungen und veraltete Funktionen zusammengefasst.

## Neue Features und Verbesserungen
<a name="wdl-changelog-new-features"></a>

In der folgenden Tabelle sind neue Funktionen und Verbesserungen für die WDL-Engine on aufgeführt. HealthOmics


| Datum der Änderung | Namen ändern | Änderungsbeschreibung | Empfohlene Aktion | 
| --- | --- | --- | --- | 
| 22. September 2026 | Konsistente Behandlung von CRLF-Zeilenenden | HealthOmics Die Zeilenenden von trims Windows-style (`\r\n`) sind in allen Bereichen `read_lines()` `read_tsv()` einheitlich und `read_map()` entsprechen dem Verhalten von Standard-Linux-Tools. | Keine. Es sind keine Workflow-Änderungen erforderlich. | 
| 22. September 2026 | `zip()``cross()`, und verarbeitet `read_tsv()` nun Eingaben mit gemischten Typen korrekt. Manuelle Type-Cast-Problemumgehungen können entfernt werden. | Die eingebauten Funktionen `zip()` und leiten `read_tsv()` jetzt die `cross()` Typen ihrer Rückgabewerte korrekt ab. In früheren Versionen konnten diese Funktionen beim Kombinieren gemischter Typen (z. B. `Array[String]` und `Array[Int]` in einem `zip()` Aufruf) zu unerwarteten Typfehlern führen, sodass manuelle Typumwandlungen im WDL-Code erforderlich waren. | Wenn Ihr Arbeitsablauf explizite Typumwandlungen beinhaltet, die hinzugefügt wurden, um Tippfehler von`zip()`, oder zu umgehen `cross()``read_tsv()`, können Sie sie entfernen. HealthOmics leitet jetzt automatisch die richtigen Typen ab.<br />Das Beibehalten vorhandener Typumwandlungen verursacht keine Fehler und beeinträchtigt auch nicht das Workflow-Verhalten. | 
| 22. September 2026 | `basename(path, "")`fix gibt den Dateinamen statt einer leeren Zeichenfolge zurück. | `basename(path, "")`gibt jetzt den Dateinamen zurück.<br />Zum Beispiel `basename("/path/to/file.txt", "")` wird `"file.txt"` anstelle einer leeren Zeichenfolge zurückgegeben. | Durchsuchen Sie Ihre Workflows nach `basename(x, "")` Anrufen. Falls vorhanden, stellen Sie sicher, dass die Rückgabe des Dateinamens dem erwarteten Verhalten entspricht. | 
| 22. September 2026 | Float-key Kollisionserkennung in `collect_by_key()` | `collect_by_key()`zuvor wurden `Float` Schlüssel als identisch behandelt, wenn sie mit 6 Dezimalstellen übereinstimmten. Verschiedene Werte wie `0.0000001` und `0.0000002` wurden zu einer Gruppe zusammengefasst.<br /> HealthOmics Erkennt diese Kollision ab dem Änderungsdatum bei der Workflow-Erstellung und schlägt den Workflow mit einem eindeutigen Fehler im GetWorkflow StatusMessage-Feld fehl, anstatt die Ergebnisse zu verwerfen.<br />Ein Workflow, der zuvor beim Zusammenführen verschiedener `Float` Schlüssel erfolgreich abgeschlossen wurde, schlägt jetzt mit einem Kollisionserkennungsfehler fehl wie `"statusMessage": "(collect_by_key_test.wdl Ln 17 Col 47) No such function: collect_by_key\n Map[Float, Array[String]] collected = collect_by_key(pairs_with_collision)"` | Sie können eine der drei Methoden verwenden:+  `String`Schlüssel verwenden: Wechseln Sie `Array[Pair[Float, String]]` zu Ihren Schlüsselwerten `Array[Pair[String, String]]` und zitieren Sie sie. Tastenkombinationen sind immer unterschiedlich und schließen das Kollisionsrisiko vollständig aus. <br />+  `Int`Schlüssel verwenden: Ändern Sie den Schlüsseltyp, sodass Ihre Gleitkommawerte mit einer Potenz von 10 `Array[Pair[Int, String]]` multipliziert werden, um die erforderliche Genauigkeit als Ganzzahl beizubehalten. <br />+  Wenn `Float` Schlüssel unvermeidlich sind, runden Sie sie zunächst auf eine konsistente Genauigkeit ab, um sicherzustellen, dass jeder Schlüssel wirklich anders ist und keine Daten stillschweigend zusammengeführt werden. Normalisieren Sie jeden Schlüssel, indem Sie ihn `round(value * 1000000.0) / 1000000.0` vor der Übergabe an verwenden. `collect_by_key()`  | 
| Demnächst (60 Tage im Voraus ab 22. September 2026) | Die Division mit Gleitkommazahlen (/) gibt Dezimalzahlen zurück, keine gekürzten Ganzzahlen. | **Aktuelles Verhalten: ** Der `/` Operator für `Float` Operanden gibt die nächste Ganzzahl zurück. Zum Beispiel gibt er `5.0 / 2` zurück`2.0`, nicht`2.5`. Wenn beide Operanden `Int` (z. B.`5 / 2`) sind, gibt das Ergebnis 2 zurück.<br />**Kommende Änderung (30. November 2026): ** Die Float-Division für Float-Operanden wird mit einer Genauigkeit von 16 Dezimalstellen zurückgegeben. Wird nach diesem Datum zurückgegeben`2.5`, `5.0 / 2.0` `150.0 / 7.0` wird `21.428...` anstelle eines Integer-Werts zurückgegeben.<br />Die Genauigkeit des Ergebnisses hängt davon ab, wie es verarbeitet wird: Wenn der Ergebnistyp ist`Float`, wird der Wert mit einer Genauigkeit von bis zu 16 Dezimalstellen berechnet; wenn das Ergebnis zu a gezwungen wird, wird `String` es stattdessen mit 6 Dezimalstellen formatiert.<br />Zum Beispiel `5.0 / 2.0` wird zurückgegeben und `21.4285714285714` als a zurückgegeben`2.5`, aber `21.428571` wenn es in a `Float` interpoliert `150.0 / 7.0` wird. `String`<br />`Int / Int`Ausdrücke wie `5 / 2` sind nicht betroffen und geben weiterhin 2 zurück. | Um unabhängig von der Engine-Version ganzzahlige Ergebnisse sicherzustellen, schließen Sie die Float-Division in `floor()` oder `ceil()` ein:+  `floor(5.0 / 2.0)`→ kehrt immer zurück `2` <br />+  `ceil(5.0 / 2.0)`→ kehrt immer zurück `3` <br />Wenn Ihr Workflow absichtlich Dezimalergebnisse von der Float-Division erwartet, sind keine Änderungen erforderlich. Beim nächsten Divisionsverhalten ab dem 30. November 2026 werden auch Dezimalstellen zurückgegeben.<br />Hinweis: gibt immer `5/2` noch 2 zurück, da der `/` Operator auf ganze Zahlen angewendet wird. |