Wikifunctions:Project chat/Archive/2024/07
This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Wikifunctions & Abstract Wikipedia Newsletter #162 is out: Quarterly planning
There is a new update for Abstract Wikipedia and Wikifunctions. Please, come and read it!
In this issue, we present our objectives and lines of work for this quarter, we remember to give your feedback about our "About" widget designs, 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 July 8, at 17:30 UTC (link to the meeting).
Enjoy the reading! -- User:Sannita (WMF) (talk) 12:59, 5 July 2024 (UTC)
- This section was archived on a request by: Sannita (WMF) (talk) 10:09, 12 July 2024 (UTC)
Attach convert [R,G,B] to hex colour, python string formatting (Z18123) to convert [R,G,B] to hex colour (Z17687)
Not a functioneer at this moment in time, so requesting here for someone to attach it as it passes both tests. infernostars (talk) (contribs) 19:03, 21 July 2024 (UTC)
- Done, next time, list it under Wikifunctions:Community portal#Tasks listed by users -- ScienceD90 (talk) 19:10, 21 July 2024 (UTC)
- Thank you! Didn't notice that page, haha infernostars (talk) (contribs) 19:12, 21 July 2024 (UTC)
- This section was archived on a request by: -- ScienceD90 (talk) 19:26, 21 July 2024 (UTC)
ReLU
Hello! Whoever is able to do that, please upcast change the input and output of rectified linear unit (Z13909) to integers. Natural numbers are non-negative, so the function (max(x, 0)
) is equivalent to the identity. --Matěj Suchánek (talk) 10:59, 28 July 2024 (UTC)
- Do you mean change the input and output types? -- ScienceD90 (talk) 11:23, 28 July 2024 (UTC)
- Exactly. (I probably didn't choose the correct word for that.) --Matěj Suchánek (talk) 11:24, 28 July 2024 (UTC)
- Done, next time, list it at Wikifunctions:Community portal#Tasks listed by users -- ScienceD90 (talk) 11:34, 28 July 2024 (UTC)
- Exactly. (I probably didn't choose the correct word for that.) --Matěj Suchánek (talk) 11:24, 28 July 2024 (UTC)
- This section was archived on a request by: -- ScienceD90 (talk) 17:57, 28 July 2024 (UTC)
Volunteers' Corner is postponed by one week
Hi all! Due to a last moment unavailability of most of the team, the Volunteer's Corner will be postponed by one week, same time.
We will meet on July 8, at 17:30 UTC at the same place. Sorry for the disruption! Sannita (WMF) (talk) 16:42, 1 July 2024 (UTC)
Current issues on Wikifunctions
We currently experience a lot of issues running functions on Wikifunctions. We are investigating. The main task in Phabricator to follow our work is T368892. We apologise for the inconvenience. Because of the US holiday and other schedule issues, we do not expect the situation to be resolved quickly, but expect issues to continue at least into next week. We still have not uncovered the root cause of the current problems, which makes predictions of when it will be resolved challenging. Thank you for understanding. --DVrandecic (WMF) (talk) 02:52, 4 July 2024 (UTC)
- Thank you all for your patience! It looks like we diagnosed and found a temporary solution for the issue causing a lot of failed function calls and failed tests lately. For that, we had to temporarily switch off the richer metadata in function calls. We still need to find out the root cause of the issue. We will be working on that, on re-enabling the richer metadata, and on improved production monitoring. You should see an immediate, significant improvement in the stability of Wikifunctions. Please let us know if that isn't what you experience. Thank you for your patience, and your reports, they have been super helpful in diagnosing the issue at hand. --DVrandecic (WMF) (talk) 19:06, 9 July 2024 (UTC)
Wikifunctions & Abstract Wikipedia Newsletter #163 is out: Type proposals for accessing Lexemes
There is a new update for Abstract Wikipedia and Wikifunctions. Please, come and read it!
In this issue, we discuss our current draft about Type proposals for accessing Lexemes, 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) 10:21, 12 July 2024 (UTC)
Typed lists now open beyond Booleans and Strings
Typed lists were not yet fully supporting elements of types other than Booleans and strings. We have extended typed list support to now support all types that we support, which are natural number and integer, sign, Gregorian and Igbo calendar month, and day of the week. In the future, whenever we introduce a new type, typed lists of that type should be automatically available.
Please let us know if you have trouble using typed lists of the newly defined types. --DVrandecic (WMF) (talk) 01:12, 11 July 2024 (UTC)
- This is good news! I’ve not had time to look very closely but it seems to be working well!
- Where do we now stand with lists where the elements have different types? I’m thinking of raising a Feature request to have a Typed list’s element type default to that of the first element rather than Z1. In the user interface, we can set the type to Z1 if we want to add an element of a different type but in a composition we currently have to choose Z1 if the function expects either mixed types or all elements to have the same (as yet unknown) type. We should be able to distinguish between these two cases (at least).
- (A third case is a mix of only specific types. It would be useful to restrict a list to Integers and Natural numbers, for example. Currently, an integer list would not allow a Natural number to be added without explicit conversion. Maybe an “append with conditional conversion to integer” function is called for? But that is just a start…)
- Any thoughts, anyone? GrounderUK (talk) 11:06, 12 July 2024 (UTC)
- Untyped list are currently not supported. We don't have a near-term plan to support them for implementations. The issue is that several Wikifunctions types might be mapped to the same type in a given programming language, so we cannot automatically figure out which type to use for the conversion. When we eventually support it, we will likely introduce a "Wikifunctions object" type for each programming language. --DVrandecic (WMF) (talk) 19:40, 16 July 2024 (UTC)
- I wonder if this is a partial/temporary solution to the mapping problem: Always map to the most general WF type that the programming language type can correspond to. So, for example, if [1,2,3] came out of a python implementation, it would return [integer,1,2,3]. Then any function that runs on untyped lists could at least get a result from the generic implementation. Then when another composition wanted to call that function for a specific typed list, it would just need to map the result to the specific type. So reverse_months(list) = map(reverse_untyped(list),int_to_month). -- 99of9 (talk) 02:07, 17 July 2024 (UTC)
- Untyped list are currently not supported. We don't have a near-term plan to support them for implementations. The issue is that several Wikifunctions types might be mapped to the same type in a given programming language, so we cannot automatically figure out which type to use for the conversion. When we eventually support it, we will likely introduce a "Wikifunctions object" type for each programming language. --DVrandecic (WMF) (talk) 19:40, 16 July 2024 (UTC)
- Huh? I thought an untyped list was already an array of objects in code. Maybe I’ve been dreaming but I’m pretty sure that after evaluation an untyped list is converted into a correctly typed list whenever all its elements have the same type. See Reverse (untyped) list of Natural numbers (Z13725), for example. Anyway, if mixed-type lists are not currently supported, defaulting the list’s type to the type of the first element should be the current behaviour. GrounderUK (talk) 21:55, 16 July 2024 (UTC)
- phab:T370028 We (mainly User:99of9) have now discovered errors from implementations in JavaScript or Python when the function’s return type is Z1/object rather than a Typed list and the implementations return an array of integers or numbers. GrounderUK (talk) 10:19, 15 July 2024 (UTC)
- As above: untyped lists, or even untyped functions are not expected to work for code implementations. --DVrandecic (WMF) (talk) 19:40, 16 July 2024 (UTC)
Void causing an error
On Echo (Z801), passing in void (Z24) causes an error, like on echo test case for void (Z17603). Is this intended behavior or a bug? -- ScienceD90 (talk) 12:46, 14 July 2024 (UTC)
- A bug. -- DVrandecic (WMF) (talk) 19:28, 16 July 2024 (UTC)
Wikifunctions & Abstract Wikipedia Newsletter #164 is out: Research report on integrating Wikifunctions from Wikipedia
There is a new update for Abstract Wikipedia and Wikifunctions. Please, come and read it!
In this issue, we present you the results of a research about how to integrate Wikifunctions and Wikipedia, 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:33, 19 July 2024 (UTC)
Future integration with Wiktionary
@Taylor 49 has asked a question I encourage the community to help answer here:
One day, when inflection of Swedish nouns is migrated to wikifunctions, what will be sent from a wiktionary to wikifunctions, and what comes back?
This is the design part that should be able to handle difficult nouns such as:
irregular ones those with unstable patterns double or triple forms different inflection patterns for different meanings absence of singular or plural absence of indefinite or definite forms.
So9q (talk) 05:57, 22 July 2024 (UTC)
- I think a lexeme should be sent to a function in these kind of cases. If those informations are to be passed to a function, they will be structured one way or another, and the natural way to do this is though a lexeme. If the same functions are to be used across wiktionaries, which would be a win for many wikts, their parameters will be normalized, and the data are better shared in a language independant matter. The structure itself is better unique for a given language and as Wikidata lexeme is a multilanguage project it is made to do this, consistently with wikifunction.
- One interesting follow-up question is then, how to store mapping between lexeme and parts of wiktionary pages, as there are no 1-1 mapping between lexemes and wikt pages. A wiktionary page typically cover several lexemes and several languages. One template or function could take a lexeme as a parameter, but this would be a tedious task. Could we imagine a way to map a page section with a lexeme id, function calls or templates could have access to if they are called inside a section mapped to an ID ? TomT0m (talk) 18:30, 22 July 2024 (UTC)
- I imagine that our end-users will mostly want a single front-end function that "just works", and does a lot of special-casing / language selection, routing requests to more specialist sub-functions curated with a smaller set of inputs and outputs. Jdforrester (WMF) (talk) 21:03, 22 July 2024 (UTC)
- The short version is "it depends on what the Wikifunctions community decides", but I imagine there'd be a few relevant functions depending on what was wanted.
- For example, if we're using an NLG function to create sentence fragments, we'd have something like:
- "A fish swims past." — We'd use
decline(Z1592, Q152, singular, nominative)
which would return"fisk"
, or - "There are three fish." — We'd use
decline(Z1592, Q152, plural, accusative)
which would return"fiskar"
, or - "The eyes of the three fish are open" — We'd use
decline(Z1592, Q152, Z???/plural, Z???/genitive)
which would return"fiskarna"
.
- "A fish swims past." — We'd use
- (Swedish (Z1592) is our Language object for Swedish; Q152 is Wikidata's item for fish; "singular" and "plural" would be Wikifunctions values of a yet-to-be-created "noun countable forms" Type; and "nominative", "accusative", and "genitive" would be Wikifunctions values of "noun grammatical forms" Type.)
- This is of course quite complex for non-experts, so we're going to need to create helpful interfaces to guide users through their use! Jdforrester (WMF) (talk) 21:02, 22 July 2024 (UTC)
- Thanks for sharing this! 😀
- I look very much forward to see this work in practice.
- All the work on the lexemes has yet to bear fruit it seems to me.
- WF and CC0 lexeme data is really a game-changing combo, the world has never seen anything like it.
- Imagine an AI capable of leveraging this system and enable user feedback. It's on the scale of the first GPS system becoming operational IMO. So9q (talk) 06:46, 23 July 2024 (UTC)
- @So9q: We're hoping so! Jdforrester (WMF) (talk) 14:54, 23 July 2024 (UTC)
Testing for errors
Some functions will return errors for some inputs, like a division function when you put 0 in. Is there a way to make a test for this? I know of is void (Z17180), however that does not actually work properly as errors just pass through. -- ScienceD90 (talk) 13:57, 24 July 2024 (UTC)
Welcoming new users
Hi, is there a template with information for new users I can use to greet? If not, what should we tell new users? So9q (talk) 19:30, 28 July 2024 (UTC)
- Yes, there is one:
{{Welcome/lang|user=|welcominguser=|1=~~~~}}
Asked42 (talk) 19:49, 28 July 2024 (UTC)
Wikifunctions & Abstract Wikipedia Newsletter #165 is out: Wikimania 2024 coming soon!
There is a new update for Abstract Wikipedia and Wikifunctions. Please, come and read it!
In this issue, we discuss our upcoming Wikifunctions events at Wikimania 2024, 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:13, 29 July 2024 (UTC)
Can't edit Z20
I can't edit Test case (Z20), even though it looks like I do have the rights for it. See Talk:Z20#Cannot edit. Amir E. Aharoni (talk) 12:30, 30 July 2024 (UTC)
- What were you trying to change the labels to? -- ScienceD90 (talk) 12:38, 30 July 2024 (UTC)
- Z20K1 should be "פונקציה".
- Z20K2 should be "קריאה לפונקציה". Amir E. Aharoni (talk) 12:47, 30 July 2024 (UTC)
- In case it isn't clear, I'm interested not only in fixing this particular spelling, but also understanding why can't I edit it. It looks like a bug. Amir E. Aharoni (talk) 12:48, 30 July 2024 (UTC)
- I wanted to see if I could do it since I am a functioneer. However, I got the same error. -- ScienceD90 (talk) 12:52, 30 July 2024 (UTC)
- I believe that this is T362011, which is a bit of a mystery; probably something is off in production config, as it works as specified in local testing. Jdforrester (WMF) (talk) 10:17, 2 August 2024 (UTC)
Proposal: Functioneer's noticeboard
Most of the task center in the community portal is just for asking to get functions' implementations or test cases attached, or for minor edits functioneers can also do. Would it make sense to then have a Functioneer's noticeboard (in draft right now) for this? infernostars (talk) (contribs) 21:44, 21 July 2024 (UTC)
- I agree with this proposal. One problem with the task center is that tasks can't be archived automatically as it is just a bunch of posts that are not split into any sections. -- ScienceD90 (talk) 22:08, 21 July 2024 (UTC)
- Good plan. I added the "tasks" list to the task centre when I made it to see what would happen, so I'm glad people are using it. Splitting it off seems like the best idea at the moment, since a community portal isn't best for discussions. Cremastra (talk) 18:18, 4 August 2024 (UTC)
- I know this is a bit stale, but I don't think it's necessary, it can just be discussed here or posted on the task center, no point defragmenting the already reasonably inactive project at the moment. Zippybonzo (talk) 21:38, 8 August 2024 (UTC)
Link to Z page: label in interface language or in content language?
A classic wiki-style link to a Z page shows the label of that Z page in the user's interface language.
To me, it would make sense to show it in the page content language by default. This means, for example, that most discussion pages, like this one, would show it in English, and that's OK—whoever can read a discussion in English, can also read the label of a Z page in English.
If a page's content language is set to something other than English, then the link should show the label in that language.
The current practice is similar to the Wikidata practice in the common Q and P templates: they show the label of the Q item or the property in the user interface language. But that is also not a very good practice, and I proposed changing it at d:Template talk:Q. Amir E. Aharoni (talk) 13:09, 30 July 2024 (UTC)
- This makes sense to me. I’ve noticed that there is no “languages” box on our main page, so we’re encouraging users to change their interface language to see content in a different language. In any event, if you get the Main page in a language other than English, viewing the source gives you an English template with no explicit reference to the template that has the content. If you work out the correct template (which isn’t hard), you’ll find that the “function list” appears in the interface language, because it uses Template:Z+ without an explicit language parameter (see, for example, Template:Main page/he). Please note that Template:Z also has an explicit language parameter, without which it functions like a simple wiki-link. Compare:
- join two strings (Z10000) – basic link (standard font for ZID?)
- join two strings (Z10000) – Template:Z (smaller font for ZID?)
- שרשור מחרוזות (Z10000) – Template:Z with second parameter (Is there an rtl issue here?)
- GrounderUK (talk) 08:24, 24 August 2024 (UTC)