|◀||Abstract Wikipedia Updates||▶|
Wikifunctions: a Compendium of Calculations
Twelve hundred years ago, the polymath Muhammad ibn Musa al-Khwarizmi wrote a book, The Compendious Book on Calculation by Completion and Balancing. He was born in Khwarazm in what is today Uzbekistan and wrote the book in Baghdad in what is today Iraq. The goal of the book was to help people find answers to a certain form of questions: for example, how to calculate inheritances (“a man leaves behind two sons and a daughter”), the area of a yard (“assume the yard has the shape of a rhombus”), prices for mercantile transactions (“ten for eight, so how much for four?”), and many other such practical questions for everyday life. Al-Khwarizmi drew on knowledge and practices from Indian numbers, Babylonian astronomy, and Greek mathematics (which had largely been lost in Greece and the West by that time). The book remained a major textbook on the topic for more than half a millennium, widely influencing mathematics and its notation, and answered questions for many people, whether it was on dividing their legacies, figuring out the size of their land, or buying and selling merchandise.
The book was in fact so influential that it gave us two words that are in widespread use today, with cognates in many languages: the word algebra, which is derived from the the Arabic word جبر (al-jabr), comes from the title of the book, and algorithm is derived from al-Khwarizmi, the name of the author. Even today, al-Khwarizmi's image graces the cover of some math textbooks in Ecuador, and the books seem to contain excerpts of his Compendious Book, too!
The importance and relevance of that book indicates one of the legacies Wikifunctions can aspire to: a compendium of methods on how to answer questions, including questions like the ones above, and many others too. Just as Wikipedia follows the spirit of Western enlightenment embodied in Denis Diderot’s and Jean le Rond d'Alembert’s Encyclopédie, or a Systematic Dictionary of the Sciences, Arts, and Crafts, Wikifunctions follows the Compendium as an achievement of the Islamic Golden Age, also sometimes called the Islamic Enlightenment.
It will be possible for functions in Wikifunctions to look like pure mathematics (“what is 25% of 1.5?”) or to look like questions that we might encounter in everyday life (“given a land parcel of 1.5 acres, how large would be one part out of four equal parts?”). It is known that translating from the latter to the former is not always trivial: a cousin of mine was struggling with fractions as a child. But once I rephrased the same questions to be about money instead of pure numbers, she answered each of the questions, and more, without any hesitation or error.
Both types of function can live in Wikifunctions side by side, and the everyday functions can use the pure mathematical ones in their implementations. Functions can form layers on top of other functions, and functions useful to calculate the amount of ingredients for recipes can build on top of functions for multiplication and unit conversion.
In Wikifunctions, functions will be accompanied by documentation explaining them. This documentation can guide users, and help them find the right function to answer their questions. How a function is named, how its arguments are named, the documentation surrounding functions – all of these can be major factors in making Wikifunctions more accessible and find a wider audience.
This puts a responsibility on the community to select accessible and understandable names for functions and arguments, and to offer documentation that makes a function relevant to the users of Wikifunctions. However, just as many of the examples in al-Khwarizmi’s book had a limited relevance to many people in many places in Europe, as they didn’t follow Islamic rules of inheritance, we have to be careful to draw on examples and naming sources beyond those rooted in the Western world. Even though the underlying mathematics is universal, the examples and use cases of the calculations often are not. I hope that we as a community will be mindful of our responsibility.
You can find a scan of an English copy of al-Khwarizmi’s compendium on Archive.org: archive.org/details/algebraofmohamme00khuwrich/
Interestingly, the translation also contains a translation into mathematical notation, which for some modern readers might be easier to read than the actual English translation. This would have been entirely inconceivable in al-Khwarizmi’s time.
By the way, my cousin? She has grown up, and received a degree in economics a few years ago.
DUCT: Doing Unique Ci Things
Stef Dunlap, a software engineer in Test Engineering embedded in the Abstract Wikipedia team, is working on running end-to-end tests on per-patch ephemeral test environments. The tests are orchestrated using GitLab CI (Continuous Integration) on Wikimedia's Gitlab instance. The ephemeral test environments are run on a small kubernetes cluster on Cloud VPS. A small bridging layer written in Rust running on Toolforge keeps these environments in sync with Gerrit patches.
This novel approach, with the working title DUCT (Doing Unique Ci Things) aspires to establish a pattern that other Wikimedia projects with auxiliary services can use to run reliable end-to-end tests and manually test features in single-tenant test environments (as opposed to the multi-tenant Beta Cluster) while leveraging existing Wikimedia Foundation tools and adopting new technologies that are being invested across the Wikimedia movement.
Stef will present her work next Tuesday, February 21, 2023, at 17:00 UTC. The talk will be recorded and made available afterwards. Interested parties are invited to join on Google Meet, and there will be some opportunity for questions. The link to the talk is: meet.google.com/tpn-fafq-ekj
Public NLG meeting on February 21, 2023
Next Tuesday, February 21, 2023, at 16:30 UTC, we will have our second public NLG (Natural Language Generation) workstream meeting. The meeting will be on Jitsi and can be joined here: meet.jit.si/AWVolunteersCorner
This meeting will feature a presentation by Maria Keet about the design of the "abstract content" language for writing "constructors", which are those pieces of structured information that are positioned between Wikidata and Wikifunctions as a source on the one side of the pipeline and the machinery for rendering that content into natural language sentences or paragraphs of text on the other side in the pipeline. We hope to take a step forward from its discussion document of November 2022 towards more and more concrete, required features for the data structure specification.
Apologies for the two events overlapping.
Development updates (as of February 10)
- In order to leave Goal 2 (efficient and correct evaluation) in a good state, work has started on replacing the current evaluator, which covers all native programming languages we support, with individual evaluators for each programming language. This will allow for easier introduction of more programming languages in the future, and, more importantly, to switch support for individual programming languages on and off in case a need arises, e.g. to buy time in response to critical vulnerabilities in a specific language runtime. This is a requirement from the security review.
- In Goal 6 (stable and secure system) many user rights and user groups were defined and created. These are needed to define specific actions that only certain users should be allowed to do, which are unique to the Wikifunctions environment. That includes creating new types, activating and deactivating implementations and testers, etc.
- In Goal 5 (default view), work on the list component is ongoing, which is one of the two major components remaining in this goal. At the same time, designs for Goal 5 and for Goal 9 (updating the other components) have progressed or even finalized (including the selection of icons for different modes, and a beautiful design for implementations).
- For Goal 3 (meta-data), the last major patch for reordering implementations has been sent to review, bringing us close to closing this goal. This will allow us to choose efficient, instead of the current approach of random, implementations to run for a given function, which will make the runtime of the system more predictable and use fewer resources.