Wikifunctions:Status-Updates/2024-07-10
| ◀ |  Wikifunctions Status-Updates  |
▶ |
|
Typen-Vorschläge für den Zugriff auf Lexeme
Was ist die Vergangenheitsform des englischen Verbs “write”? Da es sich dabei um ein unregelmäßiges Wort handelt, würde Wikifunctions mit der regulären Funktion die falsche Antwort liefern und “writed” ausgeben. Wikidata weiß, dass die korrekte unregelmäßige Form “wrote” ist, aber Wikifunctions kann noch nicht auf Wikidata zugreifen.
Wie letzte Woche vorgestellt, ist es eines der Ziele für dieses Quartals, Wikifunctions-Funktionen den Zugriff auf Formen von Lexemen aus Wikidata zu ermöglichen. Sobald dies verfügbar ist, können wir die korrekte Form aus Wikidata abrufen, egal ob unregelmäßig oder regulär, und für den Rest die regulären Funktionen verwenden.
Wir haben einen Entwurf einiger Beispielfunktionen, die wir unterstützen möchten, geschrieben und veröffentlicht. Diese dienen als Orientierung für die Typen, die erforderlich sind, um diese Funktionen zu unterstützen:
- Lexeme
- Lexemform
- Wikidata-Datenobjekt
- Wikidata-Aussage
- Wikidata-Eigenschaft
Insbesondere bei den letzten drei handelt es sich um unvollständige Darstellungen von Datenobjekten, Aussagen und Eigenschaften, da wir uns auf die Teile konzentrieren, die wir für den ersten Zugriff auf Formen benötigen.
Wir laden dich ein, Kommentare zu hinterlassen und Änderungen an den Typen vorzuschlagen, die wir erstellen müssen, und das Dokument als Ganzes zu kommentieren. Sobald wir alle Kommentare eingearbeitet haben, erstellen wir die erforderlichen Typen, die es uns ermöglichen, an den Änderungen im Orchestrierer zu arbeiten, der auf Wikidata zugreifen wird.
Bitte schau dir den Vorschlag an und hinterlasse Kommentare und Verbesserungen.
Typisierte Listen funktionieren nun auch bei anderen Elementen als booleschen Werten und Zeichenketten
Typisierte Listen unterstützten andere Elemente als boolesche Werte und Zeichenketten noch nicht vollständig. Wir haben die Unterstützung für typisierte Listen erweitert, sodass nun alle von uns unterstützten Typen unterstützt werden, nämlich natürliche Zahl und Integer, Vorzeichen, Monat des Gregorianischen Kalenders und Monat des Igbo-Kalenders sowie Tag der Woche. Wenn wir in Zukunft einen neuen Typ einführen, sollten typisierte Listen dieses Typs automatisch verfügbar sein.
Bitte lass uns wissen, wenn du Probleme bei der Verwendung typisierter Listen der neu definierten Typen hast.
Aufzeichnung des Freiwilligentreffens jetzt auf Commons verfügbar
Die Aufzeichnung des letzten Frewilligentreffens ist jetzt wie immer auf Wikimedia Commons verfügbar. Bitte lass uns wissen, wenn du Kommentare hast!
Letzte Änderungen an der Software
Letzte Woche haben wir ziemlich viel Zeit damit verbracht, ein Problem mit laufenden Funktionen (T368892) zu finden und zu beheben. Wir denken – hoffen! –, dass dies am Dienstag, den 09.07.2024, behoben ist, aber lass uns bitte wissen, wenn du denkst, dass es weiterhin Probleme gibt. Die Fehlerbehebung umfasste die Deaktivierung der jüngsten Änderung, die die zurückgegebenen Metadaten aus Unteraufrufen innerhalb jedes Funktionsaufrufs aufteilte. Wir prüfen, wie wir sie wieder aktivieren können, ohne die Produktion zu stören.
Im Rahmen unserer Arbeit in diesem Quartal haben wir die Protokolle, die wir in den Back-End-Diensten erstellen, weiter verbessert, indem wir unser Protokollierungsprogramm angepasst haben (T364413); weitere Arbeiten folgen hier in Kürze. Wir haben auch die Neufassung der letzten unserer Browser-Testsuiten abgeschlossen, die sich auf das Verbinden und Trennen von Implementierungen und Tests beziehen (T349836), was im letzten Quartal ein großer Schwerpunkt war.
Wir haben das Funktionsauswertungs-Widget so repariert, dass du eine Funktion sofort ausführen kannst, sobald eine Implementierung verbunden ist, anstatt die Seite aktualisieren zu müssen (T343586). Wir haben das Objektauswahl-Widget neu aufgebaut, sodass beim Klicken außerhalb des Menüs nach der Eingabe in das Widget ein exakt übereinstimmender Wert ausgewählt wird, falls einer vorhanden ist, oder das Widget in den vorherigen Zustand zurückversetzt wird, falls keiner vorhanden ist, um den Benutzererwartungen zu entsprechen (T351206).
Wir haben ein von User:ScienceD90 bemerktes Versehen behoben und die Objekte Z189/Prüfer und Z289/integrierter Prüfer für Z89/HTML-Fragmente erstellt (T368318).
Wir haben Unterstützung für eine Reihe neuer Sprachen hinzugefügt: Wali als Z1405/wlx (T368046); Interslawisch über Z1750/isv-latn und Z1924/isv-cyrl (T366171); Chitonga als Z1925/toi und Luvale als Z1926/lue (T368856); Jakaltekisch als Z1927/jac (T369095); Hunde als Z1928/hke (T369157); Abron als Z1929/abr (T369464); und Assyrisch-neuaramäischer Dialekt als Z1930/aii. Falls es dich interessiert: Der Auslöser dieser Arbeit war im Allgemeinen der Wunsch der breiteren Wikimedia-Bewegung, diese Sprachen zu unterstützen und zu verwenden, insbesondere über TranslateWiki.
Funktion der Woche: Größter gemeinsamer Teiler (Z13612)
Die aktuelle Funktion der Woche wurde von User:Autom vorgeschlagen. Vielen Dank für den Vorschlag! Wenn du einen Vorschlag machen möchtest, kannst du dies gerne auf der Seite Funktion der Woche tun.
In der Mathematik ist der größte gemeinsame Teiler zweier Zahlen die größte Zahl, durch die beide Zahlen ohne Rest geteilt werden können. Dies ist ein seit langem bekanntes mathematisches Problem und beschert uns einen der ältesten Algorithmen, der nach einer Person benannt ist: den Euklidischen Algorithmus, benannt nach Euklid, dessen Beschreibung des Algorithmus die älteste ist, die wir heute kennen. Es sind auch Beschreibungen des Algorithmus bekannt, die anscheinend unabhängig voneinander in Indien und China entwickelt wurden.
Der größte gemeinsame Teiler und der euklidische Algorithmus sind ein gutes Beispiel dafür, wie man den Unterschied zwischen einer Funktion und einer Implementierung hervorheben kann: Der euklidische Algorithmus ist nur eine Möglichkeit, den größten gemeinsamen Teiler zu berechnen. Er kann auch berechnet werden, indem man die beiden Listen der Primfaktoren der beiden Argumente erhält und dann alle gemeinsamen Primzahlen multipliziert. Und es gibt viele andere Möglichkeiten, den größten gemeinsamen Teiler zu ermitteln. Alle diese verschiedenen Möglichkeiten, das Ergebnis zu berechnen, können mehr oder weniger Zeit in Anspruch nehmen.
In Wikifunctions haben wir derzeit vier verschiedene Implementierungen für den größten gemeinsamen Teiler:
- Eine Komposition
- Eine in Python
- Eine in JavaScript, wobei alle drei genannten Implementierungen auf dem euklidischen Algorithmus basieren
- Eine, die die Python-Standardbibliothek verwendet und den größten gemeinsamen Teiler direkt anbietet
Die erste Komposition behauptet zwar im Namen, dem euklidischen Algorithmus zu folgen, implementiert ihn jedoch nicht korrekt.
Wir haben vier Tests, die Paare
- 42 und 18, was 6 ergibt
- 99 und 1, was 1 ergibt
- 42 und 0, was 42 ergibt
- 0 und 0, was als 0 definiert ist
Der erste Test deckt auf, dass die erste Implementierung fehlerhaft ist: Die Implementierung ergibt 18, sollte aber 6 ergeben. Trotzdem ist die Komposition verbunden. Ich würde vorschlagen, dass wir die fehlerhafte Implementierung entweder trennen oder reparieren.
Die Tests decken hauptsächlich Randfälle ab (drei von vier). Es wäre wahrscheinlich eine gute Idee, mehr Normalfälle hinzuzufügen (um eine falsche Implementierung wie die Komposition wirklich zu erfassen), aber auch noch mehr Randfälle abzudecken, wie beispielsweise zweimal dieselbe Zahl, ohne dass sie 0 oder 1 ist.
User:Autom weist darauf hin, dass dies eine gute Gelegenheit wäre, die möglichen Geschwindigkeitsunterschiede verschiedener Algorithmen zu diskutieren, aber im Fall von Wikifunctions ist der Unterschied zwischen den Programmiersprachen – ob wir Python, JavaScript oder eine Komposition verwenden – derzeit weitaus bedeutender. Derzeit hat Python einen höheren Overhead als JavaScript, und Kompositionen können in vielen Fällen (aber nicht immer) langsamer sein als eine Implementierung in Code. Dementsprechend bevorzugt das System in diesem Fall die JavaScript-Implementierung, gefolgt von den beiden Python-Implementierungen und mit der Komposition am Ende. Für den ersten Testfall, wohl den einzigen Testfall, der kein Grenzfall ist, dauert die Komposition derzeit länger als 11 Sekunden, die Python-Implementierungen etwa 4-5 Sekunden und die JavaScript-Implementierung etwas mehr als eine Sekunde.
Wir hoffen, die Leistung unseres Backends für alle diese Implementierungen deutlich zu verbessern, sodass die Algorithmuseffizienz eine viel größere Rolle spielt, aber so weit sind wir noch nicht.
Danke an User:Autom für den Vorschlag dieser Funktion!