Wikifunctions:Project chat/Archive/2024/03

From Wikifunctions


Wikifunctions & Abstract Wikipedia Newsletter #145 is out: Type proposal for natural numbers

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

In this issue, we discuss our progresses with the new natural numbers type, we talk about events we are taking part to, and we take a look at the latest software developments.

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

Also, we remind you that if you have questions or ideas to discuss, the next Volunteers' Corner will be held on March 4, at 18:30 UTC (link to the meeting).

Enjoy the reading! -- User:Sannita (WMF) (talk) 11:40, 1 March 2024 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 15:30, 14 March 2024 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #146 is out: Introducing our second new type: Natural numbers

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

In this issue, we discuss the launch of the new natural numbers type, we talk about events we are taking part to, 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) 13:58, 8 March 2024 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 15:30, 14 March 2024 (UTC)

Recordings of Volunteer's Corner of February and March now available!

Hi all! Just a quick message to let you know that the recordings of February and March Volunteer's Corners are available on Wikimedia Commons:

From now on, the recording will be posted here at the Village Pump in the days following the Corner, and it will always be available in the specific Commons category. Sannita (WMF) (talk) 15:48, 6 March 2024 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #147 is out: On identity

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

In this issue, we discuss the notion of identity and present our latest document about how we represent it, 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:27, 14 March 2024 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 10:23, 4 April 2024 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #148 is out: On the way to internationalizing numbers

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

In this issue, we discuss our progresses with the implementation of renderers and parsers for natural numbers, 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) 14:11, 22 March 2024 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 10:23, 4 April 2024 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #149 is out: Creating tests is now much easier!

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

In this issue, we discuss our progresses with tests and how it is easier to make them, 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:22, 29 March 2024 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 10:23, 4 April 2024 (UTC)

Quick headsup: natural numbers are there!

Hey all, just a quick headsup before the official email this week: Natural numbers are there and open for business! Please report issues. We found one about typed lists of numbers reported by GrounderUK so far, but keep an eye out for more. --DVrandecic (WMF) (talk) 01:18, 6 March 2024 (UTC)

Maybe it's a silly question and not that important overall, but wasn't natural number type meant to be Z10 or other low ID? Msz2001 (talk) 06:09, 6 March 2024 (UTC)
It was, but we ran into issues and we felt that it was better to make it live rather than spend a week or so debugging just for the ID, which is cosmetic. We might move it later (once we support redirects). Jdforrester (WMF) (talk) 14:25, 6 March 2024 (UTC)
Note neither JavaScript nor Python has a natural number type; they instead has integer type that can be number below zero. GZWDer (talk) 12:05, 6 March 2024 (UTC)
I tried to change some functions to return natural numbers, but am getting errors that I don't have the ability to edit? "User does not have permission to edit" (even in qqx mode, so I cannot track down where this error is coming from). I tried updating both string length (Z11040) and get the first n elements of a list (Z13366) - is there some other permission that is needed to be able to change the types? I am a functioneer and admin --DannyS712 (talk) 18:42, 7 March 2024 (UTC)
I am however able to create functions typed with numbers, e.g. if (natural number output) (Z13846) --DannyS712 (talk) 19:02, 7 March 2024 (UTC)
Is the problem that I would need to be a function maintainer? In which case since we have not started granting that as a community, I guess no one can change the types? --DannyS712 (talk) 19:10, 7 March 2024 (UTC)
@DannyS712: Yes, you can't change the input or return type of a function without the wikilambda-edit-running-function-definition right, and in general, almost never. This is why we repeatedly said not to create functions prematurely before the types were created. I've edited the two functions to use Natural number input/return type as appropriate. Jdforrester (WMF) (talk) 21:32, 7 March 2024 (UTC)
I had thought that Admins could do it, which is the main reason I applied for admin! --99of9 (talk) 22:56, 7 March 2024 (UTC)
The rights are listed at Special:ListGroupRights. And yes, Functioneers can edit the type of disconnected functions, though that's meant for very early draft Functions that no-one is calling yet, as the disruption to users of breaking a live function would be immense. Jdforrester (WMF) (talk) 14:03, 8 March 2024 (UTC)
Yes, I read that list, and thought that maybe "Edit the type of an existing Object (wikilambda-edit-object-type)" would allow it, before I thought of the disconnecting trick. In any case, I expect we can all agree that a function marked with a "(!)" is early enough to change without immense disruption. They were always intended to be changed once the correct type was available. --99of9 (talk) 00:15, 9 March 2024 (UTC)
However, I've just tested, and found that the conversions can be done by functioneers, as long as we disconnect the implementations first. I just did this at is prime (Z12427) and I think everything worked. (Although I haven't looked for dependencies yet.) --99of9 (talk) 22:56, 7 March 2024 (UTC)
@Jdforrester (WMF) good to know, sorry about that - is it possible to request that right? @99of9 in the meantime your trick works great, thanks --DannyS712 (talk) 00:19, 8 March 2024 (UTC)
Is this also why I cannot add Echo Test case for natural numbers (Z13870) to Echo (Z801)? --DannyS712 (talk) 00:59, 8 March 2024 (UTC)
@DannyS712: I believe that we are not going to hand out that right yet, as it's premature whilst so much is in flux. Jdforrester (WMF) (talk) 14:04, 8 March 2024 (UTC)

