Wikifunctions:Status updates/2024-03-13/fr

◀

Wikifunctions Status updates

▶

On identity

A banana with the QID for bananas. Note that Wikidata currently has no individual banana described.

In the Wikifunctions data model, we are using the notion of "identity" widely. For example, Types, Functions, and also the two Boolean values all feature the idea that they have an identity.

But the concept of identity has so far not been an explicit part of the data model, which prevented us from easily using it, such as in certain kinds of new types where values are limited, or easily incorporate them into a better user experience .

We would like to fix this issue for Wikifunctions, and add an explicit notion of identity to the data model. We have written a document with four different proposals, and would also like to gather input from the community: did we overlook advantages or disadvantages of certain proposals, are there even better ideas out there which we could implement instead? What did we miss, what could we do better?

You can find the document representing identity here, and it also touches on how to represent optional keys on types (which may also pre-inform on how to represent optional arguments on functions).

We hope to respond to your thoughts and implement a decision in the coming weeks and months.

Changements récents du logiciel

Multiplying Roman numerals using the User Interface in Latin. Wikifunctions Beta.

Our big focus this Quarter has been on improving Types so you can use them easily, on the path to accessing and using Lexemes and other content from Wikidata. This week, we landed a big milestone around how Types can use Functions to check inputs as you enter them, and shown based on their value (T358041). We will discuss this, with demonstrations, on-wiki and in a later Update as new Types are developed. You can already try it out on Wikifunctions Beta, for example to see multiplication work for Roman numerals (see screenshot). Please try it out in the Beta and raise issues if you encounter them.

We've also made some improvements related to editing Types (T358136 & T358135); we hope to make the interface good enough for the community to use and so be able to open up access without risking the site integrity in the future. Previously, when editing an old revision of an Object (e.g. to manually revert), the 'Publish' button wasn't active until you made a change, like for normal edits; we now detect this situation and make it active immediately (T343654). Last week we tweaked the heading on each Object page to not repeat the type between the title and the sub-title; this week, we've also removed the ZID of the type from the sub-title, to make the interface simpler (T357805).

On the back-end services, as well as internal changes, we've made some fixes to simplify the return value when using generic types (T324661), and to not hard-code an English value for the meta-data value of what kind of Implementation is run (T358571). We've dropped an old, now-unused API that was created to monitor the back-end services' availability (T359179). A few Functions have mis-reported Implementations or Testers due to how they were created and a bug in our code; we've made an adjustment to our code that might fix this situation as the affected items are edited, but will investigate further.

We made a fix to stop loading many copies of the style files on a page, which should slightly speed up the site loading and operation for everyone (T355919). Last week we tweaked the Function Evaluator to hide the 'no approved implementations' message; we've made a follow-up bug-fix, so you can consistently use it again (T346852). Our apologies!

All Wikimedia-deployed code, including Wikifunctions, are using the latest version of the Codex UX library, v1.3.4, as of this week. We don't expect any user-visible changes, so as always please comment on the Project chat or file a Phabricator task if you spot an issue or concern.

Wiki Mentor Africa recording available

The recording of the Wiki Mentor Africa event, that we cited in our last weekly update, is available on Zoom (passcode: w%mj$Yp3).

Function of the Week: equality of natural numbers (equality of natural numbers (Z13522))

Le coin des bénévoles Mars 2024

Depuis que nous avons introduit les nombres naturels la semaine dernière, 140 fonctions utilisant les nombres naturels ont été créées. Et puisque nous parlons d'identité ci-dessus, nous pouvons nous pencher sur une notion formellement liée, l'égalité. C'est pourquoi j'ai choisi cette semaine l'égalité des nombres naturels. Cette fonction a été créée dans le coin des bénévoles de la semaine dernière, et c'est donc l'une des fonctions pour lesquelles nous disposons d'une vidéo de son début.

Lorsqu'il s'agit d'êtres humains, il y a une grande différence entre l'identité et l'égalité. Mais lorsqu'il s'agit de nombres, ce n'est pas le cas. Si un nombre est égal à un autre nombre, alors ces deux nombres sont vraiment les mêmes, n'est-ce pas ? Peut-être, peut-être pas. Cette question va très loin dans la philosophie des mathématiques et la question de savoir ce qu'est réellement un nombre. Pour d'autres types que les nombres naturels, la question de savoir si deux instances de ce type sont identiques, si elles sont égales, et s'il existe une différence entre ces deux questions, peut devenir plus intéressante, et fait réellement partie de la définition du type.

The same discussion about equality and identity becomes relevant for the JavaScript implementation. JavaScript also makes a difference between equality and identity: the former is tested using two equal signs, ==, whereas the latter is tested using three equal signs, ===. As long as we are comparing two BigInt values, it doesn’t make a difference. But if we would compare a BigInt value with a Number value using ===, it would always fail. And if we had chosen to turn BigInt into JavaScript objects instead of BigInt values, === would also always fail. It is the interplay between the converter to BigInt that we are using and the implementation of equality using === that makes it work.

In Python, we don’t have to make that decision, and just use an implementation with the == operator.

The composition uses the built-in string equality on the strings resulting from casting both values to strings.

La fonction comporte quatre tests :

1. Deux égale deux
2. Deux n'est pas égal à zéro
3. 9007199254740992 et 9007199254740993 ne sont pas égaux
4. Un zéro initial ne rend pas deux valeurs inégales

Les deux premiers tests sont assez évidents, mais qu'en est-il des deux autres ?

Le test 3 ressemble à deux grands nombres aléatoires, l'un étant plus grand que l'autre. Mais en JavaScript, si vous tapez le code suivant dans une console JavaScript :

 9007199254740992 == 9007199254740993

ou

 9007199254740992 === 9007199254740993

vous obtiendrez la réponse surprenante :

 true

This is one of the cases where the human reader is usually better than the computer at Mathematics. Wikifunctions on the other hand gets this right, as it is set up to deal with arbitrary large natural numbers, as we discussed last week.

(The reason why JavaScript doesn’t get this right is because JavaScript does not really have integers, but all numbers are floating point numbers, and floating point numbers have a well-defined, but limited precision. That is the same reason why in JavaScript 0.8 minus 0.1 does not result in 0.7, but in 0.7000000000000001. Recently, JavaScript introduced the BigInt type for precise arithmetics using arbitrarily large integers. This is why we are using it as the value to which to convert the natural number type in JavaScript.)

The last test lead demonstrates that we haven't yet connected the validator with the type properly. As we have discussed in last week's Function of the Week, the validator should not allow for leading zeros.