[00:01:02] Yeah, kinda… but not this week? (re @Toby: I've suggested that maybe a third way is possible. An option 2c that is in between 2a and 2b. Because it's non-conforming, those...) [00:01:23] https://tools-static.wmflabs.org/bridgebot/1c66bfce/file_66236.jpg [00:06:40] Are you in support of 2a or 2b (re @Al: Yeah, kinda… but not this week?) [00:06:47] I'm leaning 2a [00:06:50] closer to 2d [00:07:09] i'd put it on like a spectrum [00:07:27] There is a few others https://en.wikipedia.org/wiki/Language_isolate (re @Feeglgeef: isn't it like the only language with no language in the same family?) [00:08:03] 2a——2d—2c—2b [00:08:09] is the spectrum of options here [00:08:26] i'm in between 2a and 2d [00:08:29] both are fine tho [00:08:48] Al [00:22:00] I made some changes to the categorization of the comments on the rational numbers proposal [00:27:16] I’m sticking with 2b this week. You can consider my comment on 2c to be 2e, if you wish. (re @Feeglgeef: Al) [00:27:46] Alright (re @Al: I’m sticking with 2b this week. You can consider my comment on 2c to be 2e, if you wish.) [00:28:09] Toby is your !vote for 2c or 2d? [00:28:29] I'm just making sure I know where everyone stands [00:32:36] Remember that I object to all 11. I'm a slow thinker, sorry. Wiki gives the formal definition "Rational numbers can be formally defined as equivalence classes of pairs of integers (p, q) with q ≠ 0", so now I'm reconsidering the sign issue and wondering whether both the numerator and denominator should be integers!!! (re @Feeglgeef: Toby is your !vote for 2c or 2d?) [00:33:34] Yeah, I’m good with that. (re @Toby: Remember that I object to all 11. I'm a slow thinker, sorry. Wiki gives the formal definition "Rational numbers can be formall...) [00:35:04] (But I also not-so-secretly want to retain the option to return q=0. This allows us to represent Infinity, but also means our functions won't just fail or need special error messages when someone divides by 0) [00:35:17] Yeah (re @Toby: (But I also not-so-secretly want to retain the option to return q=0. This allows us to represent Infinity, but also means our fu...) [00:35:22] I would like this [00:35:36] Specifically Infinity is positive over 0 [00:35:50] - Inf is negative over 0 [00:35:57] (but the equivalence classes reduce to a canonical co-prime representation under simplification) (re @Toby: Remember that I object to all 11. I'm a slow thinker, sorry. Wiki gives the formal definition "Rational numbers can be formall...) [00:36:15] I'd consider myself a fast thinker (re @Toby: Remember that I object to all 11. I'm a slow thinker, sorry. Wiki gives the formal definition "Rational numbers can be formall...) [00:36:19] But my fast thinking [00:36:32] Is almost always not a good solution [00:38:26] I openly object! (re @Toby: (But I also not-so-secretly want to retain the option to return q=0. This allows us to represent Infinity, but also means our fu...) [00:38:29] Agreed. And this goes in both directions, so if anyone wanted an integerp/integerp representation we could give them one, no matter how we represent the sign. Okay, I'm happy to lock in 1a again. (re @Al: (but the equivalence classes reduce to a canonical co-prime representation under simplification)) [00:39:14] I'm still on 1a [00:40:37] Oh, interesting. So what do you want the divide_natural_numbers(1,0) to do: return/error/break? Is that test disconnected? (re @Al: I openly object!) [00:43:39] 1/0 is undefined. I would class it as an error but we should be able to trap errors and branch accordingly. [00:44:20] I would suggest trying to at least complete whole sentences before pressing send! Telegram can get very busy, so it helps to have whole thoughts in each box. (re @Feeglgeef: But my fast thinking) [00:45:02] I don't like (re @Toby: I would suggest trying to at least complete whole sentences before pressing send! Telegram can get very busy, so it helps to hav...) [00:45:04] Doing that [00:45:27] For me it's much easier to get thoughts out this way [00:46:55] When I have to type out full sentences [00:47:38] It makes things harder [00:47:43] To finalize [00:47:58] I guess my opinion is influenced by the fact that we can't trap errors well at this stage, so WF functions feel broken unless they can return a result (even a default) for all inputs. (re @Al: 1/0 is undefined. I would class it as an error but we should be able to trap errors and branch accordingly.) [00:48:36] This is why I am in support of a dropdown type (re @Toby: I guess my opinion is influenced by the fact that we can't trap errors well at this stage, so WF functions feel broken unless th...) [00:48:46] It's exclusively for utility in inputs [00:49:03] In the function creation thing you can give it a typed list of options [00:49:08] And the user has to pick one [00:49:16] I think it will be really useful [00:49:55] It would replace a bunch of types would normally want to make [00:50:10] Ex. Tense, alphabet [00:52:41] We have enumerated types like Day of the Week, which can be selected from a dropdown. But your proposal is to have a type that allows a user to customise what the dropdown options would be. How is that different to a list typed as strings? Maybe your innovation would be to have a UI element which affected something like select_from_list_of_strings. (re @Feeglgeef: This [00:52:41] is why I a [00:52:42] m in support of a dropdown type) [00:53:27] Yes (re @Toby: We have enumerated types like Day of the Week, which can be selected from a dropdown. But your proposal is to have a type that a...) [00:53:43] It's not supposed to be like a data type [00:54:01] It's supposed to be a type for the creation of functions with proper limits [00:54:11] Guiding the user with what to input in a clear way [00:55:03] This may be worth raising as a Phab ticket. I imagine it would take quite some work, but it's worth thinking about. (re @Toby: We have enumerated types like Day of the Week, which can be selected from a dropdown. But your proposal is to have a type that a...) [00:56:59] Part of the function signature would be a link to a Persistent Object which would be a list type of the objects (maybe not always strings actually) available. (re @Feeglgeef: It's supposed to be a type for the creation of functions with proper limits) [00:57:24] Yeah (re @Toby: Part of the function signature would be a link to a Persistent Object which would be a list type of the objects (maybe not alway...) [00:57:27] I like this [01:02:07] Z14084 returns Infinity but should return NaN. (re @Toby: I guess my opinion is influenced by the fact that we can't trap errors well at this stage, so WF functions feel broken unless th...) [01:02:26] Although it may be useful for many functions, it would only work when the list was finite. So would not help us for a function that could only receive primes, or (here for p/q q>0) could only receive non-zeroes. In that case we would need some kind of functional validator of the input rather than a dropdown. (re @Feeglgeef: This is why I am in support of a dropdown [01:02:26] type) [01:03:03] I know (re @Toby: Although it may be useful for many functions, it would only work when the list was finite. So would not help us for a function t...) [01:03:33] The dropdown would just be convenient for the things it's used for [01:04:00] I'm also in support of eventually being able to set a regex as a pattern [01:04:33] So you could use a prime Regex if it requires a prime number [01:09:59] Well, it's more flexible to allow any validator function than always using a Regex. Primes would be a nightmare as a regex!! (re @Feeglgeef: So you could use a prime Regex if it requires a prime number) [01:10:14] No they won't? (re @Toby: Well, it's more flexible to allow any validator function than always using a Regex. Primes would be a nightmare as a regex!!) [01:10:24] Prime Regexs are really easy [01:10:32] ^.?$]^(..+?)\1+$ [01:10:42] Well [01:10:50] This is for composite numbers [01:11:03] But we just have to reverse it [01:12:46] Interesting. According to https://en.wikipedia.org/wiki/Division_by_zero#Computer_arithmetic the answer differs for floating point: "Dividing any non-zero number by positive zero (+0) results in an infinity of the same sign as the dividend." and integer arithmetic: different handling in every different language! (re @Al: Z14084 returns Infinity but should return NaN.) [01:16:17] Yes, I saw a video about this. But it doesn't work on the actual digits, it's about the length of the strings. Anyway, it's still clearly more flexible to use Z12427 as a validator. Regex is thinking too small. (re @Feeglgeef: ^.?$]^(..+?)\1+$) [01:18:48] By whom? (re @Toby: Yes, I saw a video about this. But it doesn't work on the actual digits, it's about the length of the strings. Anyway, it's stil...) [01:19:11] I'd be ok with a composition as valudator (re @Toby: Yes, I saw a video about this. But it doesn't work on the actual digits, it's about the length of the strings. Anyway, it's stil...) [01:19:15] validator* [01:20:51] Numberphile: https://www.youtube.com/watch?v=5vbk0TwkokM (re @Feeglgeef: By whom?) [01:21:43] Yeah (re @Toby: Numberphile: https://www.youtube.com/watch?v=5vbk0TwkokM) [01:22:01] I guess this Regex would be super super slow compared to the other solutions [01:22:14] Actually I think we should drop Regex and just do compositions [01:23:09] We should also drop dropdowns [01:23:17] If we need one we have a validator [01:23:34] I'd also support using hamming distances to find the nearest correct result [01:33:28] I created a phab feature request [01:33:45] It's at T379338 [01:36:34] To be fair, it also sets the divide by zero flag so that the exception can be handled appropriately. (re @Toby: Interesting. According to https://en.wikipedia.org/wiki/Division_by_zero#Computer_arithmetic the answer differs for floating poi...) [02:32:53] https://youtube.com/shorts/OhyezRXm4iE [03:15:16] @vrandecic order I think we should create types in: [03:15:18] 1. Rational number [03:15:19] 2. Float64 [03:15:21] 3. Gregorian date [03:15:22] 4. Bytes [03:15:24] 5. RGB Color [03:15:25] 6. SI units [03:15:27] 7. Moment in time [03:15:28] 8. Kleenean [03:15:30] 9. Gregorian year [03:15:31] 10. Complex128 [03:15:33] 11. Multidimensional array [04:03:39] Is it about inflection? (re @Galder: you don't memorize them, you know them) [04:34:05] Galder can you please color your icons on the catalogue? [04:34:18] I pinged you on wiki [06:33:00] Toby should "triple if" be renamed "double if" [06:33:13] ? [06:33:20] It's a 3 argument if [06:33:30] But there are only 2 ifs [06:38:51] For Z19601 I wonder if the default outcome should be the first element rather than the last? [06:40:54] Oh, nevermind, you've already switched the composition. (re @Toby: For Z19601 I wonder if the default outcome should be the first element rather than the last?) [06:41:16] I mean it doesn't work (re @Toby: Oh, nevermind, you've already switched the composition.) [06:41:25] It shouldn't be that hard to fix but [06:41:28] I'd be fine with either [06:41:31] Honestly [06:43:33] It's passing now but I wouldn't object to you changing it [06:58:47] He might be sleeping (re @Feeglgeef: Galder can you please color your icons on the catalogue?) [07:02:18] He just responded on wiki (re @cvictorovich: He might be sleeping) [07:02:37] Then it’s okay [07:08:10] What’s Kleenean (re @Feeglgeef: @vrandecic order I think we should create types in: [07:08:10] 1. Rational number [07:08:12] 2. Float64 [07:08:13] 3. Gregorian date [07:08:15] 4. Bytes [07:08:16] 5. RGB Color [07:08:18] 6. SI ...) [07:08:43] [[WF:Type proposals]] (re @cvictorovich: What’s Kleenean) [07:09:32] Ternary… [07:09:46] Maybe is still unknown [07:44:48] Yes, apologies -- many larger Lexemes break. We are working on this: T377338 (re @Galder: Working for dog, not for the Basque noun "txakur") [07:47:41] enumerations are locked to the type creation right, others are usually open for every contributor unless exceptionally handled (re @Feeglgeef: @vrandecic how do permissions for newly created types get assigned) [08:24:00] Alright (re @vrandecic: enumerations are locked to the type creation right, others are usually open for every contributor unless exceptionally handled) [08:28:22] Galder it's still a Boolean Algebra symbol [08:28:40] It should be a --> looking arrow [08:28:49] Not ==> [09:59:04] https://tools-static.wmflabs.org/bridgebot/bda2c970/file_66248.jpg [11:08:35] Hello everyone. I saw that there is going to be a backend rewrite in Rust. How can I get involved? I program in Rust. [12:06:39] @arcstur Here was a previous answer to this question. Hope this helps! (re @wmtelegram_bot: Hi, @olivneh! That Phabricator task is the center of the discussion so far, yes. There's no other public discussion so f...) [12:08:35] I was trying to think through how to represent float64, but I didn't get a result that makes me happy: https://www.wikifunctions.org/wiki/Wikifunctions:Type_proposals/float64 [12:19:28] How can they be same?! (re @Galder: ) [12:22:15] just as 1/2 and 2/4 can be the same: under a certain interpretation [12:23:11] Most of all the problems are problems of definition! (re @vrandecic: just as 1/2 and 2/4 can be the same: under a certain interpretation) [12:25:00] Disagreements come from differences in definitions [12:28:49] Interesting, thanks for sharing! [12:28:51] I don't understand some of these and I can think of many more types that I would need more than those, but it's interesting to see what other people think (re @Feeglgeef: @vrandecic order I think we should create types in: [12:28:52] 1. Rational number [12:28:54] 2. Float64 [12:28:55] 3. Gregorian date [12:28:57] 4. Bytes [12:28:58] 5. RGB Color [12:29:00] 6. SI ...) [12:30:17] I think that's just the list of the ones that are already on the [[Wikifunctions:Type proposals]] page, ordered by their priority. I am not sure we will implement all of these, and I am sure that the list is not complete! [12:30:26] Kleenean is about 3 states: yes, no or unknown (re @Nicolas: Interesting, thanks for sharing! [12:30:27] I don't understand some of these and I can think of many more types that I would need more than...) [12:31:04] This name is somewhat obscure [12:31:35] It comes from Kleene algebra (re @cvictorovich: This name is somewhat obscure) [12:32:23] Ternary is a better name [12:32:32] https://en.wikipedia.org/wiki/Stephen_Cole_Kleene [12:32:38] Same pattern as binary (re @cvictorovich: Ternary is a better name) [12:33:33] but we call it the Boolean type, not the Binary type [12:36:13] I'm more curious about the types that I think are missing: nothing about images (jpg, svg, etc.), only RGB (and no other way to represent color), date and moment in time (?) but no time span/duration, etc. [12:38:33] An example on time-related operations: (re @Nicolas: I'm more curious about the types that I think are missing: nothing about images (jpg, svg, etc.), only RGB (and no other way to ...) [12:38:36] https://www.postgresql.org/docs/17/functions-datetime.html [12:38:55] Vide table 9.32 [12:43:07] Is this a good model? [12:49:30] It's certainly a good start (re @cvictorovich: Is this a good model?) [12:55:03] I think you are going in a good direction here. I particularly like the K4 idea to deal with the strange cases. For the rest, as long as a representation has a one-to-one map between it and the programming language floats, then the priority should be about conversion speed. Whichever can be converted in and out the quickest should be used. Unlike for the Wikidata types, [12:55:04] I think i [12:55:04] t will be rare to want to do anything with the component keys on their own (except occasionally K1). (re @vrandecic: I was trying to think through how to represent float64, but I didn't get a result that makes me happy: https://www.wikifunctions...) [14:45:04] Yes, absolutely, we need it. And Chinese, Japanese, Lunar, etc. calendars as well. (re @cvictorovich: We might want data types for Islamic calendar) [14:45:53] Have you seen Wikimedia projects? This kind of cases are everywhere (re @Feeglgeef: No, but I see these as pretty unnecessary) [14:46:01] Actually, per [[WF:BROAD]] I'd advocate for only one type (re @Nicolas: Yes, absolutely, we need it. And Chinese, Japanese, Lunar, etc. calendars as well.) [14:47:25] In principle yes absolutely. Not sure it works here. Dates can be very weird and irrational (re @Feeglgeef: Actually, per [[WF:BROAD]] I'd advocate for only one type) [14:48:00] I don't think it will be that complex (re @Nicolas: In principle yes absolutely. Not sure it works here. Dates can be very weird and irrational) [14:48:13] Maybe I'm wrong but [14:48:26] The type would just be Date and Month [14:51:11] Ok, let's try some "simple" examples : in what year was the shortest/longest between two consecutive Eastern? [14:51:12] or [14:51:14] give an example of events on the same date but not the same day (like Cervantes and Shakespeare) (re @Feeglgeef: I don't think it will be that complex) [14:52:10] Actually we would need year (re @Nicolas: Ok, let's try some "simple" examples : in what year was the shortest/longest between two consecutive Eastern? [14:52:10] or [14:52:12] give an example...) [14:52:28] For the second one it's pretty easy [14:54:44] Wise choice! (re @Nicolas: Yes, absolutely, we need it. And Chinese, Japanese, Lunar, etc. calendars as well.) [14:56:35] It's very different in meaning (re @Galder: ) [14:56:58] One is a Boolean Algebra symbol (that we literally have a function for) and one is an arrow [14:57:32] Otherwise these look really good [14:59:02] I had lots in Latex... I like this, but anyone can change it, for sure! : https://tools-static.wmflabs.org/bridgebot/4b240650/file_66253.jpg [14:59:54] The second one in the second row looks really good [15:01:03] Or the opposite, give an example of events that happened on the same day but not the same date (re @Nicolas: Ok, let's try some "simple" examples : in what year was the shortest/longest between two consecutive Eastern? [15:01:03] or [15:01:04] give an example...) [15:09:10] @vrandecic can I (or you) add a symbol for q for your implementation? [15:09:41] I was planning on using ᵠ [15:10:00] I'll disconnect it and you can add [15:10:23] I have the rights, I just wanted to make sure you were ok with it. [15:10:41] ah, yes, sure go ahead! it's a wiki [15:11:06] I am rather disappointed by the support of superscripts in unicode [15:11:14] Yeah [15:11:36] It was rejected because they didn't find anyone using it [15:20:25] It was rejected mostly because it's formatting not character encoding [15:20:37] Yeah (re @Nicolas: It was rejected mostly because it's formatting not character encoding) [15:20:47] the superscript chars are used as proper chars [15:20:52] not just for formatting [15:21:21] And Unicode couldn't find anyone using superscript q besides people who wanted to format a superscript 1 [15:21:23] q* [15:28:28] They’re Unicode characters (re @Galder: I had lots in Latex... I like this, but anyone can change it, for sure!) [15:29:04] Really likes the fourth in line 4 [16:10:14] which svg and where? I think the svgs are shown in the page language by default, unless the "lang" parameter is used in the wikitext (re @Galder: The svg files are translatable, I have chosen Basque as my language, but the svg are not shown in my language. Is this a bug?) [16:10:42] yes, now with the translation feature they work (re @Nikki: which svg and where? I think the svgs are shown in the page language by default, unless the "lang" parameter is used in the wiki...) [17:14:08] [[Wikifunctions:Type proposals/Calendar date]] [17:18:33] The calendars I have listed that I think we should support are: [17:18:34] Gregorian [17:18:36] Islamic [17:18:37] Chinese [17:18:39] Japanese [17:18:40] Lunar [17:18:42] Juche (possibly) [17:18:59] Those are the only ones I can think of [17:19:50] Hebrew, Hindi, and Persian perhaps? [17:40:27] Juche has been deprecated lately :) (re @Feeglgeef: The calendars I have listed that I think we should support are: [17:40:27] Gregorian [17:40:28] Islamic [17:40:30] Chinese [17:40:31] Japanese [17:40:33] Lunar [17:40:34] Juche (possibly)) [17:41:07] No it hasn't? (re @cvictorovich: Juche has been deprecated lately :)) [17:41:10] I’m only sure that Hebrew and Persian calendar exists (re @Feeglgeef: Hebrew, Hindi, and Persian perhaps?) [17:41:31] Official DPRK announced (re @Feeglgeef: No it hasn't?) [17:42:17] oh yeah [17:43:22] well [17:43:31] they are still working on getting rid of it [17:43:57] [[en:Hindu calendar]] [17:46:53] Don’t forget Thai calendar! [17:48:07] Solar and lunar [17:49:32] We have examples of both [17:50:27] There are too many! [17:50:49] ehh [17:50:52] I only have 9 [17:50:53] [[en:List of calendars]] [17:51:08] we don't need every single used calendar [17:51:40] Do you know about heavenly stems and earthly branches [17:52:15] This is important in traditional Chinese calendars [17:52:36] I was thinking only currently used calendars [17:54:20] 天干地支 [17:54:34] Sure (re @Feeglgeef: I was thinking only currently used calendars) [22:24:21] Toby Nicolas does this look good? (re @Feeglgeef: The calendars I have listed that I think we should support are: [22:24:22] Gregorian [22:24:24] Islamic [22:24:25] Chinese [22:24:27] Japanese [22:24:28] Lunar [22:24:30] Juche (possibly)) [23:02:48] That's the main ones but not the only ones (re @Feeglgeef: The calendars I have listed that I think we should support are: [23:02:49] Gregorian [23:02:51] Islamic [23:02:52] Chinese [23:02:54] Japanese [23:02:55] Lunar [23:02:57] Juche (possibly)) [23:07:56] I'll take a lot of convincing that all of these should be included in the same Type. [23:16:49] "Your proposal involves creating 30+ types, mine involves creating 2" -You, a few days ago (re @Toby: I'll take a lot of convincing that all of these should be included in the same Type.) [23:22:34] Exact quote is "My proposal contains two new types, yours would need 36+." -You, 1:59 UTC, 28 October 2024 [23:23:43] True, but in that case it was possible because _Système international_ is actually systematised. This is trying to merge numerous systems. (re @Feeglgeef: "Your proposal involves creating 30+ types, mine involves creating 2" -You, a few days ago) [23:24:37] Yes but less types = better [23:24:40] see [[WF:BROAD]] [23:25:26] Also these types are pretty similar [23:25:35] They all have months [23:25:41] they all have days of months [23:25:45] they all have years [23:26:12] I think we should use the common denominator to our advantage. [23:26:26] Specifically for function that need to return multiple types. [23:26:47] I am in favor of you being able to select what calendar a function outputs in the selector [23:26:53] kinda like the typed list thing