Criteria for granting "maintainer" rights/editing running functions

In the discussion above it became clear that the community is currently unable to change the types of "running" functions without first removing all existing implementations and tests, and then afterwards adding them back. This seems like something we should avoid (also because those edits don't let you specify an edit summary). Per Wikifunctions:Maintainers

the community have not yet decided on what requirements or guidelines to follow around appointing members

and so it is up to the wikifunctions staff to decide whether to grant these rights. Because particularly the wikilambda-edit-running-function right would be very useful as new data types get rolled out, I think we should either start establishing criteria for the maintainer group, or allow functioneers (or maybe just admins?) to have the wikilambda-edit-running-function right. Thoughts? --DannyS712 (talk) 00:37, 8 March 2024 (UTC)

We are intentionally not handing it out at all; it is not ready yet. Jdforrester (WMF) (talk) 14:05, 8 March 2024 (UTC)

New type proposed: integers

Please see Wikifunctions:Type proposals/Integer and discuss there. Thanks, --DannyS712 (talk) 05:26, 8 March 2024 (UTC)

Article count

The current "article" count for this wiki is 7,119. I don't think the usual article count method, which is based on the presence of [[wikilink]]s, is appropriate for this wiki. Should we change it to count all pages in all content namespaces (currently only the main namespace)? - dcljr (talk) 03:00, 8 March 2024 (UTC)

It should probably be the same method as d:, where that is currently 108,764,588 (here, that number is "5,026" presently). ―Justin (koavf)❤T☮C☺M☯ 09:04, 8 March 2024 (UTC)
@Dcljr, @Koavf: If you look at our current configuration, we're already using the 'any' method (and did so at launch). Jdforrester (WMF) (talk) 14:14, 8 March 2024 (UTC)
Well, looky there. I coulda sworn there were more non-redirects in ns0 than that. But no. A "manual count" gives the same number. Thanks. - dcljr (talk) 00:40, 9 March 2024 (UTC)
No worries. :-) Jdforrester (WMF) (talk) 19:11, 11 March 2024 (UTC)

In functions, is speed, elegancy or simplicity more important? And is the function that is picked static?

(for below, I make the assumption that Wikifunctions would always pick the implementation which passes the most amount of tests, when I talk about there being two implementations, I mean two implementations that pass all (or an equal amount of) the tests for the function)

I'm aware that for now in this project that simply just getting enough functions is the main priority regardless of implication, but assuming in the future we start getting a large amount of implementations for a single function, does Wikifunctions have a preference? I'll take the example of a sorting algorithm using comparison sort, where the first argument is the list you wish to sort, and the second in a function that compares the elements in order to sort then. Assuming that there is two implementations, one being 'bubble sort', and the other being 'quick sort' (or any other faster algorithm). Would there be a preference? Would more easily understand code, which in this case be 'bubble sort' be picked. Or would it matter entirely on speed. if it were to be that speed was the main deciding factor, how would you measure that. Bubble sort would likely sort two elements in a list faster than quicksort since quicksort may define more variables before starting the trivial sort. But of course, in large list, quick sort easily beats bubble sort. If it were to be elegancy or simplicity, who decides that?

And about the second question asking if the implementation is static, because while we have things like tests to verify if a function works, but that doesn't guarantee it for all possible inputs. If the sin function using implementation A breaks at numbers above 2^32, while implementation B only breaks at numbers above 2^64, and the function you design (since this is a problem for the far future, let's assume that you're able to call Wikifunctions inside programming languages instead of only having compositions as I believe that is planned), and you call that for some function about light where you have to figure out if the light wave is at a peak amplitude millions of light years away from the source which may lead to a sin value above the 2^32 limit for Implementation A, what would happen then? Would Wikifunctions always pick the same implementation, or would it randomly change and cause a silent nasty bug that is hard to debug. Would you even be able to tell which implementation your light wave function is using? ListWorshiper (talk) 15:19, 9 March 2024 (UTC)

