.jpg)
This week we are happy to announce the introduction of a new API to call functions on Wikifunctions! The MediaWiki Action API for Wikifunctions was extended by a public endpoint to run functions. This allows external tools to call Wikifunctions in order to run a function with the given arguments, and get the result back.
The new action should mostly work as a drop-in replacement for the existing internal wikilambda_function_call API action. If there are any tools currently using the internal action, we ask you to switch over to the public one, as it’s more stable, reliable, and performant. We plan to continue swiftly evolving the internal API only in ways that support the front end better, without announcing such changes or offering guarantees of stability. Changes to the external API on the other hand will follow MediaWiki’s usual policies. We also documented the new API in the API Portal, in the Wikifunctions API Reference.
If you like to get support with switching the API, we are happy to provide help.
As with everything Wikifunctions at this early stage, we ask that you use the API gently and with consideration, and to allow us to slowly grow into the most useful version the project can be.
As of Saturday, 6 April 2024, Wikifunctions has grown to 1000 functions! Congratulations to the community! We present the 1000th function in the section about the Function of the Week below, here we look at a few statistics around the functions as we have them so far.
Sixty of the functions come in the predefined space. Those are validators for the predefined types and a small set of functions with builtins.
Of the first 1000 functions,
Since a function can be in more than one group, the numbers won’t add up to a thousand.
As we can see, the majority of our functions are dealing with strings, which is great for a system that aims to become a comprehensive natural language generation library. According to the count in our catalogue, we currently have functions for 20 languages.
We are excited about this early milestone, and are looking forward to develop into a comprehensive library of functions to support Wikipedia, the other Wikimedia projects, and beyond.
Are you a front end or full stack engineer and want to work with us on Abstract Wikipedia and Wikifunctions? Then we are a looking for you! Check out our job description on Greenhouse.
The recording of the last Volunteers’ Corner is now available for everyone to see on Wikimedia Commons. Thanks to all who participated!
This week, we made some follow-up tweaks to the code for the new, public API (T360359). We adjusted our example API call for the public to use the shorter, simpler, more familiar 'canonical form', rather than the more expansive 'normal form'.
We deployed the latest version of the back-end services, which we hope will have fixed a number of minor issues, and helped us move forwards with other improvements.
We improved the error-handling when using Python to wrap things in user-readable errors in some further cases (T356715). We no longer hard-code the internal label for what kind of evaluation is used, but show Z14K2 or similar (T358571); there is more work to do to label this nicely. We reduced the level of expansion in argument calls, which should speed up execution in some cases (T360172). Similarly, we switched the expansion of Code objects to be ephemeral, so they're returned only by reference (T359872). Finally, we fixed an unnecessary expansion of Types in lists (T324661). Collectively, these three prompted further review of how we can simplify responses (work forthcoming).
We adjusted how the front-end handles API errors (T361598), and consolidated the code into a central place (T315432). We changed how the object selector filters out 'disallowed' values so that it can be used in certain cases which we previously unintentionally prohibited (T336292).
We tweaked our metrics monitoring code to not emit null values, so that the new Metrics Platform from our colleagues won't reject the logs (T350497). We simplified some of our browser tests to be simpler and less likely to break as the code changes (T349836), and abstracted the internationalisation label checking so it won't break tests when labels update; the newly-fixed tests are now part of the daily browser test regression monitoring suite, as well as the regular CI.
.svg)
Since numbers have become available, a lot of new functions have been created for them. And some of them leave me with mixed feelings, such as the Function of the Week for this week. I chose it because it is the 1000th function: Padovan number (Wikifunction Z15075, Wikipedia article).
Named for Richard Padovan, an European architect, the Padovan numbers are a sequence of numbers where each number is the sum of the two numbers in the sequence preceding the one before the number we are looking for. That is, the tenth Padovan number is the sum of the eighth and seventh numbers, the two numbers before the ninth. That renders the definition quite similar to the far more famous Fibonacci sequence (Wikifunction Z13835). The Wikipedia article discusses the sequence in further detail.
Currently, the function offers three tests and two implementations. The three tests define the zeroth Padovan number as 1, the tenth number as 3, and the hundredth number as 288,627,200,960. As the Wikipedia article discusses, there are several ways to start the sequence, and the tests specify how the sequence starts, which follows On-Line Encyclopedia of Integer Sequences sequence A000931, but is, interestingly, different from what the Wikipedia article in any of the existing language editions suggests (by being shifted by five positions). Then we do have the Padovan spiral number, which aligns with Wikipedia's definition, and shifts the number accordingly.
| n | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| Wikipedia | 1 | 1 | 1 | 2 | 2 | 3 | 4 | 5 | 7 | 9 | 12 |
| Wikifunctions | 1 | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 2 | 2 | 3 |
The two existing implementations are both written in Python, and represent two different ways to calculate the number:
You may ask “what is this function good for?”, and in my opinion these functions dance around the border of being useful for Wikifunctions. This is ultimately a discussion that we have to have as a community. I don’t expect this function to be terribly useful for Abstract Wikipedia, but I could see that eventually we could interactively embed this function in the Wikipedia article for the Padovan sequence itself, allowing for a better experience of our favourite encyclopaedia. I could also see us postponing the decision of how to define what belongs into Wikifunctions and what does not for a little bit longer. Or making a decision now that we revise after a while, with more experience. I am all for allowing a young project such as Wikifunctions to have a bit more space to breathe in these early days, to have a bit more space for fun, for exploration. And I certainly don’t want to make a call at this point in time already about how to circumscribe the functions which belong in Wikifunctions, but it will be a discussion and a decision that we will have to face at some point.
I am looking forward to that discussion with curiosity and an open mind.