Wikifunctions:Project chat/Archive/2024/06
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 #158 is out: New Type: Sign
There is a new update for Abstract Wikipedia and Wikifunctions. Please, come and read it!
In this issue, we introduce a new enumeration type, Sign, and we take a look at the latest software developments.
We are also looking for feedback for our next new types. See the announcement at the Project Chat for more information.
Want to catch up with the previous updates? Check our archive!
Enjoy the reading! -- User:Sannita (WMF) (talk) 11:59, 7 June 2024 (UTC)
- This section was archived on a request by: Sannita (WMF) (talk) 11:04, 21 June 2024 (UTC)
Wikifunctions & Abstract Wikipedia Newsletter #159 is out: New Type: Igbo calendar months
There is a new update for Abstract Wikipedia and Wikifunctions. Please, come and read it!
In this issue, we introduce a new enumeration type, this time for the thirteen months of the Igbo calendar, 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:21, 14 June 2024 (UTC)
- This section was archived on a request by: Sannita (WMF) (talk) 11:04, 21 June 2024 (UTC)
Testing two new types
As discussed in today's Volunteers' Corner (recording forthcoming) we will soon be adding two types to Wikifunctions for testing purposes. Both new types will be marked in their labels for now with "do not use". Please do not use them yet. The two types are an enumeration type for signs (positive, neutral, negative, see proposal) and our first complex type, integer numbers, composed of the new sign type and the natural number type (see proposal). We'll keep you updated here about how the tests are proceeding in the following days. If you have questions or comments, please feel free! -- DVrandecic (WMF) (talk) 18:40, 3 June 2024 (UTC)
Wikifunctions & Abstract Wikipedia Newsletter #160 is out: New Type: Integers
There is a new update for Abstract Wikipedia and Wikifunctions. Please, come and read it!
In this issue, we are happy to announce that we introduced another new type, integers, that will increase our coverage of mathematical functions. Moreover, we take a look at the (many!) software developments we introduced in the last week.
Want to catch up with the previous updates? Check our archive!
Enjoy the reading! -- User:Sannita (WMF) (talk) 11:07, 21 June 2024 (UTC)
- This section was archived on a request by: Sannita (WMF) (talk) 10:09, 12 July 2024 (UTC)
Wikifunctions & Abstract Wikipedia Newsletter #161 is out: Welcome, Daphne!
There is a new update for Abstract Wikipedia and Wikifunctions. Please, come and read it!
In this issue, we welcome a new member of the team, we ask for 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 1, at 17:30 UTC (link to the meeting).
Enjoy the reading! -- User:Sannita (WMF) (talk) 13:20, 27 June 2024 (UTC)
- This section was archived on a request by: Sannita (WMF) (talk) 10:09, 12 July 2024 (UTC)
Presentations about Wikifunctions and Abstract Wikipedia
Hello all! One of our objectives for these months is to create a basic presentation about Wikifunctions and Abstract Wikipedia. Our current draft will be shared in the next weeks, once finalised, and it will likely be improved by your feedback, but right now we want to ask you some questions:
- Have you already had a presentation about Wikifunctions/Abstract Wikipedia? If so, how did it go?
- If not, are you planning to do one in the future? And what kind of help would you need for it, if any?
Feel free to reach out here, or on my talk page, or via email if you wish! And thanks in advance for your help! Sannita (WMF) (talk) 15:41, 13 June 2024 (UTC)
- I gave one to the joint theoretical group meeting of our School of Chemistry. A bunch of programming-savvy educators. Titled "A language-independent programming language". Motivated by the linguistic diversity of our students. Leading through my history of attempts to contribute to poly-lingual education: from Wikipedia to Syllabus Translation to Entity Explosion to Wikifunctions. It wasn't intended to get them to edit, just to introduce them to the idea and provoke discussion really. --99of9 (talk) 04:12, 14 June 2024 (UTC)
Nonexistent validator
The validator of HTML fragment (Z89) points to Validate HTML fragment (Z189) which does not exist ScienceD90 (talk) 12:46, 20 June 2024 (UTC)
- @ScienceD90: Thank you for raising the issue. Filed T368318 on Phabricator. --DVrandecic (WMF) (talk) 20:48, 24 June 2024 (UTC)
- This section was archived on a request by: -- ScienceD90 (talk) 12:49, 14 July 2024 (UTC)
Type validators not working
There are several types whose validators are not returning an error when they should be.
- [do not use] Byte (Z80) accepts anything when it should only accept 2 hexadecimal digits according to m:Abstract Wikipedia/Validation of core types
- [do not use] Code point (Z86) accepts anything for the text field when it should only accept one character
- Natural number (Z13518) just uses the validator of Object (Z1) when it should check that the value is a valid number
ScienceD90 (talk) 13:53, 7 June 2024 (UTC)
- This is because
- For byte, the implementation of Validate byte built-in (Z280) is currently (see code at gitlab:repos/abstract-wiki/wikifunctions/function-orchestrator/-/blob/c1646b8f76919527d97b03374bd712c1d2024d4f/src/builtins.js#L983 set to accept everything
- For code point, the implementation of Validate code point built-in (Z286) also accepts everything (same file as the link above)
- For natural numbers, thats how it was created in Special:Permalink/85109, CC @Jdforrester (WMF)
- Hope this helps --DannyS712 (talk) 07:58, 9 June 2024 (UTC)
- @ScienceD90: yes, that's correct and not great. We need to fix this. This isn't our highest priority right now, but it is up there! Sorry for any inconvenience this is causing. In fact, we would be interested in what kind of inconvenience it is causing! --DVrandecic (WMF) (talk) 22:16, 12 June 2024 (UTC)
- It doesn't really cause any inconvenience, however it is weird seeing badly designed functions, like Simple calculator (Z13934) being able to return natural number "True" when you put in "True" ScienceD90 (talk) 00:42, 13 June 2024 (UTC)
- Ugh, yeah, that's a bad implementation. We shouldn't just pass user input to eval. I disconnected it. Thanks for flagging it. DVrandecic (WMF) (talk) 01:46, 13 June 2024 (UTC)
- In response to this function, I have made a page explaining why eval is bad: Wikifunctions:Eval ScienceD90 (talk) 18:03, 13 June 2024 (UTC)
- @ScienceD90: Thank you! --DVrandecic (WMF) (talk) 21:15, 17 June 2024 (UTC)
- In response to this function, I have made a page explaining why eval is bad: Wikifunctions:Eval ScienceD90 (talk) 18:03, 13 June 2024 (UTC)
- Ugh, yeah, that's a bad implementation. We shouldn't just pass user input to eval. I disconnected it. Thanks for flagging it. DVrandecic (WMF) (talk) 01:46, 13 June 2024 (UTC)
- It doesn't really cause any inconvenience, however it is weird seeing badly designed functions, like Simple calculator (Z13934) being able to return natural number "True" when you put in "True" ScienceD90 (talk) 00:42, 13 June 2024 (UTC)
Overloading types (or not)
Copied from Telegram
User:99of9 I just read this page m:Abstract_Wikipedia/Early function examples and looked up kleenean (en:Three-valued logic), which has a vague correspondence with our new "sign" type (both have three enumerated values). Should we start writing functions representing Kleene and Priest logic using the sign type (and give additional aliases to positive/negative/neutral), or should we wait and make a separate type with values more explicitly enumerated (true, false, unknown/unknowable/undecidable/irrelevant/both)?
- User:DVrandecic (WMF) I would prefer to make a Kleenean type, one not overload Sign with that, unless other people disagree. Just to be able to keep the nomenclature as close as possible to the standard nomenclature.
- User:99of9 I'm comfortable with that. The only advantages of overloading I can think of would be if we were deliberately minimising the number of types, or if a sign output from one function could reasonably be understood as a kleenean input to another.
- User:GrounderUK Hmmm… 🤔 I agree that Kleenean and Sign are probably best kept separate, but I suspect they might be better considered as “systems” over an abstract trivalent type. The standard nomenclatures are then a series of ultra-thin functional wrappers. It may be that such an approach generally allows the similarities and differences to be more clearly seen. (I feel a Project Chat topic coming on.)
- User:99of9 Another question I had is whether True and False would still map to the same ZIDs as the existing ones (I assume not, because they are already typed Boolean). And then I guess we won't be able to map two different True's to the same Wikidata item. So maybe it was good that we kept identity away from Wikidata?
- User:GrounderUK I think Boolean and Kleenean True are the same concept, although its negation is interpreted differently in the different systems. But you are right that, in practice, Kleenean true could not be true (Z41). Both “true” identities could point to the same Wikidata item (by function or by additional key) just as many lexical item senses may have the same item for this sense (P5137) Item.
- User:99of9 I guess I should have written it the other way around: Wikidata can't point from the same Q-item to two different ZIDs.
- User:99of9 I guess we could just make a "Kleenean True" QID, which would include "said to be the same as" the regular "True" QID. Then they could link to their respective ZIDs.
- User:GrounderUK Someone did, kinda 😏 True → Positive (Z17057)
GrounderUK (talk) 19:20, 17 June 2024 (UTC)
Delete this implementation
Hi, I'm a noob in this project. I have created Indian English cardinals,python (Z17100) as an implementation of English cardinal (Z13587). However, the implementation shows some errors for not being consistent with the "million-billion-trillion" system. I thought that English cardinal (Z13587) is applicable for all types of cardinal, but I'm dismayed to find that only short scale is supported here. I'm linking the Z items by analogy of Wikidata's Q and P items. Sbb1413 (talk) 17:53, 20 June 2024 (UTC)
- A function has to give the same result for the same input. When you need a different result, you need a different function. I suggest we create the required function for Indian English before deleting this implementation. We could also create a separate function for the traditional English million-based system but I don’t know whether this system is in current use by any English-speaking community. GrounderUK (talk) 19:58, 20 June 2024 (UTC)
New Type: Day of the week
We just created Day of the week (Z17402) following the Type proposal. Have fun with the Type! --DVrandecic (WMF) (talk) 22:27, 25 June 2024 (UTC)
Rename "Gregorian calendar month" to "Roman calendar month"
Since they can be used for both the Julian and the Gregorian calendar, I think it would make sense to give them a slightly more generic name. It's about this Type: Gregorian calendar month (Z16098). Thoughts? --Denny (talk) 20:50, 22 June 2024 (UTC)
- In English, we could just call it “month” or “calendar month”. I wouldn’t call it “Roman” because “Roman calendar” might equally refer to one of its pre-Julian forms. (Whether the intercalary month should be considered a thirteenth month is an open question, but the intercalary month was a short month and February was always the shortest month. A function to return the number of days in a pre-Julian month would be problematical for February (23 or 24) and for the additional month before March (27 or 28) because scholars disagree.) GrounderUK (talk) 08:36, 23 June 2024 (UTC)
- I have similar concerns to Al. I suggest "Gregorian and Julian month", or if that is too long, some kind of abbreviation expanded in the description. --99of9 (talk) 01:06, 27 June 2024 (UTC)
Proposals for dates and related types
There are now proposals for Gregorian calendar dates, days of the year, years, and eras, a set of Types that are related to each other. Feedback would be very valuable, so that we hopefully get this right! --DVrandecic (WMF) (talk) 20:45, 26 June 2024 (UTC)
Revisiting community "maintainer" rights
@Jdforrester (WMF) at Wikifunctions:Project chat/Archive/2024/03#Criteria for granting "maintainer" rights/editing running functions we were told that the Wikilambda team was not yet ready for community members to be function maintainers. Given the number of recent types created and the fact that things look like they are going smoothly, does that assessment still stand? --DannyS712 (talk) 06:37, 12 June 2024 (UTC)
- @DannyS712: It does. Particularly the user interface for creating types isn't nowhere near ready yet. We are aiming to improve our own speed with creating new types, so that there is less of a backlog for this. Is there anything else that you think is holding back the community besides the right for type creation? --DVrandecic (WMF) (talk) 22:21, 12 June 2024 (UTC)
- @DVrandecic (WMF) as I noted in the prior discussion my primary motivation was the
wikilambda-edit-running-function
right so that as new types are created any existing function that should be the new type can easily be updated. --DannyS712 (talk) 23:30, 12 June 2024 (UTC)- @DannyS712 in order to avoid the "first disconnect, then edit, then connect again" dance? --DVrandecic (WMF) (talk) 23:56, 12 June 2024 (UTC)
- @DVrandecic (WMF) exactly, though I haven't done that dance in a while, as new types are created its more likely to come up --DannyS712 (talk) 01:53, 13 June 2024 (UTC)
- @DannyS712: Thank you for the explanation! Understood. -- DVrandecic (WMF) (talk) 16:48, 13 June 2024 (UTC)
- Now that we have Integer (Z16683) ready for use its come up again - most of the stuff we switched to use natural numbers should probably be switched to use integers --DannyS712 (talk) 04:56, 21 June 2024 (UTC)
- For many of them I'd prefer to have one version natural numbers and another for integers. Otherwise every natural number operation will need to cast in and out of int all the time. 99of9 (talk) 05:03, 21 June 2024 (UTC)
- Sounds reasonable to me :) So9q (talk) 12:30, 15 July 2024 (UTC)
- For many of them I'd prefer to have one version natural numbers and another for integers. Otherwise every natural number operation will need to cast in and out of int all the time. 99of9 (talk) 05:03, 21 June 2024 (UTC)
- Now that we have Integer (Z16683) ready for use its come up again - most of the stuff we switched to use natural numbers should probably be switched to use integers --DannyS712 (talk) 04:56, 21 June 2024 (UTC)
- @DannyS712: Thank you for the explanation! Understood. -- DVrandecic (WMF) (talk) 16:48, 13 June 2024 (UTC)
- @DVrandecic (WMF) exactly, though I haven't done that dance in a while, as new types are created its more likely to come up --DannyS712 (talk) 01:53, 13 June 2024 (UTC)
- @DannyS712 in order to avoid the "first disconnect, then edit, then connect again" dance? --DVrandecic (WMF) (talk) 23:56, 12 June 2024 (UTC)
- @DVrandecic (WMF)
wikilambda-edit-predefined
would help us to better document the inbuilt functions by attaching tests (and removing broken inbuilt tests?). --99of9 (talk) 00:57, 13 June 2024 (UTC)- @99of9: Thank you, good point! For now, I'd be happy to act upon a list, so that it's at least done. --DVrandecic (WMF) (talk) 16:49, 13 June 2024 (UTC)
- @DVrandecic (WMF) as I noted in the prior discussion my primary motivation was the
@DVrandecic (WMF) Here's a list from Wikifunctions_talk:Catalogue tagged with "not done" for any that need updates. Feel free to delete the tag when done. Some will need thought if any unconnected test fails any implementation:
- Unquote (Z899) Not done
- Code point equality (Z888) Not done
- Codepoint list to string (Z886) Not done
- Errortype to type (Z885)
- Typed Map (Z883)
- Typed pair (Z882)
- Typed list (Z881) Not done
- Reduce Function (Z876) Not done
- String to codepoint list (Z868) Not done
- Language code to language (Z860) Not done
- Validate against schema (Z831)
- fetch Persistent object (Z828)
- Get envelope from function call (Z823)
- Get second element of a Typed pair (Z822) Not done
- Get first item of a Typed pair (Z821) Not done
- Trigger metadata (Z820)
- Abstract (Z808) Not done
- Reify (Z805) Not done
- Values by keys (Z804)
- Value by key (Z803) Not done
- Echo (Z801) Not done
--99of9 (talk) 03:42, 14 June 2024 (UTC)
- This is more difficult than I expected! --DVrandecic (WMF) (talk) 21:16, 17 June 2024 (UTC)
- Which difficulties are you encountering most? I find inbuilt functions particularly hard to make tests for because the code is not visible, and the definition is often just a name and some input/output types. But that's also why I want to make more tests available! It looks like you chose Value by key (Z803) to start with, which has some phabricator tasks/bugs, so is perhaps tougher than most. 99of9 (talk) 02:06, 18 June 2024 (UTC)
A freely editable presentation about Wikifunctions & Abstract Wikipedia is available
Hi all! As I already said in my previous message, we have worked in the last weeks to produce a basic presentation about Wikifunctions and Abstract Wikipedia that could be freely reusable and editable by you users, in case you were thinking of holding a presentation about our project(s) but needed some help with it.
I'm happy to announce that the version 1.0 of the slidedeck is now freely available and downloadable! Feel free to download it in the format you like and translate it or modify it to your liking. You can also comment on slides, if you want to give us feedback or you need clarifications.
Also, be aware that most of the slides have speaker notes: we did it to allow people to better understand what was the idea behind the introduction and most of the image-only slides. Notes are also freely reusable, modifiable and translatable, of course.
I wanted to personally thank the team for their feedback and internal evaluation of the slidedeck, as well as users Msz2001, Jens Ohlig and Kristbaum for their incredible and extremely valuable feedback. I hope more will come in the future from you!
Now it is your turn: what do you think of it? Does it look helpful? Also, please remember to upload your presentation to our Commons category!
One last note: unfortunately, since Commons doesn't allow us to upload .odp or .ppt files, we can only host it on Google Docs for the time being. We know this could be a problem for some of you, so if you need a copy of the slidedeck in an open format, please reach out to me via email, and I'll send it to you. Thanks for your patience! Sannita (WMF) (talk) 14:06, 28 June 2024 (UTC)
- Good to see. Slide 5 potentially makes it look like English has got it together and has nothing to benefit from this. I've even heard people suggest that it's easier to all learn English and read en-wp. A picture I use to counter this idea is the map generated by this query. These are politicians with a Wikipedia article written about them in only one language, coloured according to what that language is, and located by their birthplace. It shows the segregation of knowledge into local languages. --99of9 (talk) 05:31, 29 June 2024 (UTC)
- @99of9 Thanks, this is really a good example. I'll think about using it to show the meaning of "unevenly distributed knowledge". Sannita (WMF) (talk) 18:03, 29 June 2024 (UTC)
- Thank you for sharing that 🤩 So9q (talk) 17:40, 18 July 2024 (UTC)