This wouldn't answer most of the issues above, but I believe there are cases when both faster and slower implementations are worthy placing into Wikifunctions. For example: a well known way of getting n-th Fibonacci number is to iterate n times, calculating all the subsequent numbers and to return the desired one. It's easy to spot mistakes in, to learn about the Fibonacci sequence (and perhaps has other benefits). However, it's not optimal. Whie being O(n), there's also an O(log n) algorithm that involves rasing a 2x2 matrix to n-th power. This algorithm is faster than the most natural one but having the two might help to ensure that the tests are well-written – the simpler one could assure us that we didn't make any mistake when specifying test cases and the quicker might be actually used by Wikifunctions engine most of the time.
I believe that some kind of cross-validation has been mentioned in past by the devs but rather as an idea, without the details. Msz2001 (talk) 15:33, 9 March 2024 (UTC)
Simplicity first!
Someone who does not know the specific programming language (or English) should be able to understand from the code how the simplest implementation of a function works. A composition will rarely be the most efficient implementation, but a fairly simple composition should be implemented wherever feasible. Once we have an implementation that clearly (simply, expressively, comprehensibly…) implements the function, more efficient or elegant alternatives can be implemented in addition.
During each evaluation of a function’s tests, the performance is monitored automatically and this feeds back into the selection of the implementation for future evaluations. Quite how sophisticated this is, I cannot say, but you occasionally see automatic updates by User:WikiLambda system, and there is a general explanation on that page. Oddly, it doesn’t mention accuracy or success. 🤔
If performance characteristics vary greatly and significantly according to the input, we’ll need to make sure that the available test-cases provide a reasonable sample. In the future, the selection of implementation might be made more sophisticated to vary according to input, but the trade-offs in such an approach are complex. For the time being, the performance overhead of the orchestrator tends to dominate, so adding further orchestration doesn’t seem sensible to me. That said, the selection of implementation is neither random nor static; if WikiLambda system consistently favours a generally less efficient or less accurate implementation (where additional test cases cannot fix this) I’m sure the community would not object to disconnecting that implementation (or reverting WikiLambda system’s update).
TL;DR? Z8K4. 😏 GrounderUK (talk) 11:07, 10 March 2024 (UTC)
I hadn't read the User:WikiLambda system documentation - that's neat. I think accuracy/success is supposed to be the job of the functioneers, so we shouldn't connect implementations which have inferior accuracy (except if it's due to timeouts IMO). --99of9 (talk) 11:45, 10 March 2024 (UTC)
Sounds sensible. Would you care to propose that here as our first or second Best practice? You might suggest that we should also actively disconnect currently connected implementations that are less accurate. I have a few qualifications to suggest, but let’s not get off-topic here. GrounderUK (talk) 19:44, 10 March 2024 (UTC)
Done. I threw in a bonus one of yours about connecting tests from a previous conversation. --99of9 (talk) 11:10, 12 March 2024 (UTC)

Translation questions

Who can explain "Reading function" in wikilambda-parser-unexpected-result-error? What translations have we used and how would they most naturally translate back into English?

What about "Display function" in wikilambda-renderer-unexpected-result-error? ("Error message for the string renderer returning an unexpected type as a result") Is it just “renderer” again? GrounderUK (talk) 16:59, 12 March 2024 (UTC)

Same thing at https://phabricator.wikimedia.org/T359960. It's generally really simple, and once I get an answer from someone who's familiar with the code and the terminology, the qqq can be quickly updated.
Going forward, it's important to document every message parameter ($1, $2, etc.), and every term that appears in the messages. Amir E. Aharoni (talk) 17:15, 12 March 2024 (UTC)
@GrounderUK: I've answered @Amire80 on the task, which might answer your questions too? Jdforrester (WMF) (talk) 17:38, 12 March 2024 (UTC)
Thanks, James. They were always Amir’s questions but there were no takers on Telegram. I didn’t know about the ticket. GrounderUK (talk) 17:54, 12 March 2024 (UTC)

Tests style

Is it good style to use Boolean identity (Z10215) and not (Z10216) in tests, like these are doing? Gut reaction is that while it's shorter code, it's not better code... --Azertus (talk) 20:06, 8 March 2024 (UTC)

