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.
Recent Changes in the software
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 & [[:phab:T358135|]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 (Z13522 )
Since we introduced natural numbers last week, 140 functions using natural numbers have been created. And since we are talking about identity above, we can look at a formally related notion, equality. This is why this week I chose the equality of natural numbers. This function was started in last week’s Volunteer’s Corner, and is thus one of the functions where we have a video of its beginning.
When we talk about humans, there is a huge difference between identity and equality. But when we talk about numbers, not so much. If a number is equal to another number, then those two numbers are really the same number, aren’t they? Maybe, maybe not. This question goes very deep into the philosophy of mathematics and the question on what a number actually is. For other types than natural numbers, the question whether two instances of that type are the same, whether they are equal, and whether there is a difference between these two questions, can become more interesting, and is really part of defining the 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.
The function has four tests:
- Two equals two
- Two does not equal zero
- 9007199254740992 and 9007199254740993 are not equal
- A leading zero does not make two values unequal
The first two tests are quite obvious, but what’s up with the other two tests?
Test 3 looks like two random large numbers, one being one larger than the other. But in JavaScript, if you type the following code into a JavaScript console:
or
you will get the surprising answer:
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.