[00:12:21] When you say, "deteriorates more quickly," do you mean that performance is worse by a constant factor (i.e., linear in the length of the list, but slower for each item on Python than JS) or that there is an exponential performance degradation? (@Al: Thanks for that! I made an implementation with Z876 and I find it curious that performance for longer lists deteriorates more quickly than with the recursive composition ...) [00:13:01] If the former, this makes sense. It's costly to call the evaluator from the orchestrator (making JS or Python slower than a composition) and JS is much faster than Python. If the latter, I'm confused. [00:14:10] During a single function call, we wouldn't switch implementations between different list items. Implementation order is set by the PHP layer and is basically immutable once it reaches the orchestrator, although this would be an interesting thing to consider. [00:48:49] The change may be fairly linear but the gradient is steeper with Python. The test for a 9-element list takes 680 ms with JS and 4269 ms with Python. With a 2-element list, JS takes 416 ms whereas Python takes 1113 ms. The recursive composition is actually quicker with the 9-element list than with a 2-element list. Thinking about it, I guess it doesn’t actually switch to [00:48:50] JavaScr [00:48:51] ipt, it just chooses it up-front for the recursive branch and uses it each time? 🤷‍♂️ (re @wmtelegram_bot: When you say, "deteriorates more quickly," do you mean that performance is worse by a constant factor (i.e., linear in t...) [06:45:27] Thank you! The original imlementation was using Z19243 , which returns a Z810(Z6004), whereas we need a Z11 (which Z19530 returns). Had we paid more attention to the return type, that should have been clear (also, Z19540 was ceated after the corner, if I see that right, by Feeglgeef , thanks!) (re @Toby: I see you also worked on Z19524 @vrandecic . I also fixed [06:45:27] that yesterday, by [06:45:28] turning it inside out, so that the if statements ar...) [13:00:54] Yes, that's right. Once your function call hits the orchestrator, implementation ordering won't change. We should think about improving that, e.g. by somehow marking implementations that show evidence of certain classes of failure and omitting those implementations during the rest of the function call. (@Al: ... it just chooses it up-front for the recursive branch) [14:03:06] Hmmm… one day, perhaps. First we would need some way to tell better from worse in live evaluations and have that influence the initial selection of implementation. Re-visiting that selection during a particular evaluation feels like it might be a solution in search of a problem 🤷‍♂️ (re @wmtelegram_bot: Yes, that's right. Once your function call hits the orches [14:03:06] [14:03:06] trator, implementation ordering won't change. We should think ...) [14:07:39] Absolutely, I wouldn't want to re-order. There are some obvious things we could do, though: for example, if an implementation tries to hit the Python evaluator and the Python evaluator seems to be down, we could avoid trying it for the duration of the call. [14:17:32] That seems valid, but I would still be inclined to fail the call and retry (automatically or by user request). Selection would be as before, but with some types of implementation excluded. That, in turn, would mean we would need to reorder the implementation lists even when the first implementation is the same. (re @wmtelegram_bot: Absolutely, I wouldn't want to [14:17:32] re-order. [14:17:33] There are some obvious things we could do, though: for example, if an implement...) [15:20:59] Is the Volunteer's Corner the first Monday of the month? What is the schedule for it? [15:22:01] yes, correct [15:22:23] Alright, thanks. [15:22:24] And we try to shuffle the time around sometimes, but it is most often during the time it was this week [16:11:31] It is _usually_ the first Monday of the month, but it _could_ be moved one week later sometimes (like in December, because the team will be busy on that particular Monday) (re @Feeglgeef: Is the Volunteer's Corner the first Monday of the month? What is the schedule for it?) [16:12:04] Next one will be in December 9, we'll see if we can move it a little bit earlier to accomodate other people [16:12:27] Ok [16:12:57] I was talking about the time, not the date, to be more precise (re @Sannita: Next one will be on December 9, we'll see if we can move it a little bit earlier to accomodate other people) [16:13:23] It is usually at 17/18.30 UTC, but we'll see if we can schedule it a couple of hours earlier [16:14:44] I'd personally prefer something around 12:30 UTC but any time is fine [18:14:30] I want to get back to having more types being created, and am just reading through the [[Wikifunctions:Type proposals]] -- is there any particular type that folks are waiting particularly impatient for, or shall I just pick and start doing things? [18:14:45] Floats [18:14:48] Probably [18:14:55] Is the most critical of them all [18:15:16] It's natively supported in basically every programming languages [18:15:37] I'd prefer the rational number type to floats but we probably need one of the two [18:15:43] I would love to see a proposal for precise floats, or are you really asking for IEEE floats? [18:15:53] I wouldn't mind having both [18:16:17] Anything for representation of all rational numbers [18:16:29] oh, you're right, rational numbers cover all precise floats! [18:17:05] The rational number type is probably my favorite but the float64 type is probably the easiest and is closer to what is actually represented in JS or python [18:17:10] I'd be fine with either [18:17:17] We just really really need one of them [18:19:18] I hear you! I am partial to the rational number proposal, and aim to implement it early next week, depending on the feedback here or on-wiki [18:20:05] Yeah [18:20:34] The only thing to consider with rational numbers is errors coming from IEEE to fraction conversion [18:21:14] I would think those would be errors in the implementation. We should probably write the code so that it is without errors, if possible. [18:21:21] We'd have to find some way in the type converters to make sure that 0.1 does not turn into 100000001/100000000 or something like that. [18:21:25] Yeah [18:21:59] I think we should *also* have IEEE floating point as a type eventually, and have the respective imprecisions implemented too (which should come for free with JavaScript) [18:22:15] Yeah we should [18:23:36] I'm also obviously biased towards my proposal as a type we should create, but it's probably pretty low on the priority scale [18:24:03] the same for me. Which one's yours? [18:24:04] [[Wikifunctions:Type proposals/SI units]] [18:24:31] For metres, seconds, newtons, etc [18:24:51] yeah, rational numbers or floats first [18:25:42] Mhm [18:26:13] The proposal actually explicitly mentions Rational numbers as a prerequisite [19:02:08] I am generally in disagreement with having 2 types to do the same thing but everyone else seems to be in support of it [19:02:33] I suppose it shouldn't be that bad if we have sufficient converter functions [19:16:18] Yeah, rationals next, please… 100%. We never agreed whether we preferred a signed pair of Natural numbers, though. Thinking about the SI proposal, it occurred to me that we need some way to distinguish true rationals from imprecise approximations. My particular concern was that code implementations would need to signal whether they involved the use of floats (or other [19:16:18] imprecise [19:16:19] representations) so that the returned “rational” might be imprecise. (re @vrandecic: I hear you! I am partial to the rational number proposal, and aim to implement it early next week, depending on the feedback her...) [19:17:30] I think Integer/Natural number is fine [19:18:25] I'm in favor of the type converters doing something to deal with the imperfectness of IEEE [19:19:02] For example if it gets 0.30000000000000004 we can assume 0.3 [19:19:29] I'd also be fine with the type having a precision value for how many decimal digits it has [19:19:43] You could then specify this for your input and output [19:22:22] https://www.wikifunctions.org/wiki/Wikifunctions:Catalogue I have made something to move into subpages the growing list, as now it is too large to navigate. Let me know if you agree, we have a discussion open [19:24:08] Looks good! [19:25:46] 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? [19:27:22] Yes, that sort of thing… but also being clear that no such assumptions have been made, when the representation is precise. (re @Feeglgeef: For example if it gets 0.30000000000000004 we can assume 0.3) [19:29:47] Perhaps we could have a way of differentiating in the function definition? If this isn't reasonably possible I think we should either leave it up to the individual developer to figure out. (re @Al: Yes, that sort of thing… but also being clear that no such assumptions have been made, when the representation is precise.) [19:43:36] I suppose a function can declare itself to be precise but I would expect that to carry through into its return type. Then the problem is that if its arguments are not themselves precise, nor is the evaluation. (re @Feeglgeef: Perhaps we could have a way of differentiating in the function definition? If this isn't reasonably possible I think we should e...) [19:48:23] Yeah [19:49:14] I'm actually now in favor of just making the developer responsible for handling perfection and other things [19:49:47] The type converter should just convert the decimal it gets to fractions, and not provide any extra operations [19:51:27] I was thinking: [19:51:28] m = 1 [19:51:30] while (round(mx)!=mx): [19:51:31] m *= 10 [19:51:33] return x [19:51:46] For intentional imprecision, let's not forget that Wikidata already has a quantity datatype that allows for values with their precision explicitly stated (and units) [19:51:46] return mx* [19:52:21] I would prefer if we considered that in order to stay compatible to supporting Wikidata quantities [19:52:57] Is there like documentation for that? [19:53:12] Yes [19:53:27] Where is that? [19:53:48] https://m.wikidata.org/wiki/Help:Data_type#quantity [19:55:29] I'd be fine with that. [19:55:36] which layout do you prefer? : https://tools-static.wmflabs.org/bridgebot/ee0193a5/file_66191.jpg [19:55:53] Bigger text is ideal [19:56:11] I'd remove the text at the bottom though [19:56:33] I don't know if that's fully accessible, even with alt text (re @Feeglgeef: I'd remove the text at the bottom though) [19:56:38] Also here, but I can't link to the proper section https://m.mediawiki.org/wiki/Wikibase/DataModel [19:56:59] Oh fair (re @Galder: I don't know if that's fully accessible, even with alt text) [20:00:58] Are you thinking of two types: precise rationals and imprecise quantities? (re @vrandecic: For intentional imprecision, let's not forget that Wikidata already has a quantity datatype that allows for values with their pr...) [20:01:28] And IEEE floats [20:01:46] I disagree with this [20:02:20] I personally think there should be one [20:02:26] And I'm fine with 2 [20:02:40] But 3 will make things really difficult [20:14:09] I don’t suppose we can avoid those forever… Maybe just give precise rationals a head start? 😏 I actually think imprecise quantities should be explored along with SI and non-SI units, with IEEE floats being a special case of imprecise quantities 🤷‍♂️ (re @vrandecic: And IEEE floats) [20:17:17] That sounds good to me. It's just the math of floats is different than for numbers with precision [20:27:41] as I'm trying to subcategorize the functions, are these functions of the same kind? or should they have different subpages? Natural number operations [20:27:42] [20:27:43] Integer functions [20:27:45] [20:27:46] Number operations requiring future types [20:28:02] No [20:28:29] One is whole numbers (no decimal), one is (probably) floats and complex numbers [20:28:42] I haven't seen it but it sounds right [20:29:02] I also think the categories don't have to be mutually exclusive, but a function should be able to be in several groups, what do you think? [20:29:10] Yeah [20:29:24] Though most of them currently are by type [20:29:50] But I definitely think if we are doing this by subpages we should have more categories that can overlap [20:29:53] I'm not an onthologist (re @vrandecic: I also think the categories don't have to be mutually exclusive, but a function should be able to be in several groups, what do ...) [20:30:40] Huh? [20:30:59] What connection does onthology have to this? [20:31:24] Anyway [20:31:33] We should have overlapping categories [20:31:35] For sure [20:33:51] I'd be fine with these being separate or being in one "Number" page (re @Galder: as I'm trying to subcategorize the functions, are these functions of the same kind? or should they have different subpages? Natu...) [20:35:26] Yes, but mostly (?) people think they want floats when they really just want decimals… In Wikifunctions, I see IEEE floats as a matter of compatibility, for specialized rather than general use. (re @vrandecic: That sounds good to me. It's just the math of floats is different than for numbers with precision) [20:35:50] I agree (re @Al: Yes, but mostly (?) people think they want floats when they really just want decimals… In Wikifunctions, I see IEEE floats as a ...) [20:36:15] We should definitely have good conversion and Rational Numbers should usually be used [20:36:42] I also support renaming them to something like decimal and having floats be called IEEE Floats [20:36:52] Just to remove bias towards it [20:37:03] And to make it more clear [20:51:16] https://tools-static.wmflabs.org/bridgebot/dd2dd495/file_66192.jpg [20:51:17] https://tools-static.wmflabs.org/bridgebot/4ed59f55/file_66193.jpg [20:51:27] Here's what I would have the keys look like [20:51:43] @vrandecic does this look right? [21:16:40] https://www.wikifunctions.org/wiki/Wikifunctions:Catalogue/Natural_language_operations... eventually there should be 6,000 languages there! [21:17:26] I don't we will ever get there [21:17:46] doubt* [21:17:59] I mean we might [21:18:00] But [21:18:58] We only have 950 Wikilambda languages [21:19:15] I doubt we'll ever be able to have functions for 6,000 [21:44:35] well... imagine a list of 950 languages there! [21:44:52] That would be cool [21:45:12] The thing is [21:45:23] For every function for a relatively obscure language [21:45:34] We need at least one person who knows the language well enough [21:45:59] It's going to be hard to find a total of 950 languages people have enough experience in [21:46:19] But we definitely should have more [21:46:34] I've recently been contributing to Malayalam functions with Athulvis [21:51:24] yes, just "our dream" [21:51:33] I have finished the reordering... https://www.wikifunctions.org/wiki/Wikifunctions:Catalogue [21:52:37] Move the text at the top to the bottom? [21:53:06] Also you can just put [[Wikifunctions:Catalogue]] [21:54:47] And can anyone with translation admin please mark the page for translation? [21:56:53] also, all the svgs are translatable [21:57:06] That's good [21:58:07] but I think that Wikifunctions can't handle that [21:58:17] Oh [22:42:10] That's fine once converted into code, but for compositions which will often branch according to the sign, it's easier to get the sign from it's own key than to dig inside an integer to find it. (re @Feeglgeef: I think Integer/Natural number is fine) [22:42:41] Why not a function to get the sign? [22:43:29] That sounds easier than both other options [22:44:34] There will be such a function. The question is how much work that function has to do: can it just read the key, or does it have to dig into the integer? This function will be called often, so I think it's better to streamline it. [22:45:04] I mean is it that much more difficult to reach for a key twice [22:45:30] It's ZAAAK1.ZRRRK1.ZIIIK1 [22:45:41] Instead of ZAAAK1 [22:45:59] Sorry [22:46:04] Ignore the ZAAA [22:46:07] Are you talking about from code? (re @Feeglgeef: It's ZAAAK1.ZRRRK1.ZIIIK1) [22:46:14] Yes [22:46:15] Or [22:46:23] From a built it in function [22:46:33] Or user defined function [22:46:57] ZRRRK1.ZIIIK1 is not huge [22:47:05] Compared to ZRRRK1 [22:47:17] It also adds another key [22:47:18] Anyway, yes, it doubles the depth for what should be as fast as possible. [22:47:37] But that's like nanoseconds of time [22:48:18] We have *much* better ways to save time if necessary [22:48:38] Having Int/Natural number will make things easier [22:48:45] easier for what? [22:48:51] In general [22:49:04] Easier to read/write [22:49:19] for humans or computers? [22:49:24] Humans [22:49:27] Sorry [22:49:29] Computers [22:49:37] No effect for Humans [22:49:57] The type converters would be much more complex if we have to account for the sign [22:50:19] type converters to or from code? [22:50:29] Both [22:50:58] m = 1 [22:50:58] while (round(mx)!=mx): [22:51:00] m *= 10 [22:51:01] return [mx, 10*m] [22:51:07] Is my plan for from code [22:51:14] We have to double the length [22:51:19] To account for signs [22:51:47] The return statement is an oversimplification [22:51:50] But still [22:51:56] The code is not complex [22:52:35] To make sign independent would just be to move time from something irregularly called to something regularly called [22:52:58] in your pseudocode the mx is a floating point not a rational? [22:53:33] mx is a whole number [22:53:35] It must be [22:53:42] Because of the while loop [22:54:04]