[00:01:57] Did I get unbanned? (re @Egezort: I forwarded it) [00:03:22] Some people sent good reactions to the message but there wasn't much talk afterwards. Perhaps you could reach out to an admin, I assume they'll be charitable since you apologised before [00:03:44] I don't know who is an admin (re @Egezort: Some people sent good reactions to the message but there wasn't much talk afterwards. Perhaps you could reach out to an admin, I...) [00:09:19] You can write a message asking to be taken back, explaining the reason you were banned and why you won't repeat what you did etc. and I'll forward it, I don't know if there's anything I can do further than that though [00:12:28] I think there may be an error in Z20885, but only staff can change it (ping @vrandecic ). I believe line 76 should be if math.copysign(1, Z20885K1) < 0: (reverse the order of the arguments). This is because we are trying to get the sign from Z20885K1, and copysign gets the sign from the second argument. I believe that fixing this will mean that Z21455 [00:12:28] should pass Z21413. [00:13:05] This is why we need function maintainers (re @Toby: I think there may be an error in Z20885, but only staff can change it (ping @vrandecic ). I believe line 76 should be if...) [00:13:13] We shouldn't need staff to do this [00:13:36] Change looks fine though [00:31:48] Less important, because they are likely to usually be ignored, but it looks like the exponent's returned when returning a special value (lines 67 to 79) are not the same as the exponents listed at https://en.wikipedia.org/wiki/Double-precision_floating-point_format#Double-precision_examples where the +/- zero have exponents equivalent to -1023 and the others have +1024. [00:31:48] If you a [00:31:49] gree, it would be good to make this change at the same time. (re @Toby: I think there may be an error in Z20885, but only staff can change it (ping @vrandecic ). I believe line 76 should be if...) [00:34:45] Oh, and the NaNs have different significands too. (re @Toby: Less important, because they are likely to usually be ignored, but it looks like the exponents returned when returning a special...) [02:36:43] Wasn't there explicit yapping about ignoring the standard here? (re @Toby: Less important, because they are likely to usually be ignored, but it looks like the exponents returned when returning a special...) [02:36:53] Discussing* [02:38:22] Possibly. I recall discussing whether it was okay to have a separate key which would essentially override the other keys. But I don't think that implies anything about how those keys should be set (especially if we ever convert to binary objects etc). (re @Feeglgeef: Wasn't there explicit discussion about ignoring the standard here?) [02:39:20] Yeah and we decided that the special value thing was "still the standard" (re @Toby: Possibly. I recall discussing whether it was okay to have a separate key which would essentially override the other keys. But I ...) [02:39:42] I see no reason and actively object to having both [02:55:46] @amire80 can you stop vandalizing the sidebar? [02:55:51] Thank you! [03:15:55] https://tools-static.wmflabs.org/bridgebot/a9554563/file_67785.jpg [03:16:16] So fix it? (re @amire80: ) [03:16:21] This is how the sidebar looks like in French because of the changes that you're making, and I'm quite sure that it's not because "my computer is broken". (re @Feeglgeef: @amire80 can you stop vandalizing the sidebar?) [03:16:32] I was trying to fix it, and you repeatedly reverted me. [03:16:48] Wrap it with a {{#ifexists}} call [03:17:12] There's a better solution than that [03:17:41] Weren't you the one complaining about wikilambda-edit being in the wrong spot [03:17:46] This is the same thing [03:17:48] Buddy [05:55:09] I'm still having trouble figuring out what is wrong here. This python executes fine: exponent = int("1023") [05:55:10] significand = int("4503599627370495") [05:55:11] mantissa = 1 + significand/2**52 [05:55:13] positive = 1 [05:55:14] import math [05:55:16] print(mantissa) [05:55:17] val = math.ldexp(mantissa/2.0, exponent+1) * (1 if positive else -1) [05:55:19] print(str(val)) [05:55:20] print(str(val)==str(val)) (re @Toby: Good feedback. I've made a test that is difficult for the equality function: Z21420) [05:56:06] I'd rush to blame it on rustpython (re @Toby: I'm still having trouble figuring out what is wrong here. This python executes fine: exponent = int("1023") [05:56:07] significand = int("4...) [05:58:40] Okay. I don't know anything about that, but I suppose it's plausible that the compiling/system matters in such edge cases. (re @Feeglgeef: I'd rush to blame it on rustpython) [05:58:45] The flowchart is: [05:58:46] Is it Wikifunctions fault? [05:58:47] If no, is it RustPython's fault? [05:58:49] If no, are you sure? [05:58:50] If no, triple check [05:58:52] If no, it's probably a dependency object's fault [05:58:53] If no, it's probably your fault [05:58:55] If no, the Matrix is plotting against you or something, idk [05:59:15] I'm still trying to figure out step 1! [06:01:05] CPython is by far the most commonly used implementation with 99% market share but Wikifunctions uses RustPython because it's easier to sandbox [06:01:30] This means that it can work differently than CPython [06:08:14] https://rustpython.github.io/demo/ Yes, your right. And the code I listed above fails on that, but passes where I was testing it before on https://www.w3schools.com/python/trypython.asp?filename=demo_compiler (re @Feeglgeef: They have a demo on their GitHub.io IIRC) [06:15:49] I've added an explanatory note at Talk:Z21420 . If we raised this as an issue with RustPython is there much chance it would get fixed? (re @Toby: https://rustpython.github.io/demo/ Yes, your right. And the code I listed above fails on that, but passes where I was testing it...) [06:16:38] Not sure (re @Toby: I've added an explanatory note at Talk:Z21420 . If we raised this as an issue with RustPython is there much chance it would get...) [06:17:14] It's not a bug many people often come across [06:19:06] Might be worth filling an issue on GitHub [06:26:47] A lot of extra things to give you a better idea: [06:26:47] If the error is a lot lot of JSON, it's quite likely to be Wikifunctions or an egregious user mistake [06:26:49] If the error cannot be replicated in a code sandbox, it's likely the evaluator's fault [06:26:50] If the error references any object with a ZID above 10000 that is not directly relevant (i.e. the function, inputs, etc), it's likely to be another object's fault [06:26:52] Also using this to promote my userscript :) it helps with these guys a bit (re @Feeglgeef: The flowchart is: [06:26:53] Is it Wikifunctions fault? [06:26:55] If no, is it RustPython's fault? [06:26:56] If no, are you sure? [06:26:58] If no, triple check [06:26:59] If no, it...) [08:38:39] https://github.com/RustPython/RustPython/issues/5471 (re @Feeglgeef: Might be worth filling an issue on GitHub) [08:39:17] Thank you (re @Toby: https://github.com/RustPython/RustPython/issues/5471) [08:40:11] Also, why do they make it so hard to request desysoping? They blocked me on meta for some reason and now I need someone to deliver my resignation for me [08:46:03] I did it! [08:46:13] Only took a small amount of rights abuse [12:08:19] Can someone have a look at the error message at Z21468. I can't see why that fails, and I don't know what "unspecified error" means. [12:09:56] "vandalizing" LOL (re @Feeglgeef: @amire80 can you stop vandalizing the sidebar?) [12:15:14] I think it means “your guess is as good as mine”. It looks like the evaluation is correct so maybe (first guess) the problem is in the equality function? (re @Toby: Can someone have a look at the error message at Z21468. I can't see why that fails, and I don't know what "unspecified error" me...) [12:22:46] Thanks. The equality test has an explicit test of this exact comparison Z20926 ... (re @Al: I think it means “your guess is as good as mine”. It looks like the evaluation is correct so maybe (first guess) the problem is ...) [12:24:17] The other test seems to be passing now (with the original evaluation). Some sort of glitch? (re @Toby: Thanks. The equality test has an explicit test of this exact comparison Z20926 ...) [12:24:42] Oh, wait, now the original Z21468 passes! Maybe it was related to my manual edit cleaning up an invisible implementation which had moved to the other equality function. [12:24:45] https://www.wikifunctions.org/w/index.php?title=Z20850&diff=155875&oldid=155791 [12:27:16] Yes. That was the implementation used when I tried the equality function, but it wasn’t in the list when I looked for it 😏 (re @Toby: Oh, wait, now the original Z21468 passes! Maybe it was related to my manual edit cleaning up an invisible implementation which ...) [12:29:20] which also cleans up some of the other frustrations I had today. A strange example is Z21411 which I thought I was totally blaming on RustPython... (re @Toby: Oh, wait, now the original Z21468 passes! Maybe it was related to my manual edit cleaning up an invisible implementation which ...) [12:35:05] It doesn’t help that the test details don’t show the implementation of the function used in result validation. Is there a ticket for that? (Or would it be a Feature request?) (re @Toby: which also cleans up some of the other frustrations I had today. A strange example is Z21411 which I thought I was totally blami...) [12:37:01] I'm not aware of one. I'd appreciate if you can write it, because I'm still quite vague when trying to analyse errors. (re @Al: It doesn’t help that the test details don’t show the implementation of the function used in result validation. Is there a ticket...) [12:39:22] I think that’s the general problem. I’ll give it a go and include this particular problem as an example. (re @Toby: I'm not aware of one. I'd appreciate if you can write it, because I'm still quite vague when trying to analyse errors, so I don'...) [12:39:36] Another takeaway from this is that we need an automatic method of finding and removing ghost implementations. They are hard to notice and can have really bad effects. [12:44:18] Yes. But not many people can move implementations (I guess that’s what causes the problem). So the few that do need to be careful to do it correctly. Is there a log of moved implementations that we can check? (re @Toby: Another takeaway from this is that we need an automatic method of finding and removing ghost implementations. They are hard to n...) [12:50:52] It's caused by changing the function at the top of the implementation. Maybe all functioneers can do this? (re @Al: Yes. But not many people can move implementations (I guess that’s what causes the problem). So the few that do need to be carefu...) [12:56:20] Oh! I’ve never tried that… It looks like we can. Either it shouldn’t be possible or it should remove the implementation from the list in the original function on publish. Do we have a ticket for that? (re @Toby: It's caused by changing the function at the top of the implementation. Maybe all functioneers can do this?) [12:57:39] I saw some discussion with @jdforrester about how to do this best but can't remember the decision (re @Al: Oh! I’ve never tried that… It looks like we can. Either it shouldn’t be possible or it should remove the implementation from the...) [12:59:51] I'm turning into a pumpkin in 2 minutes. Thanks for your help - that has resolved some major headaches. I still don't fully trust float64, but I'm getting there. [14:31:44] after I asked you not to use inflammatory tones, one week of silence should teach you when enough is enough (re @Feeglgeef: Buddy) [18:42:46] I decided to define it quite narrowly but I’m happy to extend it. *T383326* (re @Toby: I'm not aware of one. I'd appreciate if you can write it, because I'm still quite vague when trying to analyse errors, so I don'...)