Wikifunctions:Project chat/Archive/2025/03

Wikifunctions & Abstract Wikipedia Newsletter #192 is out: Recent Changes in the software, Recording of Volunteer’s Corner, and talks in London

There is a new update for Abstract Wikipedia and Wikifunctions. Please, come and read it!

In this issue, we present two talks that will feature Denny as a speaker and we take a look at the latest software developments.

Want to catch up with the previous updates? Check our archive!

Enjoy the reading! -- User:Sannita (WMF) (talk) 15:12, 7 March 2025 (UTC)

This section was archived on a request by: 99of9 (talk) 00:35, 26 March 2025 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #193 is out: Upcoming NLG meeting, Recent Changes in the software

There is a new update for Abstract Wikipedia and Wikifunctions. Please, come and read it!

In this issue, we invite you to the next NLG SIG Meeting, that will take place on Tuesday March 18 at 16 UTC, and we take a look at the latest software developments.

Want to catch up with the previous updates? Check our archive!

Enjoy the reading! -- User:Sannita (WMF) (talk) 16:39, 15 March 2025 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 14:14, 6 April 2025 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #194 is out: Wikidata-based simple enumerations

There is a new update for Abstract Wikipedia and Wikifunctions. Please, come and read it!

In this issue, we introduce a discussion about a new kind of enumeration type, and we take a look at the latest software developments.

Want to catch up with the previous updates? Check our archive!

Enjoy the reading! -- User:Sannita (WMF) (talk) 12:06, 21 March 2025 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 14:14, 6 April 2025 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #195 is out: It’s about time

There is a new update for Abstract Wikipedia and Wikifunctions. Please, come and read it!

In this issue, we introduce a discussion about how to support the creation of a type for time that is compatible with Wikidata, and we take a look at the latest software developments.

Want to catch up with the previous updates? Check our archive!

Enjoy the reading! -- User:Sannita (WMF) (talk) 17:25, 28 March 2025 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 14:14, 6 April 2025 (UTC)

Constructed languages

I notice that toki pona has its own natural language object. toki pona is not a language that naturally evolved; it was made at the beginning of this century by a single person and some volunteers. It has a not-insignificant amount of speakers, but I wouldn't go so far as to call it a "natural" language. I'm sure some are fluent in it but I'd be surprised if there were native speakers in the language.

In general, does the natural language type extend to constructed languages? When it specifies "language naturally spoken by humans," what does naturally exactly mean in this context? Not to be pedantic, I just feel concerned that the type is being misused for this purpose (unintentionally, of course) or that a conlang like toki pona is in too broad of a scope for a type that appears to deal mostly with natural, organic languages rather than invented ones. — rae^5e <talk> 12:53, 12 March 2025 (UTC)

Natural means it's not a Programming language (Z61). Any language conceivably usable as a UI language qualifies. Feeglgeef (talk) 19:09, 12 March 2025 (UTC)

Is it possible to include new lines and/or tabs in the result validation of test cases?

Hi, Just have the title question. Thanks! Aram (talk) 17:09, 13 March 2025 (UTC)

Yes, just not through the UI. Feeglgeef (talk) 17:21, 13 March 2025 (UTC)

@Feeglgeef Could you clarify how to do that? I don't see any option to edit the source code—only the UI is visible to me. Aram (talk) 17:44, 13 March 2025 (UTC)

You'll need to use something like User:Feeglgeef/wikilambda editsource.js if you want to use it on wikifunctions.org Feeglgeef (talk) 17:50, 13 March 2025 (UTC)

@Feeglgeef Useful script! I'm still exploring it and haven't used it yet. I'm planning to create an interesting function as things go as I am planning. I'll let you know once it's successfully created. Thanks! Aram (talk) 18:10, 13 March 2025 (UTC)

@Feeglgeef I created Z23293, but I'm not sure why the test case Z23294 failed. I suspect the issue might be with Wikifunctions. Aram (talk) 19:24, 13 March 2025 (UTC)

Humours Suggestion...

On other porjects the central discussion has it's own name. Wikipedia: Viage Pump, Wikisource:Scriptorum, Wikivoyage: Traveller pub.. Can calling the central discussion here the 'Chalkboard" ? ShakespeareFan00 (talk) 20:58, 24 March 2025 (UTC)

On a more serious note: Are there plans to try and implement all the common functions in the CRC handbook? ShakespeareFan00 (talk) 20:58, 24 March 2025 (UTC)

