[00:03:09] <wm-bb>	 <Feeglgeef> Do Z19701 and Z19702 look good? I have no way of testing them.
[00:03:52] <wm-bb>	 <Feeglgeef> You should be able to edit
[00:17:36] <wm-bb>	 <Feeglgeef> currently 2d is implemented
[00:39:29] <wm-bb>	 <Toby> It looks like it may not include BigInts. Also I guess that the object labels in the return should not be in English. Also can you expand on what you changed when you said "this is different from what is in the proposal"? (re @Feeglgeef: Do Z19701 and Z19702 look good? I have no way of testing them.)
[00:39:59] <wm-bb>	 <Feeglgeef> I guess they shouldn't be (re @Toby: It looks like it may not include BigInts. Also I guess that the object labels in the return should not be in English. Also can y...)
[00:40:34] <wm-bb>	 <Toby> Why?  That's how we defined natural numbers and integers. To give unlimited precision. (re @Feeglgeef: I guess they shouldn't be)
[00:41:04] <wm-bb>	 <Feeglgeef> Sorry. This is why multiple messages is good. I was talking about "Also I guess that the object labels in the return should not be in English." (re @Toby: Why?  That's how we defined natural numbers and integers. To give unlimited precision.)
[00:43:01] <wm-bb>	 <Feeglgeef> Wait, don't both programming languages used only support English? Wouldn't someone need to know English to create functions in the first place?
[00:43:57] <wm-bb>	 <Feeglgeef> You can make it support BigInts if you want to (re @Toby: It looks like it may not include BigInts. Also I guess that the object labels in the return should not be in English. Also can y...)
[00:56:02] <wm-bb>	 <Toby> If we refer by the ZIDKeyID then it will be unambiguous no matter which interface language you come in from. (re @Feeglgeef: Wait, don't both programming languages used only support English? Wouldn't someone need to know English to create functions in t...)
[01:05:13] <wm-bb>	 <Feeglgeef> Yeah, I've changed it to that (re @Toby: If we refer by the ZIDKeyID then it will be unambiguous no matter which interface language you come in from.)
[04:16:34] <wm-bb>	 <Jan_ainali> Even better would be to use something more precise than "they" when the message replied to have multiple possible targets. (re @Feeglgeef: Sorry. This is why multiple messages is good. I was talking about "Also I guess that the object labels in the return should not ...)
[04:23:30] <wm-bb>	 <Jan_ainali> Not really. When I learned programming in Basic, my English skills were not on the level to understand all error messages. Instead, I used a textbook that had all error messages listed with explanations in Swedish. (re @Feeglgeef: Wait, don't both programming languages used only support English? Wouldn't someone need to know English to create functions in t...)
[04:25:01] <wm-bb>	 <Feeglgeef> It's not like the error messages would be understandable if you did know the language (re @Jan_ainali: Not really. When I learned programming in Basic, my English skills were not on the level to understand all error messages. Inste...)
[04:47:30] <wm-bb>	 <cvictorovich> There are some minor programming languages that aren’t based on English
[04:47:49] <wm-bb>	 <Feeglgeef> I'm talking about ones that WL supports (re @cvictorovich: There are some minor programming languages that aren’t based on English)
[04:48:11] <wm-bb>	 <cvictorovich> Yes, they’re English… (re @Feeglgeef: I'm talking about ones that WL supports)
[04:48:45] <wm-bb>	 <Feeglgeef> Yeah
[06:42:17] <wm-bb>	 <Nikki> wikifunctions is designed to be as multilingual as possible (see https://www.wikifunctions.org/wiki/Wikifunctions:FAQ), people can create implementations using composition without having to understand either of the currently supported programming languages, and more programming languages might be added in the future (re @Feeglgeef: Wait, don't both programming
[06:42:17] <wm-bb>	 languages used only <clipped message>
[06:42:18] <wm-bb>	 <Nikki>  support English? Wouldn't someone need to know English to create functions in t...)
[08:26:58] <wm-bb>	 <cvictorovich> Oh my gosh T377338 haven’t been solved yet
[08:27:44] <wm-bb>	 <cvictorovich> It must be solved before I build some of my functions
[08:31:52] <wm-bb>	 <vrandecic> We are working on it, and several engineers are trying to figure out what is going on there. it is somewhat baffling, and requires us to deploy a new backend in order to gather more information and try out some hypotheses. Some things just turn out more complicated than we hoped.
[08:45:11] <wm-bb>	 <cvictorovich> How long would it take approximately
[08:54:13] <wm-bb>	 <Toby> Can you build them now and test them on lexemes with less than 20 forms? Then when the issue is fixed they should work on all. (re @cvictorovich: It must be solved before I build some of my functions)
[08:57:01] <wm-bb>	 <cvictorovich> One of problems is related to incomplete lexical data
[08:57:37] <wm-bb>	 <cvictorovich> See here (re @cvictorovich: I need P5186 returned and as an intermediate variable for later actions)
[08:57:57] <wm-bb>	 <cvictorovich> It’s not here now
[10:25:48] <wm-bb>	 <Nikki> when I enter l7 in the field for picking a lexeme to test against, it only shows me the id
[10:39:09] <wm-bb>	 <Al> …and if you enter “cat” it doesn’t show the id… but either way, when selected it ends up displaying as “cat”, yes? (I’d prefer something like “L7: cat (English, noun)” in all contexts.) (re @Nikki: when I enter l7 in the field for picking a lexeme to test against, it only shows me the id)
[10:40:53] <wm-bb>	 <Al> [Thank you, wikilinksbot, that’s nice too] (re @wikilinksbot: L7 – cat [en: English])
[10:40:57] <wm-bb>	 <Toby> Same here, on Z6825 I get : https://tools-static.wmflabs.org/bridgebot/4bfabdb7/file_66425.jpg
[10:43:44] <wm-bb>	 <cvictorovich> Incomplete data are returned
[11:04:08] <wm-bb>	 <Al> I can’t see why we get “brusić”… there are lots of other lexemes with IDs beginning L7 🤷‍♂️
[11:51:54] <wm-bb>	 <vrandecic> filed T379740
[11:58:07] <wm-bb>	 <vrandecic> There's no renderer or parser yet, but I wanted to invite adventurous folks to play with the new Rational number type: https://www.wikifunctions.org/view/en/Z19677
[12:04:31] <wm-bb>	 <Toby> Hi Denny, I'm a bit confused about where GCD is going in the JavaScript for Rational Numbers. I was hoping the plan was to not have to call gcd from every function like is currently done in Z19704. I thought it was going to happen automatically in Z19702 so that every returning function will be normalised. But then I do see it in Z19701 which seems to unnecessarily
[12:04:31] <wm-bb>	 protect the <clipped message>
[12:04:31] <wm-bb>	 <Toby>  code receiving unsimplified ratios (unnecessary because their mechanics will work anyway, so it wastes time on the way in).
[12:05:49] <wm-bb>	 <vrandecic> good point let's add it to Z19702 too, then we can drop it from 19704!
[12:09:45] <wm-bb>	 <vrandecic> done
[12:10:07] <wm-bb>	 <Toby> In case we all start duplicating stuff, here's a category section: https://www.wikifunctions.org/wiki/Wikifunctions:Catalogue/Number_operations#Rational_number_functions
[12:19:41] <wm-bb>	 <Feeglgeef> Toby I think you created a duplicate of Negate rational number
[12:19:56] <wm-bb>	 <Feeglgeef> Unless you mean flip numerator and denominator
[12:20:45] <wm-bb>	 <Feeglgeef> Nevermind!
[12:22:14] <wm-bb>	 <Toby> yes, that's what invert means (re @Feeglgeef: Unless you mean flip numerator and denominator)
[12:23:01] <wm-bb>	 <Feeglgeef> Ok :)
[12:38:14] <wm-bb>	 <Feeglgeef> This different in JS vs Python thing is actually really useful
[12:38:39] <wm-bb>	 <Feeglgeef> At first I thought it would not work well, but I really like this.
[12:40:11] <wm-bb>	 <vrandecic> huh, wait, it shouldn't be different? I probably misunderstand
[12:51:11] <wm-bb>	 <Al> Sorry, I’m a bit busy but can we just think about our terminology for Natural numbers and Integers represented as Rational numbers? I hesitate to use the word “convert” in this context, even though type conversion is exactly what it is. So, yeah, to turn an integer representation into an equivalent rational number representation might be “represent Integer as Rational
[12:51:11] <wm-bb>	 number”?
[12:52:15] <wm-bb>	 <Feeglgeef> Python is fraction.Fraction by default (re @vrandecic: huh, wait, it shouldn't be different? I probably misunderstand)
[12:52:29] <wm-bb>	 <Feeglgeef> JavaScript is, well, JavaScript
[12:53:39] <wm-bb>	 <vrandecic> one option to avoid this is by simply saying "Integer as Rational number" etc. and drop the verb (re @Al: Sorry, I’m a bit busy but can we just think about our terminology for Natural numbers and Integers represented as Rational numbe...)
[12:54:03] <wm-bb>	 <vrandecic> aah, gotcha, yes! (re @Feeglgeef: Python is fraction.Fraction by default)
[12:57:25] <wm-bb>	 <Al> Yes, that’s a good option. It reads better for type conversions more generally too. (re @vrandecic: one option to avoid this is by simply saying "Integer as Rational number" etc. and drop the verb)
[13:01:42] <wm-bb>	 <Al> (`Z17101 would be “Natural number as Integer”, for example`…”)
[13:04:52] <wm-bb>	 <Feeglgeef> Should Z19744 be changed to this? (re @vrandecic: one option to avoid this is by simply saying "Integer as Rational number" etc. and drop the verb)
[13:11:27] <wm-bb>	 <Al> Hah, you were literally doing it while we were discussing it… Avoiding “convert” is my priority, but Denny’s suggestion is a good solution as far as I’m concerned. 😎 (re @Feeglgeef: Should Z19744 be changed to this?)
[13:12:22] <wm-bb>	 <Feeglgeef> Alright (re @Al: Hah, you were literally doing it while we were discussing it… Avoiding “convert” is my priority, but Denny’s suggestion is a goo...)
[13:16:18] <wm-bb>	 <Toby> It seems JS will usually be harder to write for rationals, but Z19745 has some elegance even though Z19714 looks simpler. (re @Feeglgeef: This different in JS vs Python thing is actually really useful)
[13:17:20] <wm-bb>	 <Toby> It's working really well as far as I can tell Denny. Thanks for your work. I'm off to bed now. I look forward to seeing what is developed overnight! (re @vrandecic: There's no renderer or parser yet, but I wanted to invite adventurous folks to play with the new Rational number type: https://w...)
[13:17:46] <wm-bb>	 <Feeglgeef> Yeah, definitely (re @Toby: It's working really well as far as I can tell Denny. Thanks for your work. I'm off to bed now. I look forward to seeing what is ...)
[14:25:16] <wm-bb>	 <Al> Is this preferable for JavaScript addition? (I think that’s how we used to do it in school, years ago!) 😏 (re @vrandecic: good point let's add it to Z19702 too, then we can drop it from 19704!)
[14:25:22] <wm-bb>	 <Al> Z19755
[14:31:44] <wm-bb>	 <Al> Actually, I think we need to multiply the numerator by the sign… or something 🙄 (re @Al: Is this preferable for JavaScript addition? (I think that’s how we used to do it in school, years ago!) 😏 Z19755)
[14:45:07] <wm-bb>	 <Al> (I told you I was busy… 🙄) Wouldn’t it make more sense to convert to JS with numerator as a signed integer? (re @vrandecic: good point let's add it to Z19702 too, then we can drop it from 19704!)
[14:47:08] <wm-bb>	 <vrandecic> while we still don't have many functions, that is a change we can make if we have agreement here
[14:47:25] <wm-bb>	 <vrandecic> ... while we still don't have many javascript implementations for these functions ...
[14:52:34] <wm-bb>	 <Feeglgeef> {{s}} (re @vrandecic: while we still don't have many functions, that is a change we can make if we have agreement here)
[14:53:24] <wm-bb>	 <Feeglgeef> It's giving -5/6 for 1/2-1/3 (re @Al: Is this preferable for JavaScript addition? (I think that’s how we used to do it in school, years ago!) 😏 Z19755)
[14:53:32] <wm-bb>	 <Feeglgeef> So not working
[14:53:36] <wm-bb>	 <Al> It’s more consistent with Python (and my mental blackboard) (re @vrandecic: while we still don't have many functions, that is a change we can make if we have agreement here)
[14:54:00] <wm-bb>	 <Al> That’s what I thought 😏 (re @Feeglgeef: So not working)
[14:58:50] <wm-bb>	 <Feeglgeef> If Toby is fine with it we should do it
[15:11:23] <wm-bb>	 <Feeglgeef> Imo Rational numbers should have a simple parser for inputting them faster
[15:11:30] <wm-bb>	 <Feeglgeef> Right now it's really inconvenient
[15:38:18] <wm-bb>	 <Feeglgeef> Specifically, I see Python used more for interacting with the data inside the functions, and JS more used for things related to the function model (re @Feeglgeef: This different in JS vs Python thing is actually really useful)
[15:42:46] <wm-bb>	 <cvictorovich> Ah, finally there’re some updates on my request
[15:45:18] <wm-bb>	 <cvictorovich> !249
[15:45:54] <wm-bb>	 <Winston_Sung> https://tools-static.wmflabs.org/bridgebot/ddddb792/file_66435.webp
[15:46:08] <wm-bb>	 <Winston_Sung> [ which repository ] (re @cvictorovich: !249)
[15:47:22] <wm-bb>	 <cvictorovich> https://gitlab.wikimedia.org/repos/abstract-wiki/wikifunctions/function-orchestrator/-/merge_requests/249
[15:48:40] <wm-bb>	 <cvictorovich> Need it very very much
[16:28:48] <wm-bb>	 <vrandecic> We currently have 8 JS implementations for functions using rational numbers. My understanding is that Toby is out for the day. If we want, we can make the change now for a little cost or tomorrow for higher cost, but there's a risk of people pushing back if we do it now. I am happy one way or the other.
[17:03:58] <wm-bb>	 <Al> For the JavaScript conversion to code, I think the proposal is as in https://www.wikifunctions.org/w/index.php?title=Wikifunctions:Type_proposals/Rational_number&oldid=136505. Toby commented on that to the effect that JS simplification could be in conversion from code (as we now have). I don’t see anything that looks like an objection to the {Integer, Natural number}
[17:03:58] <wm-bb>	 object the <clipped message>
[17:03:58] <wm-bb>	 <Al> n proposed. He hasn’t commented since the conversion proposal was changed, as far as I can see. (Toby) (re @vrandecic: We currently have 8 JS implementations for functions using rational numbers. My understanding is that Toby is out for the day. I...)
[17:04:25] <wm-bb>	 <Al> Toby (re @Al: For the JavaScript conversion to code, I think the proposal is as in https://www.wikifunctions.org/w/index.php?title=Wikifunctio...)
[18:39:38] <wm-bb>	 <vrandecic> Newsletter 180:
[18:39:39] <wm-bb>	 <vrandecic> * New type: Rational numbers
[18:39:40] <wm-bb>	 <vrandecic> * Recent Changes in the software
[18:39:42] <wm-bb>	 <vrandecic> * Natural numbers have a renderer and parser again
[18:39:43] <wm-bb>	 <vrandecic> * Documentation on Wikidata-based types
[18:39:45] <wm-bb>	 <vrandecic> * Function of the Week: minimum of a list of natural numbers
[18:39:46] <wm-bb>	 <vrandecic> https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-11-13
[19:37:21] <wm-bb>	 <Toby> This change is okay by me. (re @Al: For the JavaScript conversion to code, I think the proposal is as in https://www.wikifunctions.org/w/index.php?title=Wikifunctio...)
[19:40:34] <wm-bb>	 <Al> Toby agrees. (re @vrandecic: We currently have 8 JS implementations for functions using rational numbers. My understanding is that Toby is out for the day. I...)
[21:05:33] <wm-bb>	 <vrandecic> OK, switched the JS internal representation (please, can someone update the type proposal? It is late here. And fix all implementations 🙂 )
[21:14:58] <wm-bb>	 <vrandecic> And I am off for the day! See y'all!
[21:46:27] <wm-bb>	 <Feeglgeef> I've done them (re @vrandecic: OK, switched the JS internal representation (please, can someone update the type proposal? It is late here. And fix all implemen...)
[21:55:31] <wm-bb>	 <Feeglgeef> Z19704 and Z19755 are duplicates
[21:56:12] <wm-bb>	 <Feeglgeef> Al GrounderUK
[21:57:42] <wm-bb>	 <Al> Ah, I suppose they would be now… we can delete mine, if you like 😎 (re @Feeglgeef: Z19704 and Z19755 are duplicates)
[21:58:14] <wm-bb>	 <Feeglgeef> I'll request deletion (re @Al: Ah, I suppose they would be now… we can delete mine, if you like 😎)