[00:02:32] But successfully turns to Python when required. : https://tools-static.wmflabs.org/bridgebot/5a1f455d/file_74907.jpg [01:05:13] Time for the next code converter issue? I believe Z24537 fails in JavaScript because the JS implementation never gets the input keys properly (if you try just immediately returning a value, it still fails). So I presume that Z19701 has a problem with very large numerators and denominators, but I haven't noticed anything wrong in particular. Anyone else want to take a [01:05:13] look? [09:20:01] JavaScript won’t echo a Natural number with that number of digits either 🤷‍♂️ (re @u99of9: Time for the next code converter issue? I believe Z24537 fails in JavaScript because the JS implementation never gets the input...) [09:31:57] Oh… seems it will, after all… (re @Al: JavaScript won’t echo a Natural number with that number of digits either 🤷‍♂️) [09:55:58] Hmm… JavaScript seems to be able to handle either the numerator or the denominator, but not both (in Z20121). I was wrong about Natural numbers (or Z10015 was, which is itself “interesting”) [10:07:32] Our guts agree. (re @vrandecic: Abstract content will be CC BY SA, indeed. I guess we would need to ask a lawyer what that means for the text created, but my gu...) [10:08:36] Ah, not so “interesting”, just serialisation, of course 🙄 (re @Al: Hmm… JavaScript seems to be able to handle either the numerator or the denominator, but not both (in Z20121). I was wrong about ...) [10:32:33] The gcd function is recursive, so that might blow the call stack, I suppose 🤔 The iterative form in Z14707 succeeds in finding no common divisor greater than 1, but fails with a recursive version (where all tests pass). I suggest we adopt the iterative approach in Z19701. @vrandecic (re @Al: Hmm… JavaScript seems to be able to handle either the numerator or the [10:32:33] denominator, [10:32:33] but not both (in Z20121). I was wrong about ...) [11:26:52] I've been cheeky and did it iniline: https://www.wikifunctions.org/wiki/Z19701?uselang=en&diff=prev&oldid=225784 [11:31:09] but Z24537 still fails on against Z20855 [11:46:57] Looks like a failure in orchestration, probably a timeout or rate limit. It took only about 4 seconds in Z14707 but more than 9 for the test case 🤷‍♂️ (re @vrandecic: but Z24537 still fails on against Z20855) [11:47:57] would you mind filing a bug? I think that's a great localizable issue [11:48:55] Will do … later. (re @vrandecic: would you mind filing a bug? I think that's a great localizable issue) [11:50:22] thanks! [11:53:22] Z29082 (re @Al: The gcd function is recursive, so that might blow the call stack, I suppose 🤔 The iterative form in Z14707 succeeds in finding n...) [11:55:04] That's a big number for evaluation: : https://tools-static.wmflabs.org/bridgebot/f6d73e22/file_74924.jpg [13:57:45] Yes, I noticed. It seem QuickJS is not particularly quick with doing math with BigInts [13:57:59] but I think no bug needs to be filed anymore (re @Al: Will do … later.) [13:58:12] the issue was the Debug call in the converter inside the loop [13:58:13] https://www.wikifunctions.org/wiki/Z20855?uselang=en&diff=prev&oldid=225793 [13:58:58] once this was commented out, Z24537 now passes the JavaScript implementation! [13:59:37] Wikifunctions.Debug is quite slow, and if called many times in a loop, it will easily cause timeouts [14:00:50] Ah, thanks… I was just about to start it! I hadn’t noticed the debug, but… yeah… don’t do that 😎 (re @vrandecic: once this was commented out, Z24537 now passes the JavaScript implementation!) [14:02:09] my fault not catching it before connecting [14:05:19] I guess we’ll need the same change in Z19702 (re @vrandecic: my fault not catching it before connecting) [14:25:36] done https://www.wikifunctions.org/wiki/Z19702?uselang=en&diff=prev&oldid=225796 [14:25:51] i hope I didn't break things worse [14:28:09] I think I did [14:31:50] It’s okay with existing tests on Z20112. I’m just setting up a more challenging test. (re @vrandecic: I think I did) [14:32:37] i just reverted it, it failed a simple run of Z24429 [14:34:38] Okay. I’ll set up the test anyway… (re @vrandecic: i just reverted it, it failed a simple run of Z24429) [14:38:44] yes, please, I think I figured out my mistake [14:41:57] ok, the change is in again, and this time it seems to work. Looking forward to your test to stress test it [14:51:24] Not too much stress… but JavaScript seems to beat Python: Z29083 (re @vrandecic: ok, the change is in again, and this time it seems to work. Looking forward to your test to stress test it) [14:53:17] Actually, that’s odd (as it were) because they can’t be co-prime… (re @Al: Not too much stress… but JavaScript seems to beat Python: Z29083) [14:55:14] Now, QuickJS beating Python is odd, given the behavior on Z24537 [14:57:59] I chose much smaller ints. The UI doesn’t lend itself to handling very long numbers. (re @vrandecic: Now, QuickJS beating Python is odd, given the behavior on Z24537) [15:31:46] No, I see they are much smaller, but I am surprised that "very large numbers" vs "large numbers" make such a big difference in Python vs JS [15:40:46] But the gcd calculation would be optimised in Python’s Fraction implementation. (re @vrandecic: No, I see they are much smaller, but I am surprised that "very large numbers" vs "large numbers" make such a big difference in P...)