Personally, I won't be working on many functions related to scientific measurements until we've implemented something like Wikifunctions:Type_proposals/SI_units, so that the units can be attached. 99of9 (talk) 01:19, 25 March 2025 (UTC)

Function request: Cartesian to Polar.

Input 1 matrix [x,y] Output 1 matrix [θ,r] Short text : Polar conversion of x,y to polar space, (centre at 0,0) Constraints: x,y,r are rationals (floats), θ lies in the range -π<0<π

The reverse could also be implemented. ShakespeareFan00 (talk) 23:28, 25 March 2025 (UTC)

These look worthwhile to me. A good place to put suggestions so that they stay on the record is at Wikifunctions:Suggest a function. --99of9 (talk) 00:37, 26 March 2025 (UTC)

Operations in polar shuch a shifting a point or reflecting it could also be implementedShakespeareFan00 (talk)

Function request:

Name: Charcter to Hershey. Input: Unicode code point.

Output: Hershey Character Number (Real), Occidental (Boolean)

Supplied with a Unicode character point, returns the number of the charcter in the numbers used to define the Hershey character sets. — Preceding unsigned comment added by ShakespeareFan00 (talk • contribs)

@ShakespeareFan00: what do you mean by "Hershey Character Number"? Is it Hershey fonts? (from what I gathered, there is no possible calculation, we have to do a one-on-one mapping, is it right? see https://github.com/Kaloffl/Hershey-Unicode-Mapping which is luckily free licensed). Cheers, VIGNERON (talk) 14:32, 26 March 2025 (UTC)

This would be a one to one mapping , if it is out of scope, LMK. The Occidental flag is because there is a seperate Japanese series of Hershey characters. And yes this is about the Hershey fonts. ShakespeareFan00 (talk) 15:10, 26 March 2025 (UTC)

Broken formulas

I tried asking on Telegram and didn't get a response, so trying here.

In the discussion right above this one ("Numeric type : Real number ?"), there are some broken Math formulas. I didn't look deeply into the configuration, but the possible reason is that wikifunctions.org not connected to Restbase. That's usually the thing that causes failures to render Math formulas.

It typically happens when a Wikipedia is created in a new language: the domain is created first, and some other services, like Content Translation, Wikidata, and Restbase, are enabled a few days later, and during these days, those things don't work.

AFAIK, Restbase is not used for many things except rendering Math formulas, and in some time in the future it is going to be completely disabled, and rendering Math will be moved to something else. But since it hasn't happened yet, perhaps Wikifunctions should be connected to Restbase so that people can use Math formulas?

Or maybe it is connected, and the rendering errors are caused by something else? Amir E. Aharoni (talk) 11:29, 27 March 2025 (UTC)

@Amire80: Restbase isn't installed here because it's not meant to be used on new wikis, and the owning team said expanding it to this new wiki family wasn't supported. Math rendering here is only supported via MathML/MathJax, but unfortunately we can't disable the broken mode, so if you've got that set in your preferences you'll see that form until it's no longer supported, yes. (As always, please file Phabricator tasks for technical issues.) Jdforrester (WMF) (talk) 16:51, 28 March 2025 (UTC)

Reference desk?

I have some functions and use cases I was wanting, I know they are 'defined' somewhere. Can we have a Refdesk equivalent to help find functions and implementations? ShakespeareFan00 (talk) 14:17, 28 March 2025 (UTC)

WF:Find has some helpful tips and a spot to ask at the end. Feeglgeef (talk) 14:22, 28 March 2025 (UTC)

Feature petitions page

I've made a page to add and sign petitions for Wikilambda features, to help the community voice priorities. Feel free to add some or sign existing ones. Feeglgeef (talk) 23:37, 27 March 2025 (UTC)

@Feeglgeef: This feels rather low-value compared to a conversation about what and why we might want to add features? I think it might be worth talking about things first before "voting" on them? Jdforrester (WMF) (talk) 16:48, 28 March 2025 (UTC)

Of course. I made this because I (and others on the telegram/IRC) feel some of our priorities have been consistently ignored (phab:T385895, phab:T386422, phab:T386671). I'm hoping to make our priorities clearer and more accessible with this. Feeglgeef (talk) 18:33, 28 March 2025 (UTC)

I wouldn’t say “ignored”, but the prioritisation process is opaque and lacks a mechanism for community input or interaction. But I agree that voting is not the priority! GrounderUK (talk) 23:30, 28 March 2025 (UTC)

Thanks for kicking this off. I’ve added the Feature requests that I have raised in the past and one that @99of9 and I discussed on Telegram. I haven’t looked at my Bug reports yet. I’m not happy with the page title; I think “Feature proposals” or “Proposed features” would be more appropriate. In my view, the page should include (our) high-priority Bug reports, but I don’t think we need to worry about the distinction. GrounderUK (talk) 09:58, 30 March 2025 (UTC)

Which number type to use on WP facing functions

We have two real options for which number type to use in Wikipedia facing functions for precision beyond the integer. These are:

• Rational number
• float64

This is an important choice, and I think it will be better to make an explicit choice now instead of going with whatever is initially most popular.

For clarification, Wikipedia facing functions are functions with the primary purpose of serving Wikipedias. They should generally use a capital letter and accept a language input. Feeglgeef (talk) 13:44, 9 March 2025 (UTC)

Rational number, because float64 is unnecessarily restricted in range. Rational number often has bad conversion out for Wikipedia use cases, but calls can always be wrapped in a function to fix this problem Feeglgeef (talk) 13:47, 9 March 2025 (UTC)

Maybe we should improve the display function for cases where the (simplified) denominator is divisible by 10 (or it is 2, 4, 5, 8?) , displaying as decimals? GrounderUK (talk) 14:32, 9 March 2025 (UTC)

No, we should keep our display function optimised for representing general values of the Type. It would be rare for the result of a wiki calculation to end up with a denominator being a power of 10. I agree with @Feeglgeef that we will need a range of formatting functions constraining sig figs, decimal places, expressing percentages, units, currencies, etc etc. That will be necessary no matter which underlying format we use. 99of9 (talk) 00:54, 10 March 2025 (UTC)

Oh, yes… a range of formatting options is the right way to go, but that’s not what we’ll go live with. The Wikipedia user will have a restricted range of functions, because they must read and display strings. They won’t be able to wrap functions according to the desired format; they’ll just get what the display function gives them. I imagine the “plain text” limitation means that the function call’s plain text evaluation can’t be embedded in Wikipedia-resident formatting either. GrounderUK (talk) 08:55, 10 March 2025 (UTC)

I understand that we can ultimately only return a string. But it's not clear to me that we won't be able to call a (formatting) function of a (calculating) function. Maybe I'm too hopeful? 99of9 (talk) 11:44, 10 March 2025 (UTC)

Maybe I’m too “realistic”? Wikifunctions can wrap useful functions for a range of formats, and Wikipedia users can choose from the wrapped functions (among others), I suppose. But we’d have to create such a wrapped function for every “useful” function for which fractions or long decimal strings would be inappropriate in Wikipedia. I don’t think that is necessarily evil and, of course, my understanding may be incorrect, but if we start down this track, it doesn’t much matter whether the wrapped function uses Rationals or floats. GrounderUK (talk) 15:12, 10 March 2025 (UTC)

If float64 has a renderer that outputs completely intelligible to the parser, this should work. I was also hoping that we could select from a list of approved renderers (that can also take inputs) attached to the type. This should hopefully make rational numbers more convincing for you on the WP editor and WP user end (again, the target of this RfC) Feeglgeef (talk) 13:13, 11 March 2025 (UTC)

float64 (or future SI measurement) is my current preference, but I think it is too early to decide what will be most useful until we can see the options in action. I don't buy the range restriction argument, because for a written work we will inevitably want to make it simple and readable (scientific notation, heavily rounded, or similar), and the values we deal with are very unlikely to be out of the enormous range that float64 permits. If we ever do need extreme values, it would be easy enough to write that particular function using rationals. If we really want to worry about edge cases, it would be good to figure out how to deal with irrationals well, because numerous maths articles need them (currently coded with markup). For regular pages it will be things like population/area or %increase in value, which will look terrible in our default rational display. If we have to write a wrapper anyway, then it won't usually matter what the underlying type is. 99of9 (talk) 00:46, 10 March 2025 (UTC)

• you can't represent irrationals with float64
• values are likely to be imprecise when calculations are done and such
• we should strive for a completely compatible system. Rational numbers are a superset of float64
• the way you want to render a number will obviously change from one article to the next, I don't think it's a good idea to pick a worse type because it has a renderer that's better in some cases

Feeglgeef (talk) 14:06, 10 March 2025 (UTC)

Despite the flaws you've pointed out, I still feel inclined to agree with 99of9 here on opting for float64. I believe many languages (such as JavaScript and Lua, if I recall) use floating-point numbers as the default decimal type or default number type in general. The imprecision that comes with using float64s will always remain an unfixable issue, but the higher bit width and fact that most outputs of float64 functions will end up getting rounded or truncated in the end anyways makes the issue manageable enough to warrant using it over rational numbers. I understand we are working with all manner of types here and going with what a bunch of programming languages do already is certainly not a very logical approach to take, but I point out the pattern because I feel its inclusion is for a meaningful reason beyond popularity, i.e. its versatility—among other things. Representing decimal numbers using their fractional parts, as well as other methods of representing decimals such as fixed-point, have their uses, but floating-point numbers seem like more of a sensible, foolproof default (barring imprecision). Of course, rational numbers will always exist on Wikifunctions, as will their associated functions, so defaulting to using floating-point numbers won't do much harm when an editor can always choose to opt for whatever type is most appropriate for their use case. It just makes the most sense to use float64 as the common denominator, in my opinion. — rae^5e <talk> 04:18, 11 March 2025 (UTC)

float64 is default? Rational numbers are literally the standard in math sense, float is arbitrary appeal to how computers work, which should again not be what we are targeting. The only real argument for float64 that presented is popularity in computing spaces (which is, again, not our target here) Feeglgeef (talk) 13:06, 11 March 2025 (UTC)

I don't know what you mean when you say "float64 is default?", but I didn't say or imply any of that, at least not intentionally. I'm not attempting to base the decision purely off of consensus. I concur with all of the things 99of9 says in the parent post, I was just adding my own thoughts on why I think float64 should be used. I wasn't pointing out the commonness of floating-points in programming languages as a rationale to use it as the default on its own, but I was using it to attempt to demonstrate the familiarity around it and the fact that, to me, its high usage communicates that it's acknowledged to be flexible, versatile, and unobtrusive enough for most use cases. I don't think any of those languages would opt for the type just due to consensus. — rae^5e <talk> 12:47, 12 March 2025 (UTC)

"but floating-point numbers seem like more of a sensible, foolproof default."

Rational numbers are much more versatile for anything that's not code, and, again, our goal is to abstract away from code. Appealing to an option that's worse because of ease of use in our context is short-sighted and only really offloads the cost from us to users.

I'd like to point out that the average Wikipedia editor or user has no idea what floating point is, and would very much like to just have things work and not see 0.3000000001 or something when they try to add 0.1 and 0.2.

Feeglgeef (talk) 19:13, 12 March 2025 (UTC)

I've given it some thought and I believe that if rational numbers don't incur a significant performance cost compared to floats, they would fit as a sensible, non-technical default—basically every wiki editor knows what a fraction is, but I'd imagine not many know what a mantissa is. My preference towards using them at this moment is not particularly strong, and I still believe more people should weigh in on this issue before a consensus is even remotely reached, but the unfixable problem of floating point precision errors is unignorable and you make a good point about them. We could always round or truncate the results, however, as I don't believe most editors will need to display the full range of precision of double-precision floats except in technical cases when demonstrating the type itself. When not displayed in full and errors are corrected by way of rounding, the results floats provide are still quite accurate; accurate enough for many scientific and graphing calculators to use them by default, at least, which at least means something for the mathematical capability of the type. Float values on Wikifunctions when not sent through a reader or display function are very, very unwieldy to use. I'm sure you remember that this is how they had to be interfaced with for a time (at least, from my perspective) and it made it very difficult to actually use them, being someone not strongly knowledgeable of the workings of floating-points in the first place. That being said, that was only temporary exposure to the more ugly parts of the type that in modern times is never required knowledge for use of the type itself in user-facing applications. Nasty precision errors are usually never seen due to correction or are told to users using them beforehand as a warning of what and what not to expect. I think float64 should hold some prominence in wiki-facing function calls, maybe by the discretion of the editor, maybe in special cases that warrant them (if ever there are any); irregardless, I believe most of what you said is correct, and I change my stance towards rational numbers, but not heavily. At this moment I'm primarily just concerned about how much overhead the latter (rationals) would have in comparison to the former. — rae^5e <talk> 13:06, 10 April 2025 (UTC)

You make some good points. Specifically on performance, it depends… Because a Z20838 is a more complex object, there are additional overheads before and after evaluation. For simple arithmetic, using converted Z20838 objects also tends to be more efficient because it’s all integer-based. No doubt there are more complex cases where it is more efficient, overall, to use float64s, so I suggest we try and find some and set them up as test cases so that we can see the differences. Ideally, that would be end-to-end, but we do not see the read and display performance in the evaluation of a test case. GrounderUK (talk) 13:34, 10 April 2025 (UTC)

If the goal is to replace some ParserFunctions/Lua calls while maintaining compatibility, wouldn't a function need to use float64 throughout? YoshiRulz (talk) 04:50, 10 March 2025 (UTC)

No? Float and Rational are in the same technical place when it comes to Wikipedia use. Feeglgeef (talk) 14:00, 10 March 2025 (UTC)

I don’t have a strong view on this, although I’ve never been keen on floats. I’ve created two functions that may be of interest.

• number as Rational number (Z23668): returns a Natural number, Integer or Float64 as a Rational number (returning a Rational number unaltered or simplified and an error for any other type)
• Rational number as simplest type (Z23660): returns a non-negative integer value as a Natural number object and any other integer value as an Integer object (any other Rational number remains unchanged)

I haven’t added these to the Catalogue as I’m not sure we want to be going down this route. GrounderUK (talk) 07:26, 9 April 2025 (UTC)

Numeric type : Real number ?

In order to allow π to be supported in my previously suggested cartesian/polar conversion function, I note that a 'real' type needed to be supported.

A 'real' differs from a rational in that it it can take any supportable numerical value.

Obviously for Wikifunctions purposes a real has a floor and ceiling value for positive/negative infinity, and underflow infinity ( i.e too close to zero). Can someone assist me on converting this into a formal explanation?

I had this so for for real : Constraint : Representation: "[0-9]*\.[0-9](\E((\+|\-)|)[0-9]*|)" Pi would then be - Function Name: Pi Function type: Constant value - Real. Constraint : 3.141... Unless in abstract there's a different way to define it.

Formal methods is not an area I thave that much experience with. ShakespeareFan00 (talk) 08:37, 26 March 2025 (UTC)

Defining a color for referenche elsehwere either as :

Representation:\#[0-9A-F]{6}. \* Hex String *\ Representaion: (\1\.\0|\0\.[1-9]+)\,{2}(\1\.\0|\0\.[1-9]+) \* 3 value float (0.0 < n 1.0 *\

We don’t have a Type proposal for Real numbers yet. We can support arbitrarily precise approximations for an irrational number as a Z19677 and we already have a float64 approximation for Z20862, but someone should propose a Real number type (or, perhaps, an Irrational number type) if they have a clear idea of how it might work. I’m rather drawn to the idea of a separate Irrational number type, without thinking it through… GrounderUK (talk) 10:28, 26 March 2025 (UTC)

One way it could work is to reprensent (comptable) real numbers by fonctions that take a precision and returns a rational number. <math>\pi<math> would be internally implementations of algorithms / formulas that computes it up to some arbutrary precision.

The arithmetic basic opération like addition would be higher order fonctions that takes real numbers as arguments and returns themselves a real number, so a function that takes a precision and returns a rational number that approximates the sum up to that precision. (A number of bits, or a number of decimals) TomT0m (talk) 12:35, 21 April 2025 (UTC)

I've started a little way down this track. A good example is pi approximation from Chudnovsky partial sum (f64) (Z23902), but with a rational return. --99of9 (talk) 23:47, 25 April 2025 (UTC)

@Dv103 made another very nice example of this at square root of rational with precision (Z24505), which I hope we can use as a general model. --99of9 (talk) 15:03, 5 May 2025 (UTC)

If I understand the proposal right, the proposal is not to create a type for real numbers, but rather functions that return a real number with an argument for the precision in one of the existing types. Is that right? That seems to take us pretty far.

To the best of my knowledge -- but I am not a mathematician -- the answer to the question of how to create a type for real numbers isn't obvious yet. See also this thread and this paper.

Having said that, and re-reading the thread and skimming the paper, it would involve two new types:

1. a number with a precision. Since we need that for the Wikidata quantity type anyway, we should probably have one such type that will also work for the Wikidata quantity type.
2. the type as described in the paper for even more goodness.

Just a thought. --Denny (talk) 10:39, 16 May 2025 (UTC)