[00:26:14] I'm seeing one odd error at Z19713 [00:42:56] @vrandecic when should floats be expected, if we are getting Gregorian year next week [00:49:12] I’m not seeing an error 🤔 (re @Toby: I'm seeing one odd error at Z19713) [00:56:01] Thanks. Now all cleared up for me too. It looked like some network thing ("... Doctypes ...") (re @Al: I’m not seeing an error 🤔) [00:57:40] Z19745? The negative numerator becomes a negative denominator and that isn’t converted, so we end up with a negative Natural number in a positive Rational number? (re @Toby: I'm seeing one odd error at Z19713) [00:59:12] but it's inside javascript, so I'm using the fact that the sign will be switched in the conversion from code (re @Al: Z19745? The negative numerator becomes a negative denominator and that isn’t converted, so we end up with a negative Natural num...) [00:59:41] but no, the error was showing against Z19716 (re @Al: Z19745? The negative numerator becomes a negative denominator and that isn’t converted, so we end up with a negative Natural num...) [00:59:42] Yeah, but it isn’t 😏 (re @Toby: but it's inside javascript, so I'm using the fact that the sign will be switched in the conversion from code) [01:03:30] I already commented at https://www.wikifunctions.org/wiki/Wikifunctions:Type_proposals/Rational_number#JavaScript (re @Toby: but it's inside javascript, so I'm using the fact that the sign will be switched in the conversion from code) [01:04:18] Oh, I see you're right. So line 3 should change from if ( Z19702K1.K1 < 0n ) { to if ( Z19702K1.K1*Z19702K1.K2 < 0n ) { (re @Al: Yeah, but it isn’t 😏) [01:10:02] We’d have to flip the signs too, otherwise we’d still end up with a negative denominator. (re @Toby: Oh, I see you're right. So line 3 should change from if ( Z19702K1.K1 < 0n ) { to if ( Z19702K1.K1*Z19702K1.K2 < 0n ) { but sin...) [01:13:03] Ouch, that would corrupt it badly, because the denominator has N type. (re @Al: We’d have to flip the signs too, otherwise we’d still end up with a negative denominator.) [01:13:48] K2 shouldn't be negative (re @Toby: Oh, I see you're right. So line 3 should change from if ( Z19702K1.K1 < 0n ) { to if ( Z19702K1.K1*Z19702K1.K2 < 0n ) { but sin...) [01:17:16] But functions like Z19745 can cause it, so the type converter should be able to handle it. (re @Feeglgeef: K2 shouldn't be negative) [01:19:43] Then I think we should make Z19745 not cause it (re @Toby: But functions like Z19745 can cause it, so the type converter should be able to handle it.) [01:21:10] something like { [01:21:10] K1: K2*sign(K1), [01:21:12] K2: abs(K1) [01:21:13] } [01:22:11] It will happen again without us noticing (that one was done deliberately), so even if we alter this, I think we should sanitize it in the conversion from code (just as we do other unsimplified fractions). (re @Feeglgeef: Then I think we should make Z19745 not cause it) [01:22:58] We should be throwing an error to make this easy to notice (re @Toby: It will happen again without us noticing (that one was done deliberately), so even if we alter this, I think we should sanitize ...) [01:24:21] I think we are also assuming too much if we do this [01:24:22] why take a different approach to all other unsimplified fractions? Recall that the definition of a rational number is an equivalence class of pairs of *integers* with the same ratio. (re @Feeglgeef: We should be throwing an error to make this easy to notice) [01:25:10] I think it’s just an oversight. We did change the conversion at the last minute. I only spotted it when I updated the proposal and I’ve raised it as a query there. [01:26:11] If, for example, we assume K1=-1 K2=-2 means 1/2, it will be much more annoying to the implementation author to figure out what is going on if they expect -1/2 (re @Feeglgeef: I think we are also assuming too much if we do this) [01:27:44] Well, it does… so they shouldn’t be expecting it not too! (re @Feeglgeef: If, for example, we assume K1=-1 K2=-2 means 1/2, it will be much more annoying to the implementation author to figure out what ...) [01:29:08] This would put too much stress on the type converters, which should be simple [01:34:07] Feel free to reply to my comment on the Type proposal. (re @Feeglgeef: This would put too much stress on the type converters, which should be simple) [01:38:36] I'm more worried about running gcd on both the way in and the way out of javascript. It can be much more computationally expensive than the fix here. (re @Feeglgeef: This would put too much stress on the type converters, which should be simple) [01:46:54] We don’t need it… but it’s the same as Python (at some level) and JavaScript is still quicker in practice 🤷‍♂️ (re @Toby: I'm more worried about running gcd on both the way in and the way out of javascript. It can be much more computationally expensi...) [01:48:23] "quicker in practice" assumes that the time spent in code conversion is counted in the metrics we see? (re @Al: We don’t need it… but it’s the same as Python (at some level) and JavaScript is still quicker in practice 🤷‍♂️) [01:50:06] It does. And I’m pretty sure it is. (re @Toby: Yes, fair point that Python is doing this internally. "quicker in practice" assumes that the time spent in code conversion is co...) [02:31:57] We should have a gender type for Natural Language functions [02:32:39] It should have masculine, feminine, neuter, animate, inanimate [03:02:42] Toby Z19818 is a duplicate of Z19817 [03:12:57] thanks, deleted (re @Feeglgeef: Toby Z19818 is a duplicate of Z19817) [03:16:37] Exposing a bug. Deleted implementations still show up on the testers pages (e.g. at Z19816): : https://tools-static.wmflabs.org/bridgebot/cb8d4d13/file_66451.jpg [03:20:09] That's really weird (re @Toby: Exposing a bug. Deleted implementations still show up on the testers pages (e.g. at Z19816):) [03:20:37] It's giving a Z503, which makes sense [03:21:11] reported as T379873 (re @Toby: Exposing a bug. Deleted implementations still show up on the testers pages (e.g. at Z19816):) [03:22:23] I've commented that a Z503 is thrown [03:23:41] I've manually fixed the issue. You can revert it for your phab task if you want [03:24:35] This seems to be a greater problem that I think I have ran into before where the Implementation menu in the test page handles displaying connected implementations differently [03:30:30] Z19821 and Z19823 behave differently in our implementation of Z19814. We need to explicitly catch the midpoints and decide whether they round up, down, or toward zero. Which way do y'all think we should go. [03:32:49] Up, is more common [03:33:17] Up or towards 0 is fine [03:33:46] away from* [03:37:30] Oh, apparently python round is supposed to choose the nearest even number. So this behaviour was deterministic? Maybe we should match it. https://ioflood.com/blog/python-round/ (re @Toby: Z19821 and Z19823 behave differently in our implementation of Z19814. We need to explicitly catch the midpoints and decide wheth...) [03:38:26] We should do commercial rounding (re @Toby: Oh, apparently python round is supposed to choose the nearest even number. So this behaviour was deterministic? Maybe we should...) [04:23:02] I've created Z19827 as a possible renderer for the Rational number type. It has 2 tests, but probably need more. [04:24:14] We deployed a couple patches today (Wednesday) that, as far as I can tell "nearly" fix that problem. It does not reproduce for any of the previously mentioned error-cases. However, it will still reproduce for a truly monstrous lexeme (very many forms) such as L275483. We have another idea to try, soon, that may help with those monstrous cases. Apologies for slowness on [04:24:15] this, [04:24:15] and thanks everyone for your patience! (re @cvictorovich: Oh my gosh T377338 haven’t been solved yet) [04:25:05] Okay I might check out (re @David: We deployed a couple patches today (Wednesday) that, as far as I can tell "nearly" fix that problem. It does not reproduce for a...) [04:29:23] Seems no (re @cvictorovich: @vrandecic Tested with L20643 but P5186 didn’t return) [04:29:30] Re: Merge Request 249, the code is done but we decided not to deploy it yet because of concern that it might cause more occurrences of T377338 (gateway timeout). With the fixes for T377338 mentioned above, we may be able to deploy !249 soon. Again, thanks for your patience! (re @cvictorovich: Ah, finally there’re some updates on my request) [04:30:39] Well... [05:12:47] that list is oversimplified. it doesn't even include "common" (and more genders exist in some non-indo-european languages), gender and animacy can vary independently, some words can have more than one gender, some words can have an unknown gender (re @Feeglgeef: It should have masculine, feminine, neuter, animate, inanimate) [06:34:09] It might take months? (re @David: Re: Merge Request 249, the code is done but we decided not to deploy it yet because of concern that it might cause more occurren...) [07:04:09] It looks excellent to me. I made one small (possibly controversial) tweak, to change the hyphen - to an actual minus − sign. Obviously we should accept both in the parser. (re @Feeglgeef: I've created Z19827 as a possible renderer for the Rational number type. It has 2 tests, but probably need more.) [07:27:06] I've also made a speedier composition based on your same structure but calling a dedicated underlying JS function. (re @Toby: It looks excellent to me. I made one small (possibly controversial) tweak, to change the hyphen - to an actual minus − sign. Obv...) [07:45:39] Here's a framework for the rational number parser: Z19866. Lots of tests but no implementations yet. [08:12:13] (community head) for rounding, I would hope we would have several rounding functions (round to even, round up, round down, round to zero, round away from zero) [08:14:32] I would think in a few weeks. The proposal is still fluid, has three suggestions, and I don't yet see consensus on it. I have a favorite (which you can probably tell), but that was added quite late. For now, I want to focus on a few fate-related types, and then get back to float. Also to learn a few experiences from rational number, and how we use it. But again, I [08:14:32] am talking week [08:14:33] s, not months. I hope that sounds good! (re @Feeglgeef: @vrandecic when should floats be expected, if we are getting Gregorian year next week) [08:15:38] I love this approach of gathering consensus! (re @Toby: Here's a framework for the rational number parser: Z19866. Lots of tests but no implementations yet.) [08:17:16] (community head) What I was thinking, should we also allow for integers and decimals in the parser? Why not have -0.8 or 4? (although the period is tricky) Mind if I add a few tests for that and then we can see if we have consensus on adding those? [08:17:44] (and I wanted to write _community "hat"_, not head, but hey) [08:20:02] I think the ambiguity is entirely appropriate! 👑 (re @vrandecic: (and I wanted to write community "hat", not head, but hey)) [08:21:37] I was thinking the same. It is written into the proposal… Please be bold! (re @vrandecic: (community head) What I was thinking, should we also allow for integers and decimals in the parser? Why not have -0.8 or 4? (alt...) [08:38:42] won't that make compatibility with other things a pain? anyone who wants to display a number should really be using something to format it according to the user's locale (re @Toby: It looks excellent to me. I made one small (possibly controversial) tweak, to change the hyphen - to an actual minus − sign. Obv...) [08:45:18] (although I don't understand what that is for, and I find the name confusing) [08:45:35] I definitely want those. I already have "0" (re @vrandecic: (community head) What I was thinking, should we also allow for integers and decimals in the parser? Why not have -0.8 or 4? (alt...) [08:50:12] OK, I added a few... (whistling innocently) [08:52:12] Sorry, it's a bit niche. It's a function which will take the result of a computation with a rational number output type, and will convert ("render") the returned object to a string which is displayed to the user viewing on the wikifunctions website. Yes, accessibility matters. Yes, it can be split according to the users language (as we just did with the natural number [08:52:12] renderer). [08:52:12] But this is the first pass, so read it as the default language proposal. (re @Nikki: (although I don't understand what that is for, and I find the name confusing)) [08:55:09] I updated the JS converter to be able to deal with negative denominators [08:55:19] https://www.wikifunctions.org/wiki/Z19702?uselang=en&diff=prev&oldid=137906 [08:56:07] That shouldn't require any changes in the existing implementations (but might allow for some of them to become simpler) [09:02:12] We changed the names to read… and display… Unfortunately the original Rational number proposal pre-dates that change and we never updated the relevant sections. (re @Toby: Sorry, it's a bit niche. It's a function which will take the result of a computation with a rational number output type, and wil...) [10:15:37] I’d really like to allow mixed numbers like “1 2/3” but that’s a terrible representation in plain text, especially if spaces are used for grouping in large numbers. 1+2/3 might be preferable but then the negative looks a bit odd without parentheses: [10:15:37] –(1+2/3)? Open question… (re @vrandecic: (community head) What I was thinking, should we also allow for integers and decimals in the parser? Why not have -0.8 or 4? (alt...) [10:18:03] I'd just go with a space now, seems the most natural. I guess the answer would be not to use spaces for grouping here, or in case of more than one space assume it's meant for grouping and not for separating the integer from the fraction [10:24:49] I guess that would be consistent with dot and comma confusion… (but that doesn’t mean I like it) 😏 (re @vrandecic: I'd just go with a space now, seems the most natural. I guess the answer would be not to use spaces for grouping here, or in cas...) [11:08:22] Agreed [13:38:12] I disagree (re @vrandecic: (community head) What I was thinking, should we also allow for integers and decimals in the parser? Why not have -0.8 or 4? (alt...) [13:54:52] I've made a first attempt at a parser implementation, Z19889. It needs improvements, but it does work for positive numbers with no parenthesis [14:01:11] Could you put your objection(s) here, please? https://www.wikifunctions.org/wiki/Talk:Z19866 (re @Feeglgeef: I disagree) [20:06:54] No, because of the performance improvements resulting from yesterday's deployment, we expect to deploy MR 249 next Wednesday. (The concern was that adding a lot more statements inside of lexemes would cause more timeout errors, but the performance improvements have allayed that concern.) (re @cvictorovich: It might take months?) [21:33:52] Z19889 currently passes all the tests I want it to [21:42:21] It can currently handle: [21:42:21] Simplified or unsimplified numbers [21:42:22] Proper or improper fractions [21:42:24] Positive or negatives (or zero) in numerator [21:42:25] Positive in the denominator [21:42:27] Integers or fractions [21:42:28] Support should be considered for: [21:42:30] Decimals [21:42:31] Mixed numbers [21:42:33] Negatives in the denominator [21:46:25] I disagree with [21:46:25] A, because if decimals should be inputted into a function, it should use floats [21:46:27] B, not too opposed, but would be complicated to implement and likely confusing for users [21:46:28] C, because this parser is user facing, and users should generally not have negatives at the bottom anyway [21:59:24] It’s a good start. Thank you. We should consider percentages too. (re @Feeglgeef: Z19889 currently passes all the tests I want it to) [22:00:09] Yea (re @Al: It’s a good start. Thank you. We should consider percentages too.) [22:20:29] Al GrounderUK I disagree with 86,42% becoming 4321/5000 [22:21:09] This function inherently doesn't simplify so simplifying with percents is not a good idea [22:30:54] It doesn’t need to simplify, the values are equivalent in Z19686, so the result validation should succeed even if the representation is 8642/10000. (re @Feeglgeef: This function inherently doesn't simplify so simplifying with percents is not a good idea) [22:31:47] I know, it should just be clearer what should actually be returned. (re @Al: It doesn’t need to simplify, the values are equivalent in Z19686, so the result validation should succeed even if the representa...) [22:36:16] I take your point. But it literally doesn’t matter which representation is returned, so I don’t think there is a “should” in this case. (re @Feeglgeef: I know, it should just be clearer what should actually be returned.) [22:37:43] The test implies that results should be simplified, which they should not (re @Al: I take your point. But it literally doesn’t matter which representation is returned, so I don’t think there is a “should” in t...) [22:39:36] If we have a function, add one to numerator, if the parser sees 20%, 21/100 should be returned, not 2/5. [22:40:02] Hmm… I’m inclined to agree. (re @Feeglgeef: The test implies that results should be simplified, which they should not) [22:41:26] That would be a strange function, but if we do get it, I think this is one of the functions that should be split into "increment unsimplified numerator" and "increment simplified numerator". (re @Feeglgeef: If we have a function, add one to numerator, if the parser sees 20%, 21/100 should be returned, not 2/5.) [22:42:30] I don't actually support the creation of the function, it's just supposed to be an example of a function that would be different depending on simplification, and performs an operation (re @Toby: That would be a strange function, but if we do get it, I think this is one of the functions that should be split into "increment...) [22:42:59] I'm fine with requiring it to render as exactly 8642/10000. We can write a stricter test than Z19686 for special cases like this. (re @Feeglgeef: This function inherently doesn't simplify so simplifying with percents is not a good idea) [22:43:16] It’s not that strange. One often hears of percentage point increases. (Likewise “basis points”.) (re @Toby: That would be a strange function, but if we do get it, I think this is one of the functions that should be split into "increment...) [22:43:34] Yeah, we need this (re @Toby: I'm fine with requiring it to render as exactly 8642/10000. We can write a stricter test than Z19686 for special cases like this...) [22:44:36] Related to this, maybe the parser should use % if the denominator is 100? (re @Al: It’s not that strange. One often hears of percentage point increases. (Likewise “basis points”.)) [22:44:39] We should also still write the "is simplified" function (which cannot have code implementations, but can work in composition). [22:45:28] You mean the renderer? I wouldn't like that. (re @Feeglgeef: Related to this, maybe the parser should use % if the denominator is 100?) [22:45:37] Yes, I am inclined to… with Z18683. (re @Toby: I'm fine with requiring it to render as exactly 8642/10000. We can write a stricter test than Z19686 for special cases like this...) [22:47:54] No, I think it would have to be a wrapper: Rational number as percentage. (re @Toby: You mean the renderer? I wouldn't like that.) [22:49:48] Z18683 with self.simplified? (re @Toby: We should also still write the "is simplified" function (which cannot have code implementations, but can work in composition).) [22:49:48] Back to this. My reasons for supporting these even given your objections are: A) Once we have floats and float functions, users will certainly be able to put decimals into those. This does not prevent that. Schoolkids learn that 0.5 = 1/2 well before they understand true *floating* point. B) Users can't be confused if they never use it. This will only help those who try [22:49:48] to. Comp [22:49:49] licated to implement doesn't mean we shouldn't eventually. C) Rarely used doesn't mean we shouldn't allow it. (re @Feeglgeef: I disagree with [22:49:51] A, because if decimals should be inputted into a function, it should use floats [22:49:52] B, not too opposed, but would be...) [22:51:59] That would be a valid implementation. (re @Al: Z18683 with self.simplified?) [22:53:35] And they can put in 1/2? (re @Toby: Back to this. My reasons for supporting these even given your objections are: A) Once we have floats and float functions, users ...) [22:54:41] Logically, yes… but I’d need to fix Z18683 first because it uses object equality for its value equality 🙄 (re @Toby: That would be a valid implementation.) [22:55:32] It's not that it's rarely used, it's that there isn't really a case where it's inclusion would be helpful and because it's not how the type works (re @Toby: Back to this. My reasons for supporting these even given your objections are: A) Once we have floats and float functions, users ...) [22:55:49] Another composition would just be to call GCD on the keys and check if 1. (re @Al: Z18683 with self.simplified?) [22:57:35] Yes… but we’ll need “same rational number representation” anyway… (re @Toby: Another composition would just be to call GCD on the keys and check if 1. With some special handling of 0.) [22:58:37] Isn't that what we are talking about? Can you lay out where you're going here. (re @Al: Yes… but we’ll need “same rational number representation” anyway…) [22:59:34] Anyway… yes, we should accept decimals. Please comment at https://www.wikifunctions.org/wiki/Talk:Z19866 in due course. (re @Toby: Back to this. My reasons for supporting these even given your objections are: A) Once we have floats and float functions, users ...) [23:03:21] Done. Feeglgeef's reasoning here was more elaborate than on the talk page, so I'll engage that here. (re @Al: Anyway… yes, we should accept decimals. Please comment at https://www.wikifunctions.org/wiki/Talk:Z19866 in due course.) [23:04:10] That will be allowed. The idea is to allow as many types of unambiguous input as possible. (re @Feeglgeef: And they can put in 1/2?) [23:05:38] Yeah, my brain is gearing itself up 😏 We just need and(K2=K2, K3=K3), Boolean from two Qs. Did someone do that already? (re @Toby: Isn't that what we are talking about? Can you lay out where you're going here.) [23:06:25] Unless it was done while I was asleep, I haven't seen it. (re @Al: Yeah, my brain is gearing itself up 😏 We just need and(K2=K2, K3=K3), Boolean from two Qs. Did someone do that already?) [23:07:45] I don't think I created it [23:08:10] Okay, I’ll pick that one up now. (re @Toby: Unless it was done while I was asleep, I haven't seen it.) [23:39:55] Al do you type your edit summaries out yourself or do you have a script? [23:48:32] I have a spreadsheet but I often just type them myself (and sometimes get them wrong) (re @Feeglgeef: Al do you type your edit summaries out yourself or do you have a script?) [23:51:34] Don't you want to check the sign too? Z19897 Or do we need a separate one that checks everything. (re @Al: Okay, I’ll pick that one up now.)