A new API for calling Wikifunctions

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 https://api.wikimedia.org/wiki/Wikifunctions_API/Reference/Run_Function. 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 https://www.mediawiki.org/wiki/Stable_interface_policy. We also documented the new API in the API Portal https://api.wikimedia.org/, in the Wikifunctions API Reference https://api.wikimedia.org/wiki/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. The first 1000 function https://www.wikifunctions.org/wiki/File:Jarnioux_-_Num%C3%A9ro_de_rue_1000_(sept_2020).jpg

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,

- 685 deal with strings - 223 deal with Booleans - 225 deal with numbers - 173 deal with lists and other types

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 https://www.wikifunctions.org/wiki/Wikifunctions:Catalogue#Natural_language_operations, 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. Senior Frontend Engineer position open for Wikifunctions

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 https://boards.greenhouse.io/wikimedia/jobs/5850672. Volunteers’ Corner recording is available on Commons

The recording of the last Volunteers’ Corner https://commons.wikimedia.org/wiki/File:Abstract_Wikipedia_Volunteer_Corner_2024-04.webm is now available for everyone to see on Wikimedia Commons. Thanks to all who participated! Recent Changes to the software

This week, we made some follow-up tweaks to the code for the new, public API (T360359 https://phabricator.wikimedia.org/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 https://phabricator.wikimedia.org/T356715). We no longer hard-code the internal label for what kind of evaluation is used, but show Z14K2 or similar (T358571 https://phabricator.wikimedia.org/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 https://phabricator.wikimedia.org/T360172). Similarly, we switched the expansion of Code objects to be ephemeral, so they're returned only by reference (T359872 https://phabricator.wikimedia.org/T359872). Finally, we fixed an unnecessary expansion of Types in lists (T324661 https://phabricator.wikimedia.org/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 https://phabricator.wikimedia.org/T361598), and consolidated the code into a central place (T315432 https://phabricator.wikimedia.org/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 https://phabricator.wikimedia.org/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 https://phabricator.wikimedia.org/T350497). We simplified some of our browser tests to be simpler and less likely to break as the code changes ( T349836 https://phabricator.wikimedia.org/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. Function of the Week: Padovan number https://www.wikifunctions.org/wiki/File:Padovan_triangles_(1).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 https://www.wikifunctions.org/view/en/Z15075, Wikipedia article https://en.wikipedia.org/wiki/Padovan_sequence).

Named for Richard Padovan https://en.wikipedia.org/wiki/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 https://en.wikipedia.org/wiki/Fibonacci_sequence (Wikifunction Z13835 https://www.wikifunctions.org/view/en/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 https://www.wikifunctions.org/view/en/Z15077, the tenth number as 3 https://www.wikifunctions.org/view/en/Z15078, and the hundredth number as 288,627,200,960 https://www.wikifunctions.org/view/en/Z15079. 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 https://en.wikipedia.org/wiki/On-Line_Encyclopedia_of_Integer_Sequences sequence A000931 https://oeis.org/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 https://www.wikifunctions.org/view/en/Z15085, 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:

- The recursive implementation https://www.wikifunctions.org/view/en/Z15076 following the definition, and - A sum of binomial coefficients https://www.wikifunctions.org/view/en/Z15091, as described on the Wikipedia article

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.