Wikifunctions:Status updates/2025-01-29

Wikifunctions Status updates

With 2000 Functions into the new year: time for stats

A few weeks ago, we crossed 2000 functions! We will follow "Lydia’s Rule" (named after Lydia Pintscher, Portfolio Lead for Wikidata): passing random milestones shouldn’t be taken as a reason for context-free celebration, but as an opportunity to look into statistics and to take stock of where we are and what we have achieved.

As of the time of writing (Wednesday, 29 January 2025), we had 2096 functions. But of these, 189 have no implementation connected and are thus not usable, while 380 have no tests connected and are thus underdocumented and of unknown quality. The number of functions drops to 1662 if we only regard functions with at least one connected test and implementation each – still a solid 4/5ths of the functions we have, but it could be better. We now have a special page that can help with finding functions without tests. We have about 3473 implementations and 6179 tests.

Since our search isn’t great yet, the manually-curated function catalogue is probably the main entrance point to find functions. It lists a total of 1193 functions (though it may list some more than once). It has 17 top-level groups: logic (8), Boolean (30), signs (10), strings (164), scientific (13), natural languages (328, see below), lists (72), characters (12), numbers (354), dates (92), Wikidata (30), generic (8), types (11), functions (10), programming (1), and colors (18).

To break down the natural language functions, there are 13 global natural languages functions, and then we have functions for the following natural languages: Arabic (5), Bangla (23), Basque (21), Brahui (11), Breton (69), Croatian (44), Dagbani (3), Dutch (1), English (21), Esperanto (16), Finnish (1), French (10), German (15), Urdu (4), Igbo (14), Japanese (3), Persian (6), Korean (3), Kurdish (10), Malayalam (3), Moroccan Arabic (3), Polish (1), Punjabi (3), Rohingya (8), Russian (1), Scottish Gaelic (1), Serbian (1), Sindhi (8), Spanish (1), Swedish (1), Turkish (2), and Ukrainian (2).

So far, Wikifunctions has seen close to 50,000 edits. We have counted more than 43 Million pageviews last year, but this particular number is probably inflated through crawlers collecting training data for AI without properly identifying themselves, and other issues. If that number were true, it would be an increase of about 10x last year. Monthly, we currently see about 3000 function calls, mostly from the function pages, and another 400 through the external API. More than 50 countries are represented in the editorship, and people accessed Wikifunctions from more than 200 countries and territories – in other words, nearly all countries. At the beginning of the year we started with about 20 active contributors, and we grew to about 100 active contributors.

Some of these numbers are making us very happy – the healthy growth of functions, the high ratio of functions with connected implementations and tests, the large number of countries contributing to and accessing Wikifunctions. For some, we have trouble really understanding them: the pageviews seem faulty. Finally, for some we hope to see significant growth in the coming year, particularly for the numbers of function calls made, and people who are active contributors. We hope that the integration of Wikifunctions into Wikipedias and other Wikimedia projects will spur interest and excitement, and so lead to more robust numbers.

Next Volunteers’ Corner on 3 February

Next week, on Monday, 3 February 2025, at 18:30 UTC, we will have our monthly Volunteers’ Corner. Unless you have many questions, we will follow our usual agenda, of giving updates on the upcoming plans and recent activities, having plenty of time and space for your questions, and building a Function together. Looking forward to seeing you online on Monday!

Recent Changes in the software

A very short list this week, as a lot of our focus has been on delivering the bigger pieces of work for the Quarter.

We've fixed the "report" widget to not run the test suite on brand-new Implementations or Tests, as there's no content to test yet (T375242). Thank you to User:GrounderUK for the suggestion.

We've prepared a database schema change that, once applied in production, will allow filtering searches for Functions to limit results to Functions that can be embedded in Wikipedia articles (T383561). More coming soon.

We, along with all Wikimedia-deployed code, are now using the latest version of the Codex UX library, v1.20.0, as of this week. We believe that there should be no user-visible changes on Wikifunctions, so please comment on the Project chat or file a Phabricator task if you spot an issue.

News in Types: Read and display functions for Rational and Floating point numbers

A few weeks ago we introduced the Rational number and Floating point number types. The community has been working on read and display functions since then, and now we have a working set. Both have been introduced, making it much easier to use functions with these types. Thanks to everyone who has been working on these!

Function of the Week: Python converter to float64

The Function of the Week is a column written by the community. Planning the column and submissions can be made here. This week’s entry was written by 99of9 with edits by Feeglgeef.

This week's Function of the week is not a Function! This week we are discussing: Python converter to float64. It is a Type converter from code, which are almost invisible to function writers when they are working well, but their accuracy is vital to the successful release of most new Types. These converters are called when your code implementation returns a value which needs to be converted to the internal representation that Wikifunctions uses for the Type of object returned.

This particular converter is for values returned by Python implementations which implement a function which returns a float64, our type for representing 64-bit floating point numbers, which within python are typed "float". It was written by Denny, as connected converters are currently only editable by staff. This is one of the most complicated type conversions we have to date. The 64 bits in the native float are actually in three groups which are overloaded to take on different meanings in special contexts. These need to be converted to four keys for a float64, three with broadly parallel meaning, and one to enumerate the value in special contexts.

Converters from code do not have the same variety of implementations that functions do. They simply have code written in the language they are converting from that returns JSON that represents the structure of a ZObject. This one uses math library functions to check for each possible special value (NaN, signed infinity, signed zero). If it is a special value, the special value key is set, and since the other keys are now irrelevant, they are returned with a default value of 0. If the input is not a special value, the sign is tested, and the magnitude is expanded into its mantissa and exponent via math.frexp. The mantissa is then shifted from a range of [0.5,1) to [0,0.5), because just like the IEEE 754 binary representations our significand has a hidden leading bit, equivalent to always adding 0.5 back to this value. The returned exponent is decremented by one to account for the normal binary significand range representing values from [1,2). The significand is converted to a natural number in the range 0 to 2⁵²-1 for float64's significand key. It's important that none of these operations have rounding errors.

No tests are directly attached to Type converters, but we can test them indirectly. If a python implementation of any function that returns floats is failing valid tests, it is possible that this is due to the converter. This week a subtle bug was corrected, because a test returning the special value of -0 was failing in the python implementation of Rational number to float. That function also has tests for some of the other special values, and numerous floating-point edge cases. Depending on our intent for the ignored keys of special values, we can also use tests with stricter implementations testing cases like equality of +infinity with different exponent keys.

Converting from a numeric value to the keys for a Wikifunctions float64 is a task that some of us also currently need to do when designing tests for float64 functions. It's even harder for humans than it is for a converter! To ease this task, we expect to soon add a floating point reader function to float64 that will read from whatever string is entered to represent the number (just as integers already have).

Question for discussion:

Should special values return with their other (usually disregarded) keys matching the values of the sign, mantissa and exponent in the IEEE 754 binary representations?

Fresh functions weekly

Here is a list of new functions that have been created since last week, with connected implementations and (mostly) passing tests.

We can see a rich variety of functions – and there were even more who didn’t make it to the list because they didn’t have tests or implementations. A comprehensive list of all functions sorted by creation date can be found on-wiki.