The on-wiki version of this newsletter can be found here:
https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-05-30
--
A single singular or a plurality of plurals?
<https://www.wikifunctions.org/wiki/File:Latin_dictionary.jpg>18th century
Latin dictionary
We are working towards functions being able to access data from Wikidata.
The first use-case we are aiming for is to access the lexicographic Forms
of a Lexeme, given a Lexeme ID. For example, consider a function that
creates sentences such as *“There are four apples.”*, where both the number
*“four”* as well as the noun *“apple”* are arguments to the function that
creates the sentence.
What should the Functions for accessing Lexeme Forms look like? If you have
ideas to sketch that out, please go ahead, unbound by technical
limitations. We’ll look forward to seeing your ideas and using them as
inspiration in order to mold what we can achieve technically on top of the
platform we have.
In the above example, we could have a Function that creates *“four”* based
on the natural number 4, and *“apples”* based on the Lexeme ID L3257
<https://www.wikidata.org/wiki/Lexeme:L3257>. The Lexeme has two forms:
L3257-F1 being *“apple”*, marked with the grammatical feature singular
<https://www.wikidata.org/wiki/Q110786>, and L3257-F2 being *“apples”*,
marked with the grammatical feature plural
<https://www.wikidata.org/wiki/Q146786>. In order to get the right Form, we
can either look up the relevant Form Id manually, which will hardly scale,
or we use the grammatical features to request the right form. In other
words, there could be a Function e.g. "return form" which takes a Lexeme ID
and a list of grammatical features and returns all matching Forms.
return form(L3257, [plural])
would return *“apples”*. Accordingly, for the Estonian verb *“amüseerima”* (to
amuse), we would make the call
return form(L350582, [third person, plural, present tense, indicative])
to return *“amüseerivad”*.
One question we will have is whether the English plural and the Estonian
plural should be the same object in Wikifunctions, or whether they should
be two different Objects. In Wikidata, the answer is that they are (in
general) the same Item, plural <https://www.wikidata.org/wiki/Q146786> –
the form for more than one, or zero, depending on the language. There are
several languages which have other grammatical numbers, such as *paucal*,
*dual*, *trial*, and others, which are not used in English and other
languages that only have the two. Even for languages that use only two
values, there are differences; for instance, English uses the plural form
for zero ('*He ate zero eggs*'), whereas French uses the singular ('*Il a
mangé zero œufs*', or more idiomatically '*Il n'a mangé aucun œuf'*).
In Wikifunctions, we could choose to have individual enumerations for each
language, which would have the advantage allowing for simpler, but
different user interfaces for each language, where we display only the
features relevant to a given language: so that for English we don’t show
the other number classes, or ask for grammatical features which are not
relevant for the language.
There are several different solutions, and the following list is not even
exhaustive:
1. a single enumeration of all grammatical features, as in Wikidata
2. shared enumerations for the groups of grammatical features, just as
cases, numbers, etc.
3. enumerations for the groups of grammatical features that actually
appear for languages, i.e. one shared enumeration for all languages that
use only the singular and plural
4. one enumeration for each language, and for each group of grammatical
feature
We have been discussing this question in the Natural Language Generation
Special Interest Group. Another solution that was mentioned was to use
sub-typing, for example to have “English numbers” be a subtype of the
“Grammatical numbers” type, with shared elements. But without Wikifunctions
having support for sub-types, this isn’t currently an option.
It is very likely that we won’t be able to resolve this issue fully until
we have actually built it and found in practice how it works out. It might
even be that we change some of the decisions later, as we discover patterns
of Wikifunctions usage that make Wikifunctions friendlier and easier to
use. But it would be good to start thinking about what we would like to aim
for and what the principles are along which we align our design decisions.
Recent Changes in software
The big piece of work that we landed this week was a comprehensive re-build
of the front-end code for how we show labels. As is standard with
MediaWiki-based tools, if your language was set to French, but there wasn't
a label in French and was one in English, we show the fallback English
label. Previously, we were resolving the label into a string based on your
view language and displaying that, which mostly worked, but meant that the
label would not be hinted for language or directionality when they were
different from the context. We now fully pass down the label's language,
and thus directionality, in all places (T343464
<https://phabricator.wikimedia.org/T343464>, T342661
<https://phabricator.wikimedia.org/T342661>). In the future, we may adjust
how fallback labels like this are displayed, possibly to explain inline
what language is being shown, and/or give a call-to-action to translate the
label; you can add ideas to the top-level task (T343460
<https://phabricator.wikimedia.org/T343460>).
Alongside the above work, we adjusted the function-calling API code to
correctly pass along the activity tracing headers (T365053
<https://phabricator.wikimedia.org/T365053>), and made a few code quality
improvements. Additionally, we have been investigating performance-related
issues with the back-end services, and hope to have more to report soon.
Function of the Week: days in month when not a leap year
<https://www.wikifunctions.org/wiki/File:Month_-_Knuckles_(en).svg>
Are you using your knuckles
<https://en.wikipedia.org/wiki/Knuckle_mnemonic> whenever
you try to remember how many days are in a given calendar month? No need
for that anymore! Welcome the function days in month when not a leap year
<https://www.wikifunctions.org/view/en/Z16332> (Z16332).
OK, admittedly, your knuckles may often be more readily available than
access to Wikifunctions, but let’s ignore that wrinkle for a moment.
The new Function takes a Gregorian calendar month
<https://www.wikifunctions.org/view/en/Z16098>, which we have introduced as
a new Type last week
<https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-05-22>,
and returns a natural number <https://www.wikifunctions.org/view/en/Z13518>,
depending on how many days that month has in a year that is not a leap year
(a complementary function for leap years
<https://www.wikifunctions.org/view/en/Z16332> also exists).
The function has twelve Tests, one for each month (making it a completely
covered Function), and currently two Implementations, both in Python:
- One Implementation using a lookup in a Python dictionary
<https://www.wikifunctions.org/view/en/Z16347>, where for each month
number we have the number of days,
- One Implementation using an unusual formula
<https://www.wikifunctions.org/view/en/Z16329> that I’ve never seen
before
One nice thing with a good, or even complete test coverage, like in this
case, is that you don’t even have to understand or prove the formula in
order to trust it (although that sure doesn’t hurt): you can simply check
that all test cases are what you would expect, and that they pass (as they
do).
Thanks to the community for so swiftly adopting the new Type, and for
having created more than a dozen new Functions using the new Type.
The on-wiki version of this newsletter can be found here:
https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-05-22
--
New Type: Gregorian calendar months
<https://www.wikifunctions.org/wiki/File:Wheel-of-life-mother-nature-forrer-…>*The
Wheel of Mother Nature: This is Her Image*, France, ca. 1400 CE. Atop the
wheel is Time, her four wings the seasons, with the months as feathers.
We are proud to announce our initial, flagship enumeration Type: Gregorian
calendar months <https://www.wikifunctions.org/view/en/Z16098>.
Gregorian calendar months are an enumeration of twelve values, starting
with January <https://www.wikifunctions.org/view/en/Z16101> and February
<https://www.wikifunctions.org/view/en/Z16102> and going all the way to
November <https://www.wikifunctions.org/view/en/Z16111> and December
<https://www.wikifunctions.org/view/en/Z16112>. For testing purposes, we
created two functions for now: "same month
<https://www.wikifunctions.org/view/en/Z16137>", discussed below as the
Function of the Week, and "following month
<https://www.wikifunctions.org/view/en/Z16136>", which returns the month
that follows the given month.
We are curious to see what kind of functions you will build with that.
Unlike with Natural numbers <https://www.wikifunctions.org/view/en/Z13518>,
we don’t expect to see a large number of new functions immediately – but we
would be very happy to be surprised! Eventually, Gregorian calendar months
will be used as a building block for dates of the Gregorian calendar,
increasing the number of functions this type will be used with.
Thanks to the Wikifunctions community for being a great sport! When we
created this Type, we merely put a small plea into the English description,
asking not to use it yet. And indeed, this wish was mostly respected, which
allowed us to fix one more bug before we rolled it out today.
Please let us know if there are problems or wrinkles with using the new
Type. We will keep monitoring the situation as best as we can.
We also hope to swiftly add more enumeration Types, particularly for month
enumerations for other calendar systems. It would be great if you could write
proposals for those
<https://www.wikifunctions.org/wiki/Wikifunctions:Type_proposals>, so that
in a few weeks' time we can start creating them. If major issues are not
discovered, and any minor issues resolved, we plan to move on with more
enumerations, first for calendar months and then for other domains, in as
early as two or three weeks.
If you have any questions, please feel free to ask! Thank you for your
coöperation and help with this rollout.
Recent Changes in the software
Our main work this Quarter is around the eight areas
<https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-05-03> we
set out earlier. For enumeration support in Types, as mentioned above, we
rolled out a fix for the production services, which was about not eagerly
evaluating type references in Objects when they're marked as identities in
their Type. With this, as discussed above, we hope that the feature work
here is complete for the Quarter (T363390
<https://phabricator.wikimedia.org/T363390>), and have been focussing on
the other areas.
Our most visible next set of changes will be improvements to how labels are
shown in different languages (T363383
<https://phabricator.wikimedia.org/T363383>). The first improvement here is
that you can now use MediaWiki's fake language code qqx as a view language,
which will help you translate Wikifunctions better, by letting you identify
Object keys and interface messages; you can see this by visiting
view/qqx/Z801 <https://wikifunctions.org/view/qqx/Z801> (T359999
<https://phabricator.wikimedia.org/T359999>).
In other priority areas, we continued our work on streamlining,
simplifying, and otherwise improving our browser tests (T349836
<https://phabricator.wikimedia.org/T349836>) as part of our general testing
improvements work (T363389 <https://phabricator.wikimedia.org/T363389>). We
have been adjusting our back-end services' control and information flow to
make the work to better report sub-call meta-data possible (T363384
<https://phabricator.wikimedia.org/T363384>). We have also been examining
service performance and management issues within our work to better monitor
production (T363387 <https://phabricator.wikimedia.org/T363387>).
Outside of our priority work, we tweaked the load-order of our front-end
code, to avoid occasional race-conditions in our dependencies on MediaWiki.
Our production services now run on Node 20, up from Node 18, and have had
various minor bug fixes deployed. Our database-accessing code in MediaWiki
was made more modern, now using the expression builder abstraction layer in
most places (T350993 <https://phabricator.wikimedia.org/T350993>). Thank
you to Umherirrender
<https://www.wikifunctions.org/wiki/User:Umherirrender> for
this, and many other improvements for Wikifunctions and the wider Wikimedia
ecosystem, over the years.
We tweaked our languages, updating Z1221/nan
<https://www.wikifunctions.org/view/en/Z1221> to merge in zh-min-nan; our
particular thanks to Winston Sung
<https://www.wikifunctions.org/wiki/User:Winston_Sung> for their leading
work on cleaning up our language support (T348370
<https://phabricator.wikimedia.org/T348370>).
We, along with all Wikimedia-deployed code, are now using the latest
version of the Codex UX library <https://www.mediawiki.org/wiki/Codex>,
v1.6.0, as of this week. It should have no user-visible changes on
Wikifunctions, so please comment on the Project chat or file a Phabricator
task if you spot an issue.
Call for Functions: Spell out the number!
Last week, we called for you to create functions which spell out numbers
<https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-05-15> in
different languages, and you have answered. As of now, functions for
fifteen languages have been set up: Bengali, Croatian, English, French,
German, Igbo, Klingon, Low German, Malay, Moroccan Arabic, Polish,
Ukrainian, Standard Arabic, Swedish, and Láadan.
A page for this project
<https://www.wikifunctions.org/wiki/Wikifunctions:Cardinal_numbers> has
been started, and we are looking forward to seeing the project develop. If
you need any help, feel free to ask!
Wikifunctions on Beta Cluster broken
For the last week or two, Wikifunctions on Beta Cluster has been failing.
We are investigating, but are a bit of a loss of what the issue is. We
currently have no prediction when this will be fixed.
Function of the Week: Same month
Since we just introduced a new Type, Gregorian calendar month
<https://www.wikifunctions.org/view/en/Z16098>, we also created two
functions. One very useful function for every new Type is the identity
function, which checks whether two given values are the same. We named the
function "same month <https://www.wikifunctions.org/view/en/Z16137>".
It takes as input two arguments of our new Type for Gregorian calendar
months, and returns a Boolean <https://www.wikifunctions.org/view/en/Z40>
value: true <https://www.wikifunctions.org/view/en/Z41>, if the two months
are the same, and false <https://www.wikifunctions.org/view/en/Z42>
otherwise.
The identity function is the most basic function for all enumerations, and
it allows checking for the value of the enumeration. We can see it in
action in the composition for "following month"
<https://www.wikifunctions.org/view/en/Z16148>, using eleven ifs
<https://www.wikifunctions.org/view/en/Z802> sequentially, checking the
argument against all possible values and then returning the appropriate
answer (that particular implementation times out currently, though, an
issue we are working on).
For "same month", we created six tests (out of a possible 144 tests, which
would be a bit excessive). We created three pairs of text, each pair with a
test that should return true, and one that should return false. The three
pairs in turn are once using the month as a literal, once as a reference,
and once a mixed function call:
1. Checking that two literals are the same
<https://www.wikifunctions.org/view/en/Z16138>
2. Checking that two literals are different
<https://www.wikifunctions.org/view/en/Z16139>
3. Checking that two references are the same
<https://www.wikifunctions.org/view/en/Z16140>
4. Checking that two references are different
<https://www.wikifunctions.org/view/en/Z16141>
5. Checking that a literal and a reference are the same
<https://www.wikifunctions.org/view/en/Z16228>
6. Checking that a literal and a reference are different
<https://www.wikifunctions.org/view/en/Z16229>
There are two implementations for the function, one in Python
<https://www.wikifunctions.org/view/en/Z16143> and one in JavaScript
<https://www.wikifunctions.org/view/en/Z16142>. And although both of them
look very different – they use the identity operator of the given language
to compare the two values – they work quite a bit differently for the two
languages: in both languages, the incoming value is translated to a number,
but, following the standard libraries of both languages, in Python January
is represented by a 1, whereas in JavaScript January is represented by a 0.
The on-wiki version of this newsletter can be found here:
https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-05-15
--
Call for Functions: Spell out the number!
Natural numbers, like most things, have different words for them in
different languages <https://en.wikipedia.org/wiki/Numeral_(linguistics)>.
A number such as 7 is called *‘seven’* in English, *‘sedam’* in Croatian,
*‘ayɔpɔin’* in Dagbani, *‘asaa’* in Igbo, and so on. In many languages,
names of larger numbers are often composed according to rules from smaller
numbers.
<https://www.wikifunctions.org/wiki/File:Chiffre-babylonien-1000.svg>The
number 1000 in Babylonian cuneiform.
For many numbers, Wikidata offers names. Either through lexemes such as
L347774 <https://www.wikidata.org/wiki/Lexeme:L347774>, or on labels on the
respective items, such as on Q23350 <https://www.wikidata.org/wiki/Q23350>.
In Wikifunctions, we already have a function to create names for the
English cardinal numbers <https://www.wikifunctions.org/view/en/Z13587>. It
is presented below as the Function of the Week.
For other languages, we don’t have that function yet. This is a call to the
community to create such functions for the languages that you speak!
In order to help with kicking those off, we drafted a PAWS Notebook
<https://public-paws.wmcloud.org/User:Denny/numbers/numbers.ipynb> to
create a first draft of the function implementation in JavaScript, using
the lexemes and labels in Wikidata for a given language. Feel free to ask
Denny <https://www.wikifunctions.org/wiki/User_talk:DVrandecic_(WMF)> to
run the function for your language.
Instead, you may also want to use one of the implementations of the English
function below as a template and adapt it to your language.
One interesting source of inspiration for this might be Grammatical
Framework’s solution for creating number names
<https://github.com/GrammaticalFramework/gf-contrib/tree/master/numerals>,
or any of the many <https://github.com/marlun78/number-to-words> libraries
<https://github.com/kwn/number-to-words> doing the same thing.
Looking forward to seeing how this challenge develops! Let’s spell out the
number!
Recent Changes in the software
One of our big pieces of work this Quarter is supporting identity Types,
like singular/plural or passive/active (T363390
<https://phabricator.wikimedia.org/T363390>). This week, we landed
middle-ware and front-end support for identity keys in Types (T363405
<https://phabricator.wikimedia.org/T363405> and T363497
<https://phabricator.wikimedia.org/T363497>); expect further movement on
this soon!
The "About" dialog, where you can add and edit labels, short descriptions,
and aliases, now updates the 'count' of available languages consistently
with the publish state (T346031 <https://phabricator.wikimedia.org/T346031>).
The information in the pop-up meta-data dialog is now rounded to 4
significant figures, rather than letting floating-point noise obscure the
main information in *e.g.* how long a function call took to run.
We also landed some more minor fixes, including consolidating our front-end
code to have only one method to determine if you're creating a new Object (
T358596 <https://phabricator.wikimedia.org/T358596>), and improving our
browser tests to be more reliable and focussed on testing the main expected
behaviour (T349836 <https://phabricator.wikimedia.org/T349836>). We added
some logging when language look-up unexpectedly fails in the server-side
code (T357702 <https://phabricator.wikimedia.org/T357702>), though we think
this should now be fixed due to database content updates that landed last
week.
We also updated our code-documentation generation to use the latest
template, and tweaked our JavaScript code to align with Wikimedia-wide
coding style updates, using defineComponent() for making Vue components
clearer to linters, and avoiding the unnecessary jQuery's $.extend() in
favour of Object.assign().
Function of the Week: English cardinals
English cardinals (Z13587 <https://www.wikifunctions.org/view/en/Z13587>)
is a function that, given a natural number, provides the name of the number
in English. Looking at the tests, we can find the following examples:
- 42 is <https://www.wikifunctions.org/view/en/Z13589> *forty-two*
- 0 is <https://www.wikifunctions.org/view/en/Z13590> *zero*
- 101 is <https://www.wikifunctions.org/view/en/Z13591> *one hundred and
one*
- 777777777777 is <https://www.wikifunctions.org/view/en/Z13592> *seven
hundred and seventy-seven billion seven hundred and seventy-seven million
seven hundred and seventy-seven thousand seven hundred and seventy-seven*
- 12 is <https://www.wikifunctions.org/view/en/Z13593> *twelve*
- 777777777777777777777777777777777777777777777777 is
<https://www.wikifunctions.org/view/en/Z13594> *seven hundred and
seventy-seven quattuordecillion seven hundred and seventy-seven
tredecillion seven hundred and seventy-seven duodecillion seven hundred and
seventy-seven undecillion seven hundred and seventy-seven decillion seven
hundred and seventy-seven nonillion seven hundred and seventy-seven
octillion seven hundred and seventy-seven septillion seven hundred and
seventy-seven sextillion seven hundred and seventy-seven quintillion seven
hundred and seventy-seven quadrillion seven hundred and seventy-seven
trillion seven hundred and seventy-seven billion seven hundred and
seventy-seven million seven hundred and seventy-seven thousand seven
hundred and seventy-seven*
- report an overflow error
<https://www.wikifunctions.org/view/en/Z13595> for
a number with more than 48 digits
The last should throw a proper error, not just a string that says error. We
need to work on this.
There are two implementations for this function, one in Python
<https://www.wikifunctions.org/view/en/Z13588> and one in JavaScript
<https://www.wikifunctions.org/view/en/Z15955>, both having a few dozen
lines of code and quite a bit more complex than most of the Functions of
the Week we have looked at so far. They may be used as templates for
implementations for other natural languages, supporting the Call for
Functions going out this week!
The on-wiki version of this newsletter can be found here:
https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-05-10
--
Flagship type for enumerations: Months of the Gregorian calendar
<https://www.wikifunctions.org/wiki/File:Plates_of_the_Twelve_Lunar_Months_L…>*Plates
of the Twelve Lunar Months, Ogata Kenzan (Japan, 1663-1743)*
As we announced last week
<https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-05-03>,
our work for this quarter includes developing type support for enumerations
<https://phabricator.wikimedia.org/T363390>. An enumeration is a type
consisting of a set of named instances. Unlike open types such as natural
number <https://www.wikifunctions.org/view/en/Z13518> or string
<https://www.wikifunctions.org/view/en/Z6>, which can be created on the fly
and can have an arbitrary number of instances, an enumeration must have all
its instances predefined. In Wikifunctions, all instances of an enumeration
must have distinct ZIDs and are distinct objects.
We already have a few types which could be regarded as enumerations, such
as Booleans <https://www.wikifunctions.org/view/en/Z40> (with the two
values true <https://www.wikifunctions.org/view/en/Z41> and false
<https://www.wikifunctions.org/view/en/Z42>) and natural languages
<https://www.wikifunctions.org/view/en/Z60> (with currently hundreds of
values). We will want many more enumerations in Wikifunctions, be it for
the sign of a number, weekdays, cardinal directions, and much more. For
natural language generation, we will need it to represent grammatical
features, such as grammatical number, which we need for the function we
worked together on in this week’s Volunteers’ Corner (see below).
Just like last quarter with natural numbers
<https://www.wikifunctions.org/view/en/Z13518>, we chose a flagship type to
go as the first new enumeration type: months of the Gregorian calendar
<https://www.wikifunctions.org/wiki/Wikifunctions:Type_proposals/Gregorian_c…>.
The community is invited to join the discussion of the specification:
should this also encompass the Julian calendar? Is there a good name for a
single type that covers both? What other considerations are there?
We would also like to ask the community to prepare and discuss similar
enumerations for other calendar systems, so that, once this type works, we
can move swiftly to create them in order to have parity across the world's
calendar systems.
Abstract Wikipedia at the Hackathon
Our tech lead, James
<https://www.wikifunctions.org/wiki/User:Jdforrester_(WMF)>, attended the
annual Wikimedia Hackathon
<https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2024> as a volunteer
last weekend, which took place in Tallinn, Estonia. He was glad to meet
several existing Wikifunctions community members, and help explain the
Wikifunctions and Abstract Wikipedia visions. There were extensive
discussions about linguistic variations and how our community might hope to
model them in forthcoming language generation functions. It was his
pleasure to assist someone making their very first function, even though
technical issues meant it didn't work at first. He and the rest of the team
looks forward to speaking with more people about Wikifunctions.
Recent Changes in the software
Over the past two weeks, we've focused on the areas we laid out last week –
Identity support on Types, production observability improvements,
multi-language interface design improvements, research for the future
Wikipedia integration, and much more.
Beyond that work, we've made a few minor improvements that some of you may
notice. We adjusted the front-end to batch requests for objects, grabbing
at most 50 items at once, rather than unlimited; though in practice we've
not hit this yet, in the future as community-written functions get more
complex, this would have been reached and caused odd breakages in the
front-end (T359035 <https://phabricator.wikimedia.org/T359035>). We fixed a
missed piece of internationalisation in the aria-label of the Toggle
button, for screen readers and other assistive devices (T362056
<https://phabricator.wikimedia.org/T362056>).
We consolidated our duplicate maintenance scripts for managing pre-defined
Objects, merging reloadBuiltinData into loadPreDefinedObject. We added the
last remaining feature from the internal ApiQueryZObjects Action API to the
new Fetch REST API, which will allow us to migrate to these cheaper, faster
calls in future (T274269 <https://phabricator.wikimedia.org/T274269>).
All Wikimedia-deployed code is using the latest version of the Codex UX
library, v1.5.0, as of this week. Though we do not believe the library
upgrade will have any user-visible changes in our use on Wikifunctions,
please comment on the Project chat
<https://www.wikifunctions.org/wiki/Wikifunctions:Project_chat> or
file a Phabricator
task <https://phabricator.wikimedia.org/project/view/4876/> if you spot an
issue.
Volunteers' Corner on May 6th
We met with some of our wonderful Wikifunctions volunteers on Monday. We
discussed our work for this quarter in more detail and built a function
together for language-specific numerical singulars and plurals
<https://www.wikifunctions.org/view/en/Z15982>. The recording of the event
is available on Wikimedia Commons
<https://commons.wikimedia.org/wiki/File:Abstract_Wikipedia_Volunteer_Corner…>
.
Function of the Week: Binomial Coefficient (Z13848)
Binomial coefficients
<https://en.wikipedia.org/wiki/Binomial_coefficient> represent
the number of ways you can choose a certain number of items from a larger
set, regardless of the order. They're often represented as "n choose k",
where n is the total number of items and k is the number of items to choose.
<https://www.wikifunctions.org/wiki/File:Wikifunctions_binomial_function_res…>
For example, imagine we have five beads of different colors (Red, Blue,
Green, Yellow, Orange), and we want to randomly choose two beads from them
at a time. The binomial coefficient "5 choose 2" would tell us how many
different pairs of beads we can make. In this case, it would be 10 pairs:
1. Red and Blue
2. Red and Green
3. Red and Yellow
4. Red and Orange
5. Blue and Green
6. Blue and Yellow
7. Blue and Orange
8. Green and Yellow
9. Green and Orange
10. Yellow and Orange
So, binomial coefficients help you figure out how many combinations you can
make from a set of items. The image shows our function returning a result
of 10 for “5 choose 2” <https://www.wikifunctions.org/view/en/Z13848>.
Mathematically speaking, the binomial coefficient, often denoted as (nk),
represents the number of ways to choose k items from a set of n distinct
items, without considering their order. It's calculated using the formula:
(nk) = n!/(n-k)!
Where n! (read as "n factorial") denotes the product of all positive
integers up to n, and k! is the factorial of k, and so on. We have a function
for the factorial <https://www.wikifunctions.org/view/en/Z13667>, too,
which is used in one of the compositions
<https://www.wikifunctions.org/view/en/Z13907>.
The binomial coefficient function on Wikifunctions has 4 implementations –
2 compositions, and 2 implementations in Python :
- binomial composition via factorial
<https://www.wikifunctions.org/view/en/Z13907>, as just mentioned
- binomial coefficient, python
<https://www.wikifunctions.org/view/en/Z13850>, looping for a factorial
- binomial recursive composition
<https://www.wikifunctions.org/view/en/Z13912>
- binomial coefficient, python
<https://www.wikifunctions.org/view/en/Z14852> (using math.comb from the
standard library)
Binomial coefficients find their practical uses in probability predictions,
to find the chance of getting a specific number of successes in a series of
trials with only two possible outcomes or the likelihood of winning the
lottery, or combinatorics , to count different ways to arrange or choose
things, like distributing items into groups or selecting members for a
committee.
The on-wiki version of this newsletter can be found here:
https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-05-03
--
Team meeting in San Francisco
<https://www.wikifunctions.org/wiki/File:Maiden_Lane,_San_Francisco_-_View_f…>Maiden
Lane, San Francisco, view from near the office
Last week saw our annual team meeting, and this time we gathered for the
first and last time in the current office space of the Wikimedia Foundation
in San Francisco. Some of us met for the first time, and we used the
meeting to get to know each other, and to sketch out our plans for upcoming
work on Abstract Wikipedia and Wikifunctions.
We improved our shared understanding of the project and how we work
together, and one of the results is our plan for this quarter, which we
present below.
We also had interesting discussions around how Abstract Wikipedia could
look like in the future. We want to capture some of the thoughts from that
session in more detail in an upcoming update, as it opens many questions
for how Abstract Wikipedia can flourish and grow as a project that is
rooted and anchored in the work of our contributors.
It was a bittersweet opportunity for the team to see the current office, as
the Wikimedia Foundation will move to a smaller office space
<https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/…>
in
the fall as our lease ends.
Quarterly planning
One of the results of the meeting was to establish a plan for the current
quarter. Here is a quick overview of the main tasks we will be working on:
- *Visual prototype for Wikipedia integration
<https://phabricator.wikimedia.org/T363392>*: based on our ongoing
research, what could designs for the integration of Wikifunctions into
Wikipedia look like? This will also be used to improve cross-functional
collaboration and to identify next steps towards building Abstract
Wikipedia.
- *Type support for identity / enumeration
<https://phabricator.wikimedia.org/T363390>*: supporting types that have
a specific set of values, such as grammatical number in English (plural,
singular), cases in Russian (nominative, dative, etc.), signs for integers
(positive, negative, and neutral), or months in the year (January,
February, etc.). This should allow us to create all types that are
necessary to access lexicographic data in Wikidata, which would come next.
- *Improve production monitoring
<https://phabricator.wikimedia.org/T363387>*: so we have an easier time
understanding when something goes wrong, or where the time in orchestration
and evaluation is going. This will also inform future work on caching,
which is critical for integration into Wikipedia.
- *Improve integration with MediaWiki core tests and other test support
<https://phabricator.wikimedia.org/T363389>*: changes to core are
currently not automatically tested against the WikiLambda extension. We
will work on changing that.
- *Demos in a box <https://phabricator.wikimedia.org/T363394>*: provide
resources that help community members to give presentations about
Wikifunctions and Abstract Wikipedia.
- *Wikifunctions’s UX drives user behavior to increase linguistic
accessibility <https://phabricator.wikimedia.org/T363383>*: changes to
the UX that make it easier for users to provide missing translations and a
better experience in other languages than English.
- *DB table for expanded metrics support
<https://phabricator.wikimedia.org/T363439>*: allow for collecting more
metrics about Wikifunctions.
- *Help users debugging implementations by providing more metadata
<https://phabricator.wikimedia.org/T363384>*: function calls are
currently a bit of a black box. We want to provide some more insight into
what is going on inside a function call, and this might help contributors
fix issues more easily.
An overview of this quarter’s work can be seen in a brand new Phabricator
board <https://phabricator.wikimedia.org/project/board/7067/>. All the
tasks listed above are represented in the column “Epics for this quarter”.
Recent Changes in the software and Function of the Week
Because this newsletter is already so long, and due to the team meeting and
the Hackathon, we are skipping these sections this week.
Volunteers’ corner on May 6
On Monday, May 6, 2024, we are going to have our Volunteers’ corner at
17:30 UTC <https://zonestamp.toolforge.org/1715016600>. Bring questions and
curiosity! We will give an overview of recent changes, ongoing work, have
ample opportunities to answer questions and discuss concerns by the
community, and if there’s time, also work collaboratively on a function.
Abstract Wikipedia team at the Wikimedia Hackathon in Tallinn
This weekend sees the Wikimedia Hackathon 2024
<https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2024> in Tallinn,
Estonia. James Forrester of the Abstract Wikipedia team will be there and
if you want to discuss anything about Wikifunctions or Abstract Wikipedia,
feel free to approach him. (Also, he’s an awesome fellow to chat with even
if you don’t.)
The on-wiki version of this newsletter can be found here:
https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-04-19
--
Welcome, Sharvani
We are happy to welcome Sharvani Haran to the team! Sharvani is currently
an engineer on the Mobile Apps team, and joining us temporarily to explore
the role of the Product Manager. I will let Sharvani introduce herself in
her own words:
<https://www.wikifunctions.org/wiki/File:Mysore_palace_illuminated.jpg>Mysore
palace
"I come from Mysore, India. Being born and raised in this city of palaces,
world-renowned for its Dasara celebrations
<https://en.wikipedia.org/wiki/Mysore_Dasara>, I have always been in awe of
India’s ancient wisdom, diverse culture and peace-loving temperament. I'm
fascinated by different cultures and traditions - marveling at our
similarities and celebrating our differences.
Growing up with my head in books, I spent all my childhood imagining all
things that were so foreign to me like the British cultural references in
‘The Famous Five’, or stepping into Huckleberry Finn’s St. Petersburg, or
wondering how children of the world would feel if they read ‘Malgudi days
<https://en.wikipedia.org/wiki/Malgudi_Days_(short_story_collection)>’ and
its cultural references to India. I have been a lifelong fan of literary
exchange.
Graduating as a computer science engineer, I have had the opportunity to
work on various interesting projects in diverse roles for 18 years. This
amazing adventure on the Abstract Wikipedia team feels like a natural final
destination for all such linguistic and literary passions that have been a
part of me. Thrilled to be here with an amazing team of people who are
trying to make knowledge sharing easy and seamless across languages."
You already met Sharvani when she had taken care of Newsletter #150
<https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-04-03>
two
weeks ago. Please join me in welcoming Sharvani on the team!
Recent Changes in the software
This week has been one of our regular "Fix-It" weeks, where we mostly focus
on technical debt and smaller feature improvements.
When you get an error when publishing an edited or new Object, we now show
the error's message and its context in a simpler way, so it should be
easier to understand, especially when multiple errors are returned (T345557
<https://phabricator.wikimedia.org/T345557>).
The internal APIs which filter by language now list and validate the
requested language against all the known languages to Wikifunctions, rather
than giving no guidance or validation (T362193
<https://phabricator.wikimedia.org/T362193>).
We improved our test coverage for several of our custom base Vue components
(T358207 <https://phabricator.wikimedia.org/T358207>), and corrected an
issue with our test code to ensure it works with asynchronous DOM actions (
T358204 <https://phabricator.wikimedia.org/T358204>).
Finally, we created a new language, now supported by MediaWiki:
Z1229/zgh-latn <https://www.wikifunctions.org/view/en/Z1229>.
Team meeting next week
Next week, the Abstract Wikipedia team is going to have our annual team
meeting. This time we are meeting in the office of the Wikimedia Foundation
in San Francisco. Among other things, we will be planning the next few
months of work. Because of the meeting, we are going to skip the regular
update next week, and will report on the results of our planning afterwards.
Function of the Week: Encode in Morse code
In the 1840s, electrical telegraphs became the standard system to allow for
fast communication. Two stations, connected with an electrical wire, would
send electric pulses along the wire. In order to be able to send and
receive messages, the stations had to agree on how to turn messages into
pulses, and how to interpret a series of pulses as messages again.
<https://www.wikifunctions.org/wiki/File:International_Morse_Code.svg>
For this, Morse code <https://en.wikipedia.org/wiki/Morse_code> was
developed. It consists of two types of pulses, a short and a long one, and
breaks between the letters as well as longer breaks between the words. The
encoding was meant to roughly support efficiency in English: letters that are
frequent in English <https://en.wikipedia.org/wiki/Entropy_coding>, such as
E or I had short codes, letters that are less frequent, such as Q or J, had
longer codes.
There are a number of slightly different codes. Wikifunctions provides
function Z10944 for the international Morse code
<https://www.wikifunctions.org/view/en/Z10944>. Enter a text, using the 26
letters of the English alphabet plus the letter é, and you get the Morse
code back: for example, the word Wiki will be encoded as ".-- .. -.- .." -
a pattern you might recognize in the Wikidata logo. Besides the letters,
the international code also covers some punctuation characters and digits.
The function has two implementations, one in Python
<https://www.wikifunctions.org/view/en/Z10945> and one in JavaScript
<https://www.wikifunctions.org/view/en/Z10968>. Both implementations
consist of a dictionary respectively a map with all the covered codepoints,
and some short code that uses these on the input. A total of seven tests
cover a number of different cases;
- A simple input such as Hello World
<https://www.wikifunctions.org/view/en/Z10947>
- The whole set of letters, both uppercase
<https://www.wikifunctions.org/view/en/Z10969> and lowercase
<https://www.wikifunctions.org/view/en/Z10946>
- Digits <https://www.wikifunctions.org/view/en/Z10948>
- Punctuation marks <https://www.wikifunctions.org/view/en/Z10949>
- Dropping characters which are not covered
<https://www.wikifunctions.org/view/en/Z10950>
- Collapsing multiple spaces
<https://www.wikifunctions.org/view/en/Z10951>
Wikifunctions has also function Z10956 for the inverse operation, decoding
Morse code <https://www.wikifunctions.org/view/en/Z10956>. It can be used
to take a text in Morse code and turn it back into the usual letters. ....
.- ...- . / ..-. ..- -. / .- -. -.. / .-- . / .- .-. . / -... .- -.-. -.- /
.. -. / - .-- --- / .-- . . -.- …
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_…>
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…>,
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…>
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.
The on-wiki version of this newsletter can be found here:
https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-03-28
--
Creating tests is now much easier!
<https://www.wikifunctions.org/wiki/File:Autofilled_tester.png>Automatically
filled Test case for the to lowercase
<https://www.wikifunctions.org/view/en/Z10047> function
Test cases are a crucial part of defining what functions mean and ensuring
all Implementations stick to that definition. And yet, the creation of a
good test has been somewhat challenging:
1. Go to the Function and click on the plus in the box of Test cases
2. Select the Function call you want to test, using search
3. Enter the arguments for the call
4. Select the Function to check the result, using search
5. Enter the arguments for the check
The idea is that the Test works by running the call you have built in steps
2 and 3, and then check the result with the Function built in steps 4 and
5. If the latter check returns true, the test has passed. If it returns
false, the test has failed.
Selecting the right Function to check the result isn’t always
straightforward: you need to be aware of the result Type of the Function
and must either search for, or simply know, the right Function to check the
resulting value.
A few weeks ago, we extended Types with the ability to know their equality
function, *i.e.* what is the Function, if it exists, for testing whether
two values of that Type are equal or not.
With this week’s release, the process of creating Test cases has been
considerably simplified: you click on the plus button, and both the
Function for testing and the Function for checking the result are
automatically selected and filled-in for you. You can still go and change
it – for example, if the pre-selected checking Function is not appropriate,
and you need something else. But you can now just click on plus, enter all
relevant arguments, and publish the Test case.
Thanks to Geno <https://www.wikifunctions.org/wiki/User:Geno_(WMF)> who was
the engineer behind this Quality of Life improvement! We hope that this
will make writing Test cases faster for all, and especially that it will be
simpler and easier for newer community members to understand how to do the
right thing.
Recent Changes in the software
A big piece of work we've been doing this week has been to create a
properly-documented API designed for gadgets, tools, and third parties to
call to run Wikifunctions. Expect details soon! Alongside that, we've made
some feature improvements to make using Wikifunctions easier.
First, as mentioned above, when creating a new Test case, we now auto-fill
the test call to the target Function being tested and, where possible, the
validator's call to the returned Type's equality function (T358214
<https://phabricator.wikimedia.org/T358214>).
Second, when prompted to pick a Type or a Natural language, we now use a
new feature of the Codex UX library to give suggested options rather than
expecting you to know the name of one already (T350037
<https://phabricator.wikimedia.org/T350037>). For Types, if you click into
the field it will suggest string and boolean; for Natural languages, it
will suggest the "United Nations Six" languages. In the future, this may
support more Types, and allow on-wiki control of what options are
presented; please discuss this on-wiki if you have ideas.
In terms of bugs, we fixed an issue where we always expanded new items in
lists, regardless of its Type (T359576
<https://phabricator.wikimedia.org/T359576>). We fixed the special page
listing Objects to use the primary label if it's available, rather than an
alias (T358805 <https://phabricator.wikimedia.org/T358805>). We corrected
the logic that decided whether to show a 'chip' in the page's header for
the Object label and sub-title for its Type, using the relevant language
chain for each label (T360000 <https://phabricator.wikimedia.org/T360000>).
All Wikimedia-deployed code is using the latest version of the Codex UX
library, v1.3.5, as of this week. Though we do not believe the library
upgrade will have any user-visible changes in our use on Wikifunctions,
please comment on the Project chat or file a Phabricator task if you spot
an issue. We have also upgraded the Ace library (from 1.14.0 to 1.32.7)
that provides the editor and syntax highlighter when writing code
implementations (which is also used when editing site JS/CSS pages, user
scripts, and gadgets). Similarly, the upgrade should not make any
significant changes, but please do highlight to us if you notice any issues.
Upcoming Volunteer’s Corner on April 8th[edit source
<https://www.wikifunctions.org/w/index.php?title=Wikifunctions%3AStatus_upda…>
]
The next Volunteer’s Corner will be on 8 April 2024 at 22:30-23:30 UTC
<https://zonestamp.toolforge.org/1712615400>. We scheduled it to a
different time, to accommodate different people than usual. The timing is
for now a one-off. We are still working on the timing in order to
accommodate as many people as possible, and are considering a rotating
timing, possibly having three different times each quarter. We appreciate
feedback and will be taking note of attendance.
The agenda of the Volunteer’s Corner is as usual:
1. Off-the-record time to ask questions
2. Recording starts
3. Update on the project (also shared online afterwards)
4. Time for questions
5. Work together on a function
6. Time for questions
7. Recording ends
8. Off-the-record time to ask questions
We are looking forward to meeting you! Let us know if you would like to
attend but the times so far didn’t work out and which times would work for
you.
Guest editor next week
I’m taking a week off, but we will have a guest editor next week!
Function of the Week: NOR (Z10231)
I have been looking forward to writing about the NOR function (Wikipedia
article <https://en.wikipedia.org/wiki/Logical_NOR>, Wikifunctions function
<https://www.wikifunctions.org/view/en/Z10231>) for a while. In fact,
that’s why I previously introduced the NOT
<https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-02-22#…>
and
the OR
<https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-02-28#…>
functions.
Nor is the negation of the or function. Just like the or function, nor is a
binary Boolean function: it takes two arguments of type Boolean and returns
one. Since or returns true if either of the arguments is true, nor returns
true only if neither one *nor* the other argument is true.
Just as the other binary Boolean functions, Nor has four Test cases
(corresponding to Nor's truth table):
1. True NOR true is false <https://www.wikifunctions.org/view/en/Z10233>
2. True NOR false is false <https://www.wikifunctions.org/view/en/Z10234>
3. False NOR true is false <https://www.wikifunctions.org/view/en/Z10235>
4. False NOR false is true <https://www.wikifunctions.org/view/en/Z10236>
These tests are complete in Wikifunctions, meaning that every possible
combination of inputs is covered with the tests. We won’t have that luxury
for many other Types!
So, what’s so special about NOR that makes me excited about it? The
interesting thing about NOR is that any other Boolean function can be
implemented by using just the NOR function. No matter how many arguments,
all you need is the NOR function, possibly several times, and nothing else.
Of the sixteen binary Boolean functions, only two have this special
property.
I am not saying that it’s a good idea to only use NOR, but it is possible!
We could have implementation for all our Boolean functions using only NOR,
which can be an interesting educational resource. The same is true for NAND
<https://www.wikifunctions.org/view/en/Z10243> (not-and). For example, the
NOT <https://www.wikifunctions.org/view/en/Z10216> function can be
implemented by using NOR with the same value in both arguments
<https://www.wikifunctions.org/view/en/Z14580>.
The NOR function has four Implementations:
1. In JavaScript <https://www.wikifunctions.org/view/en/Z10611>,
combining the language's ! (not) and || (or) operators
2. In Python <https://www.wikifunctions.org/view/en/Z10279>, combining
the not and or keywords
3. One composition <https://www.wikifunctions.org/view/en/Z10232> using
NOT
<https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-02-22#…>
and OR
<https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-02-28#…>
4. Another composition <https://www.wikifunctions.org/view/en/Z13488> using
two if <https://www.wikifunctions.org/view/en/Z802> functions
It can be an interesting exercise to think through the last composition and
understand why it results in the NOR function.
I always thought that the name of the function, “nor”, came from combining
the words “not” and “or”, similar to how the “nand” function is named for
combining “not” and “and”, but it seems I got my direction wrong: nor
simply comes from the English word “nor
<https://en.wiktionary.org/wiki/nor#English>”, and was then reinterpreted
as “not or” in order to be a pattern for “nand”.
This update is available on-wiki here:
https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-03-21
--
On the way to internationalizing numbers
<https://www.wikifunctions.org/wiki/File:Multiplication_without_renderer_set…>Multiplication
without renderer
We now have the ability to internationalize numbers in Wikifunctions by
implementing renderers and parsers
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2023-09-20>.
For now, this is only configured for natural numbers
<https://www.wikifunctions.org/view/en/Z13518>, but it should work for
future types out of the box.
However, there’s a caveat! It has not been tested at large scale yet, and
it currently runs into some speed issues. But let’s start with how it
should be working.
In the first screenshot, we see how the system used to work before, using
the example of the multiplication function: the instances of natural
numbers are expanded, displaying their type and their value as the string
types they use internally.
The second screenshot displays the status after we configured the renderer
(the display function) and the parser (the reading function) for natural
numbers. With these two functions configured, the UX collapses the values
into single lines, both for input (for the two arguments of the
multiplication) as well as output (for the result).
The configuration itself happens on-wiki, on the natural number type
<https://www.wikifunctions.org/view/en/Z13518>, where we can see that the
renderer is set to display natural number
<https://www.wikifunctions.org/view/en/Z14280> and the parser to read
natural number <https://www.wikifunctions.org/view/en/Z14290>. The right to
edit types will be handed over to the community at a later date, but the
configured functions are editable for you right now.
<https://www.wikifunctions.org/wiki/File:Multiplication_with_renderer_setup.…>Multiplication
with renderer
This makes the display for all functions using natural numbers much more
compact. But that’s not all! Both functions to display and read natural
numbers also take a natural language as a parameter, with the idea that
both displaying and reading the values can be adjusted based on the
language set in the user interface. As of sending this newsletter, this
argument is ignored, but things are almost all set up.
If you are not interested in gory technical details, you might want to skip
the rest of this section.
In order to display a number appropriately for a given language, we first
need to have a function to do so. On Wikifunctions, we already had a function
that formats a large natural number string by adding commas
<https://www.wikifunctions.org/view/en/Z13473>. But since it was defined on
Strings, we went ahead and recreated it for numbers
<https://www.wikifunctions.org/view/en/Z14295>, and made a little change
(more to initiate a discussion than to make an editorial decision), by
putting commas into the resulting display only if the number has more than
four digits. For the implementation, we basically copied
<https://www.wikifunctions.org/view/en/Z14301> the previous implementation
<https://www.wikifunctions.org/view/en/Z13474>.
This gives us a function to format the number for English texts. Now, we
need to somehow connect this function with the renderer function that is
set above. For that, we have created two new types that help us with
configuring which languages should use which function: a configuration of
functions for a given language
<https://www.wikifunctions.org/view/en/Z14294>, which uses the function
option for a list of languages
<https://www.wikifunctions.org/view/en/Z14293>. This has been used to
create a configuration for the display function
<https://www.wikifunctions.org/view/en/Z14302> and one for the reading
function <https://www.wikifunctions.org/view/en/Z14303>.
Furthermore, we need a function that selects the right function given a
language <https://www.wikifunctions.org/view/en/Z14310> from that
configuration structure. This is needed because different languages will
expect different ways of showing values – French and German will use dots
rather than commas as three-digit group separators, Indian English will use
commas like International English but in a different pattern than
three-digit groups, some languages might want to use non-Arabic digits for
familiarity, *etc.*. And finally, we need to apply
<https://www.wikifunctions.org/view/en/Z13036> the selected function to the
number. We discuss the apply function in the Function of the Week section
below.
But alas, as of now, this frequently times out. You can see the two
implementations connected to the display function
<https://www.wikifunctions.org/view/en/Z14280>: the simple one, that just
returns the unformatted string
<https://www.wikifunctions.org/view/en/Z14282>, and the implementation
trying to apply the appropriate function based on the language
<https://www.wikifunctions.org/view/en/Z14340>. As the latter randomly, but
rather frequently times out, it is currently disconnected, in order to
avoid disrupting the site.
What’s the call to action?
1. Create functions that display and read numbers as appropriate for
your language.
2. Add those functions to the configuration object for reading
<https://www.wikifunctions.org/view/en/Z14303> and display
<https://www.wikifunctions.org/view/en/Z14302>.
3. Help us speed up the system.
For the parsers, it is recommended to be lenient. If, for example, it is
common to enter numbers both in a language-specific script as well as with
Western Arabic digits, it is totally OK to allow for both. The current
default parser <https://www.wikifunctions.org/view/en/Z14304> allows for
commas and dots in any place, instead of ensuring that they split exactly
three numbers. It’s up to the community to make the editorial decision on
what they accept as input for a given language. A good quality check is if
the output of a Type's display function for a language is valid for the
reader function for that language – that it 'round-trips' without errors.
All of these are entirely new, early-stage mechanisms working on
Wikifunctions. We are curious to hear your feedback and to hear about what
works and what doesn’t. And also for creating more functions and for help
with getting this rolled out.
Recent Changes in the software
This week we worked on a few smaller features and bug-fixes, as well as
improvements to the back-end services. We adjusted how the new reading and
display functions for Types (parsers and renderers) are called, avoiding
confusing mis-readings of user input depending on how you clicked (T359987
<https://phabricator.wikimedia.org/T359987>). The edit link for old
revisions was mis-configured, and now actually points to the edit page for
that old revision, rather than the current one (T343653
<https://phabricator.wikimedia.org/T343653>); our apologies!
We addressed a missing feature in the table of Implementations on Function
pages, which showed only a '–' rather than the number of Test cases passed,
like '3/5' (T347536 <https://phabricator.wikimedia.org/T347536>). We
improved some of the Object conversion code, which should avoid mysterious
errors breaking the front-end experience in some cases (T357594
<https://phabricator.wikimedia.org/T357594>). We now allow empty strings to
be used in a function selector, unbreaking the experience in some edge
cases (T346006 <https://phabricator.wikimedia.org/T346006>).
We've improved the accessibility experience by adding longer, explanatory
titles for the three dialogs missing them using the 'aria-title' attribute,
and two icon-only buttons, one in the mode selector control, and the other
in the Function Explorer. We rewrote how fetching state is handled in the
front-end, which should handle pending status better when loading Test case
results (T360018 <https://phabricator.wikimedia.org/T360018>).
As part of our migration work for programming language references, we now
have a maintenance script that will update on-wiki content; we will run
this shortly (T287153 <https://phabricator.wikimedia.org/T287153>). We
audited our use of i18n and found a few messages that are no longer used;
their removal will reduce the burden on translators. Finally, we've started
tracking view actions on Function pages, so that we can better understand
who is using Wikifunctions and where we might need to improve (T357069
<https://phabricator.wikimedia.org/T357069>).
Ongoing discussion on identity
Last week we introduced a question on how to work with identity
<https://www.wikifunctions.org/wiki/Wikifunctions:Representing_identity>.
The discussion is ongoing, and the team will devote more time to the
discussion very soon.
Function of the Week: apply (Z13036)
Apply <https://en.wikipedia.org/wiki/Apply> is one of the most foundational
functions in computer science, and yet it is not available in a large
number of programming languages and systems, or only by going through
hoops. Apply, in the way it is defined in Wikifunctions,
<https://www.wikifunctions.org/view/en/Z13036> takes two arguments, a
function and a value, and applies the given function to the given value,
meaning that it runs the function with the given value as the argument.
One good way to understand the function is to look at the existing tests.
Tests always live a triple life:
1. They ensure that the implementations are working correctly.
2. They capture agreement and declare what the function is supposed to
do. If there are two possible ways a function could react, then tests can
be used to resolve that ambiguity.
3. They document for the reader what the function does by providing
examples.
In this case, we can benefit from the tests and read them as great examples
of what the apply function does:
1. The first test <https://www.wikifunctions.org/view/en/Z13047> applies
the reverse <https://www.wikifunctions.org/view/en/Z10012> function
(which was our first Function of the Week
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2024-01-11>)
to the string "abc", and it checks that we get "cba". Using apply with
reverse and "abc" is the same as calling reverse itself with the
argument "abc".
2. The second test <https://www.wikifunctions.org/view/en/Z13049> applies
another Function of the Week
<https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-02-22>,
not, to the value true, and checks whether we indeed get false. This shows
us that apply works across different types: it works both with strings and
Booleans.
3. The third test <https://www.wikifunctions.org/view/en/Z13347> applies
one of our earliest user-created functions, to uppercase
<https://www.wikifunctions.org/view/en/Z10018>, to the string "hello" and
checks that the result is "HELLO".
4. The fourth test <https://www.wikifunctions.org/view/en/Z14355> applies
the square function <https://www.wikifunctions.org/view/en/Z13663> to
the number 9, and checks that the result is 81. This demonstrates that it
also works with the new types, not just the initial, built-in types.
For now, this function can only be implemented as a composition, not in
JavaScript or Python, because we don’t yet allow code implementations to
call further functions.
The first implementation <https://www.wikifunctions.org/view/en/Z13048> was
created by 99of9 <https://www.wikifunctions.org/wiki/User:99of9>, and it is
entirely composed of built-in functions: it centers around the map
<https://www.wikifunctions.org/view/en/Z873> higher-order function (which
became famous as the first half of Google’s MapReduce
<https://en.wikipedia.org/wiki/MapReduce> technology), a function that
takes a list and a function, and applies the function to each element of
the list, resulting in a new list.
The rest of the function is taking the value and adding
<https://www.wikifunctions.org/view/en/Z810> it to an empty list, in order
to create the list necessary for the map function. Map is then applied to
that one-element list, and then first element
<https://www.wikifunctions.org/view/en/Z811> is used to get the resulting
value out of the list again.
To recapitulate: we take the value, put it in a list, map the list, and
then get the resulting value out of the list again. There’s a task to add
apply as a built-in function <https://phabricator.wikimedia.org/T357858>,
so that hop in and out of a list wouldn’t be necessary.
The second implementation <https://www.wikifunctions.org/view/en/Z14353> copies
the same approach, but skips the use of the function adding the value to an
empty list and instead creates a list directly with the value. I built it
because I expected it to be a bit faster, and hoped it would run the
display function faster.
The humor here is that I have previously scolded
<https://www.wikifunctions.org/w/index.php?title=Wikifunctions:Project_chat&…>
TomT0m <https://www.wikifunctions.org/wiki/User:TomT0m> and 99of9
<https://www.wikifunctions.org/wiki/User:99of9> for working on the apply
function and related functions, pointing out that we currently don’t have
great support for functions using functions. I would still prefer for these
things to be tried out on the Beta Cluster, where I had recreated their
apply function <https://wikifunctions.beta.wmflabs.org/view/en/Z13140>, but
to be entirely honest, without their work and their exploration I would
have been stuck trying to create the routing to the right function based on
the language. Thank you!
The on-wiki version of this newsletter can be found here:
https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-03-13
--
On identity <https://www.wikifunctions.org/wiki/File:Banana_-_Q503.jpg>A
banana with the QID for bananas. Note that Wikidata currently has no
individual banana <https://w.wiki/9TU7> 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
<https://www.wikifunctions.org/wiki/Wikifunctions: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 <https://phabricator.wikimedia.org/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
<https://wikifunctions.beta.wmflabs.org/view/la/Z11695> (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
<https://phabricator.wikimedia.org/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 <https://phabricator.wikimedia.org/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
<https://phabricator.wikimedia.org/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
<https://phabricator.wikimedia.org/T324661>), and to not hard-code an
English value for the meta-data value of what kind of Implementation is run
(T358571 <https://phabricator.wikimedia.org/T358571>). We've dropped an
old, now-unused API that was created to monitor the back-end services'
availability (T359179 <https://phabricator.wikimedia.org/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 <https://phabricator.wikimedia.org/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 <https://phabricator.wikimedia.org/T346852>). Our apologies!
All Wikimedia-deployed code, including Wikifunctions, are using the latest
version of the Codex UX library, v1.3.4
<https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/…>,
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
<https://us02web.zoom.us/rec/share/Jd1zfT2ADSzACJ8Fyrtn9-svAMxjgzcFjgWAt0n0a…>
(passcode: w%mj$Yp3).
Function of the Week: equality of natural numbers (Z13522
<https://www.wikifunctions.org/view/en/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
<https://www.wikifunctions.org/wiki/File:Abstract_Wikipedia_Volunteer_Corner…>
.
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 <https://en.wikipedia.org/wiki/Philosophy_of_mathematics> and
the question on what a number <https://en.wikipedia.org/wiki/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 <https://www.wikifunctions.org/view/en/Z13526>. 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
<https://www.wikifunctions.org/view/en/Z13519> that we are using and
the implementation
of equality using === <https://www.wikifunctions.org/view/en/Z13526> that
makes it work.
In Python, we don’t have to make that decision, and just use an implementation
with the == operator <https://www.wikifunctions.org/view/en/Z13533>.
The composition <https://www.wikifunctions.org/view/en/Z14118> uses
the built-in
string equality <https://www.wikifunctions.org/view/en/Z866> on the strings
resulting from casting both values to strings
<https://www.wikifunctions.org/view/en/Z13713>.
The function has four tests:
1. Two equals two <https://www.wikifunctions.org/view/en/Z13523>
2. Two does not equal zero <https://www.wikifunctions.org/view/en/Z13525>
3. 9007199254740992 and 9007199254740993 are not equal
<https://www.wikifunctions.org/view/en/Z14043>
4. A leading zero does not make two values unequal
<https://www.wikifunctions.org/view/en/Z13524>
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:
9007199254740992 == 9007199254740993
or
9007199254740992 === 9007199254740993
you will get the surprising answer:
true
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
<https://www.wikifunctions.org/wiki/Special:MyLanguage/Wikifunctions:Status_…>,
the validator should not allow for leading zeros.
.svg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.svg){kind=link}