@Azertus: Agreed, I'd expect people to use Boolean equality (Z844). One of the purposes of Tests is to communicate in a multi-lingual way how the Function should behave, so people who don't speak your language can potentially still propose Implementations that meaningfully pass; obfuscation is not good for that. Jdforrester (WMF) (talk) 20:44, 8 March 2024 (UTC)
I'm also guilty of recently switching to using "is" (Z10215) and "not" instead of setting up a boolean equality. Yes, I save a little labour when constructing the test. But my main reason is that the biggest problem with compositions in general is that they routinely time out in orchestration (as in this week's Function of the Week), and get listed as failing. Cutting a pass-through step in the validation seems worth it because it potentially allows the test to complete. I understand your concerns around obfuscation, but we may be able to solve that by choosing better-aimed primary labels for Z10215 (e.g. "is true?") and Z10216 ("is not true?"). --99of9 (talk) 23:57, 8 March 2024 (UTC)
@99of9: I don't see how you'd actually get any speed improvements with that, though. Jdforrester (WMF) (talk) 19:13, 11 March 2024 (UTC)
@User:Jdforrester (WMF) The first one I tried agrees with your expectation (is divisible, composition (Z14101)): these two are currently showing *exactly* the same times: is 99 divisible by 7 = false (Z14102), 99 is not divisible by 7 (Z13744). Has the orchestrator/compiler figured out that they're fundamentally the same thing? --99of9 (talk) 10:46, 12 March 2024 (UTC)
@99of9: I think they always were the same thing, and you were interpreting random failures (that shouldn't happen ever, of course) as caused by this indirection? Jdforrester (WMF) (talk) 14:53, 12 March 2024 (UTC)
Not so much random failures, but specifically timeouts in the orchestrator. If the orchestration of an indirection takes time, I was seeking to shave off a tiny bit of time to hope that it could get under the timeout limit. --99of9 (talk) 22:14, 14 March 2024 (UTC)
@99of9: Please do file bugs when you run into such issues. They shouldn't be happening for anything that simple. Jdforrester (WMF) (talk) 00:06, 15 March 2024 (UTC)
Ok, I've filed phab:T360172 as a broad sweeping issue. Do you need examples that are more simple? --99of9 (talk) 02:12, 15 March 2024 (UTC)

New research in neural NLG

There’s a lot of it about and it’s not my field, but a new pre-print title caught my eye: Triples-to-isiXhosa (T2X): Addressing the Challenges of Low-Resource Agglutinative Data-to-Text Generation (isiXhosa (Z1723) is Xhosa (Z1723) in Xhosa (Q13218)). I’d like to see Q13218 on Z1723 and I’m hoping that one of the options in Wikifunctions:Representing identity will support this (see phab:T344170 by @Mahir256). GrounderUK (talk) 08:52, 15 March 2024 (UTC)

Wikifunction implementation and test approval

Is there a specific spot to request that implementations and tests go through an approval process by a functioneer? I've crated a function, tests, and an implementation, and just wanted to know if there is any process right now for this?

I know there's Wikifunctions:Approving implementations but that's just an essay and there's not a community consensus around it.

Thanks and I look forward to contributing more to this project. Philipnelson99 (talk) 17:27, 15 March 2024 (UTC)

You’re welcome!
Wikifunctions:Community portal#Tasks listed by users GrounderUK (talk) 17:50, 15 March 2024 (UTC)
I just added it there @GrounderUK! Philipnelson99 (talk) 17:53, 15 March 2024 (UTC)
@GrounderUK can you remove the random character before the return. I can't remove it as I can't edit the implementation now. Philipnelson99 (talk) 18:01, 15 March 2024 (UTC)
Done — GrounderUK (talk) 18:03, 15 March 2024 (UTC)
@GrounderUK One more ask, can you remove the single quotes around the result validation string for this test? Thanks! Philipnelson99 (talk) 18:14, 15 March 2024 (UTC)
Done Better to have added this to the original request. I might have gone away. GrounderUK (talk) 18:36, 15 March 2024 (UTC)
I think we need different rule for newly created functions and adding implementations to already existed functions. Also many processes will usually reach consensus after 7 days, so we don't need 14 days.--GZWDer (talk) 18:47, 15 March 2024 (UTC)
Note we don't require consensus to edit most templates or modules (even including breaking changes), unless they are high-risk. So we should introduce "high-risk function" here. However there are no current way to check how a function is used.--GZWDer (talk) 18:50, 15 March 2024 (UTC)
I am new but the idea of a deeming a function "high-risk" does seem like it would make the barrier for entry lower for newcomers as far as creating functions, implementations, and tests. Philipnelson99 (talk) 18:54, 15 March 2024 (UTC)
Yeah, I don’t think anyone is planning on putting that policy into effect. Let’s put any comments on it in its talk page in case we need to tighten up on our practices later. Admins who grant Functioneer requests might like to chime in with how they decide whether to grant a request. GrounderUK (talk) 18:55, 15 March 2024 (UTC)

Best practices

Best practices are about how Wikifunctions contributors can best help Wikifunctions evolve.

We currently have four topics for consideration on Wikifunctions talk:Best practices:

Feel free to add more or contribute to those that are already there. GrounderUK (talk) 10:25, 16 March 2024 (UTC)

Retrieved from "https://www.wikifunctions.org/w/index.php?title=Wikifunctions:Project_chat/Archive/2024/03&oldid=99453"