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.)
.svg){kind=link}
.jpg){kind=link}
