[01:48:56] I think the orchestrator does that (re @Al: I don’t think you can test a recursive composition when others are connected, because the php selects the current first implemen...) [01:49:01] But yeah [01:56:00] I’m recalling this, Feeglgeef (re @wmtelegram_bot: During a single function call, we wouldn't switch implementations between different list items. Implementation order is ...) [01:57:50] Yeah, those are two different things (re @Al: I’m recalling this, Feeglgeef) [01:58:19] The PHP sends all the options, and the orchestrator picks the first one [02:00:55] Makes sense… but it would still mean that the recursion would use the current first implementation, rather than itself, as I understand it. (re @Feeglgeef: The PHP sends all the options, and the orchestrator picks the first one) [02:01:20] https://gitlab.wikimedia.org/repos/abstract-wiki/wikifunctions/function-orchestrator/-/blob/main/src/execute.js#L812 [02:02:40] Yeah (re @Al: Makes sense… but it would still mean that the recursion would use the current first implementation, rather than itself, as I und...) [02:06:34] Well, from what I can tell it loops through the implementation list, tries to run each one, and goes to the next one only if it gets a non-graceful error (re @Feeglgeef: The PHP sends all the options, and the orchestrator picks the first one) [02:13:57] That’ll be why it hangs occasionally… but ordinarily it succeeds or fails gracefully, and doesn’t try the next implementation. (re @Feeglgeef: Well, from what I can tell it loops through the implementation list, tries to run each one, and goes to the next one only if it ...) [02:14:56] Yeah. Failing non-gracefully ideally shouldn't ever happen. (re @Al: That’ll be why it hangs occasionally… but ordinarily it succeeds or fails gracefully, and doesn’t try the next implementation.) [02:49:09] So far I think you're right. I even made this test to give a huge advantage to laziness: Z22106, but it hasn't flipped anything. (re @Feeglgeef: I tested it and I would be really surprised if it did work, the orchestrator is too eager.) [05:58:43] This also makes the implementation info that is returned in a Z22 more useful as even though it is the first one most of the time there is a possible case where it is not (re @Al: That’ll be why it hangs occasionally… but ordinarily it succeeds or fails gracefully, and doesn’t try the next implementation.) [08:22:37] True, but without nested metadata, we can’t see a change of implementation at the recursion, even in the normal case where the initial implementation is set and that is not the first implementation listed, so the orchestrator switches implementations at the first recursion and (normally) persists with that implementation in subsequent recursions. The (untested) metadata [08:22:37] just gi [08:22:38] ves the initial implementation. (re @Feeglgeef: This also makes the implementation info that is returned in a Z22 more useful as even though it is the first one most of the tim...) [12:58:28] At least it confirms our belief 👍 (re @u99of9: So far I think you're right. I even made this test to give a huge advantage to laziness: Z22106, but it hasn't flipped anything.) [14:23:06] Reminder that the Volunteers Corner is at 18:30 UTC today [14:24:22] https://meet.google.com/xuy-njxh-rkw [14:27:20] Thanks, I lost the track of time again, and forgot to put a reminder [17:46:41] We created the Kleenean type -- if anyone wants to check it out and see if it works well. I will remove the (TESTING) label tomorrow if no one points out anything wrong - Z22112 [18:02:42] I would ask for conversions 0, 0.5, and 1 instead to be consistent with how Booleans work (re @vrandecic: We created the Kleenean type -- if anyone wants to check it out and see if it works well. I will remove the (TESTING) label tomo...) [18:05:04] This is a more intuitive way to think about it and works with the basic operations you do with Booleans. For example, if you do an arithmetic or it gives you the correct result [18:15:07] Python type converter is broken [18:16:16] You used Z0 in an edit instead of a creation I think [18:30:27] Indeed! Fixed, thanks! [19:31:03] I think Error messages are a very important quality thing. A lot of functions either end up throwing an Error that nobody can understand or return a string that could get messed up by another function in the composition [19:31:22] I am fine either way, but I would like to see some consensus around that change (re @Feeglgeef: I would ask for conversions 0, 0.5, and 1 instead to be consistent with how Booleans work) [19:31:39] that is very true, unfortunately (re @Feeglgeef: I think Error messages are a very important quality thing. A lot of functions either end up throwing an Error that nobody can un...) [19:34:25] Perhaps there could be a function you call like Wikifunctions.Error that displays the raw text given to it. (re @Feeglgeef: I think Error messages are a very important quality thing. A lot of functions either end up throwing an Error that nobody can un...) [19:36:33] yeah, that's an idea [21:31:49] What kind of arithmetic are you thinking about? Can you give a few examples? (re @Feeglgeef: This is a more intuitive way to think about it and works with the basic operations you do with Booleans. For example, if you do ...) [21:32:43] 1-((1-x)*(1-y)) = x or y [21:33:39] I just reread [[w:Three-valued_logic]] and it seems that [-1,0,1] is most/very common. (re @Feeglgeef: I would ask for conversions 0, 0.5, and 1 instead to be consistent with how Booleans work) [21:34:40] It doesn't say that? (re @u99of9: I just reread [[w:Three-valued_logic]] and it seems that [-1,0,1] is most/very common.) [21:34:55] It lists 5 methods and both are one of them [21:35:15] x=0.5, y=0.5 returns 0.75 which is not in the space (re @Feeglgeef: 1-((1-x)*(1-y)) = x or y) [21:35:31] That's the probability (re @u99of9: x=0.5, y=0.5 returns 0.75 which is not in the space) [21:36:07] Makes more sense than 0 [21:36:12] No, they shouldn't be interpreted as probabilities. 0.5 means maybe [21:36:27] Is 0 a better interpretation? (re @u99of9: No, they shouldn't be interpreted as probabilities. 0.5 means maybe) [21:36:48] Or(maybe,maybe)=maybe [21:37:05] Slightly more likely than maybe* (re @u99of9: Or(maybe,maybe)=maybe) [21:37:22] Yes if 0=maybe (re @Feeglgeef: Makes more sense than 0) [21:37:48] No. It's a type of logic, not a probability estimate. (re @Feeglgeef: Slightly more likely than maybe*) [21:38:39] No 0 is false or false if false is -1 (re @u99of9: Yes if 0=maybe) [21:39:31] -3* [21:40:34] Which of the 5 are you following? I can't see any that use 0.5. (re @Feeglgeef: It lists 5 methods and both are one of them) [21:41:57] I don't follow where you are getting this. Clearly Or(false,false)=false no matter which system we use. (re @Feeglgeef: No 0 is false or false if false is -1) [21:44:12] in yours: [21:44:13] true or true = true [21:44:14] true or maybe = true [21:44:16] true or true = true [21:44:17] maybe or maybe = maybe [21:44:19] maybe or false = false (!) [21:44:20] false or false = invalid [21:44:22] in mine: [21:44:23] true or true = true [21:44:25] true or maybe = true [21:44:26] true or false = true [21:44:28] maybe or maybe = out of bounds [21:44:29] maybe or false = maybe [21:44:31] false or false = false [21:44:59] 1-((1-(-1))*(1-(-1))) [21:44:59] 1-(2*2) [21:45:01] 1-4 [21:45:02] -3 (re @u99of9: I don't follow where you are getting this. Clearly Or(false,false)=false no matter which system we use.) [21:46:07] And the 0.75 can be fixed by the type converter. An incorrect answer cannot (re @Feeglgeef: in yours: [21:46:08] true or true = true [21:46:10] true or maybe = true [21:46:11] true or true = true [21:46:13] maybe or maybe = maybe [21:46:14] maybe or false = false (!) [21:46:16] false o...) [21:48:35] in yours: [21:48:35] true and true = true [21:48:37] true and maybe = maybe [21:48:38] true and false = false [21:48:40] maybe and maybe = maybe [21:48:41] maybe and false = maybe (!) [21:48:43] false and false = true (!) [21:48:44] in mine: [21:48:46] true and true = true [21:48:47] true and maybe = maybe [21:48:49] true and false = false [21:48:50] maybe and maybe = invalid [21:48:52] maybe and false = false [21:48:53] false and false = false [21:49:31] The main thing is false * false = true. That sounds really annoying to deal with in an implementation [21:50:25] Different systems would use different algorithms for each function. For example, in the balanced system as the page says A OR B OR C ... = MAX(A, B, C...). This gives exact correct answers every time without the need for code conversion. [21:51:30] Can be done with mine as well (re @u99of9: Different systems would use different algorithms for each function. For example, in the balanced system as the page says A OR B ...) [21:51:35] How do you do and? [21:51:53] If it comes to a vote, I hope there’s a “maybe” 😄 [21:52:25] A AND B AND C... = MIN(A, B, C ...) it's in the article (re @Feeglgeef: How do you do and?) [21:53:33] * is more intuitive (re @u99of9: A AND B AND C... = MIN(A, B, C ...) it's in the article) [21:53:45] Also doesn't work well with if statements [21:55:29] Generally systems like these should resemble probability in how they work (re @Feeglgeef: * is more intuitive) [21:55:42] ??? Of course a Boolean if branch is inappropriate for a Kleenian. (re @Feeglgeef: Also doesn't work well with if statements) [21:55:58] I don't agree (re @u99of9: ??? Of course a Boolean if branch is inappropriate for a Kleenian.) [21:56:28] Sure, it's not ideal, but some implementations that have kleenean inputs may want to use an if [21:57:37] Yes there will be a different function for Kleenian if. Like a 3 valued case statement. (re @Feeglgeef: Sure, it's not ideal, but some implementations that have kleenean inputs may want to use an if) [21:57:51] In programming language implementations (re @u99of9: Yes there will be a different function for Kleenian if. Like a 3 valued case statement.) [21:58:46] That’s a bit Z15728 😉 (re @u99of9: Yes there will be a different function for Kleenian if. Like a 3 valued case statement.) [21:59:02] false=false, maybe=true, true=true is a little weird but not as bad as false=true, maybe=false, true=true [22:04:30] If (K >= 0) or similar will be precise and clear. I recommend against using If(K) no matter which system we settle on. (re @Feeglgeef: In programming language implementations) [22:14:35] It seems that we have what was proposed and supported. I’m open to an alternative, if the case can be made in the Type proposal.