[00:07:10] Could have just used Z20854 and wondered why you would want to use float64 in the first place! 😏 (re @Toby: @vrandecic : "This is no fun!" I thought it was very fun to see you trying your best to do floating point conversions in your h...) [01:52:57] Have you ever used an irrational number of cups to make your cake on pi day? (re @Al: Could have just used Z20854 and wondered why you would want to use float64 in the first place! 😏) [02:27:27] I tried but it just didn't add up.... sent myself on a tangent trying to pour it perfectly (re @Toby: Have you ever used an irrational number of cups to make your pie on pi day?) [03:11:29] There is a general question here. We have Z21402 and Z21770 so that we may not need two versions of every function, so it would be worth figuring out which way to default when we are making a new function. (re @Al: Could have just used Z20854 and wondered why you would want to use float64 in the first place! 😏) [03:20:14] Well, so long as it’s not float, I don’t mind! 😏 (re @Toby: There is a general question here. We have Z21402 and Z21770 so that we may not need two versions of every function, so it would ...) [03:20:57] @vrandecic your science teacher might like my only substantive contribution to wikisource: https://en.wikisource.org/wiki/Index:British_Weights_and_Measures_-_Superior_to_the_Metric,_by_James_W._Evans.djvu where the Metropolitan Inspector of Weights and Measures tried to make his case to the politicians that Australia should not adopt the inferior metric system. I find [03:20:58] it an inte [03:20:58] resting example of where knowledge and serious thought were not sufficient to come to the correct conclusions! (IMHO :)) (re @Sannita: FYI, the recording of Monday's Volunteer's Corner is now available on Commons at https://www.wikifunctions.org/wiki/File:Abstrac...) [03:21:57] Maybe we need to give you a third type which can express irrationals exactly. Power series?? (re @Al: Well, so long as it’s not float, I don’t mind! 😏) [03:23:50] Of course not. We don’t do cups in the UK. (re @Toby: Have you ever used an irrational number of cups to make your pie on pi day?) [03:24:56] The Metropolitan Inspector lost out big over here. Our cup is exactly 250mL. (re @Al: Of course not. We don’t do cups in the UK.) [03:26:08] I'm not sure quite how serious you are, but I imagine that float64 would be the best type we've got for "circumference of circle given radius". (re @Al: Well, so long as it’s not float, I don’t mind! 😏) [03:28:26] I’m not bothered by spurious accuracy, but it might be nice to know exactly how imprecise a float representation is. (re @Toby: Maybe we need to give you a third type which can express irrationals exactly. Algebraic power series??) [03:38:35] Why? What is the float64 approximation of π, expressed as a rational number? (re @Toby: I'm not sure quite how serious you are, but I imagine that float64 would be the best type we've got for "circumference of circle...) [03:57:17] We have a function, and now a test case Z21773 for that. But I'm not sure of your point. If you're just saying that float64 is an approximation too, then sure, but it's usually not represented as exact, so nobody should be misled when they see a decimal with limited decimal places, whereas someone could if they saw a fraction (even if more accurate). (re @Al: Why? What [03:57:17] is the flo [03:57:17] at64 approximation of π, expressed as a rational number?) [04:16:00] I'm quite partial to FOTW. But I agree it should not necessarily fall on staff to write it. I wonder if something like the following would work. Instead of just "suggesting" a ZID at [[Wikifunctions:Function of the Week]] we instead have a subpage where people can post full write-ups of their proposed function. Maybe others can vote support/oppose underneath each one. [04:16:00] Then whoeve [04:16:01] r compiles the newsletter can just see if any are good/supported enough, and copy-paste it. It might not necessarily receive one per week, but I think it has a fair shot. (re @Sannita: Also the newsletter #185 is out! [04:16:02] * Happy Wikipedia day! [04:16:04] * Quarterly Planning for January–March 2025 [04:16:05] * Recent Changes in the sof...) [04:46:49] It’s a fair point. Perhaps when converting from a float to rational, we should have some quantification of the imprecision? That is, it converts to a range between two rationals, not a single value? (re @Toby: We have a function, and now a test case Z21773 for that. But I'm not sure of your point. If you're just saying that float64 is a...) [04:55:19] Actually the conversion from float to rational is exact. The imprecision is that Z20862 is an approximation of the underlying irrational pi that neither float64 nor Rational can represent perfectly. (re @Al: It’s a fair point. Perhaps when converting from a float to rational, we should have some quantification of the imprecision? That...) [05:26:03] I feel like maybe we could have something like [[en:WP:FA]], where there's "featured functions" that have gone through a review by someone else for like well documented with comments, good test coverage, secure, makes sense, significant/useful enough etc. and we have a chronological queue based on date passed for "this week's featured function" (hopefully once [05:26:04] it gets more active [05:26:04] it could become "today's featured function") (re @Toby: I'm quite partial to FOTW. But I agree it should not necessarily fall on staff to write it. I wonder if something like the follo...) [05:29:03] Thinking of that, does anyone have ideas for other dynamic community content we can integrate into the main page? [05:32:09] On Commons ticking all of those checkboxes would add up to Quality Images. Featured Images need remarkable aesthetic wow as well. I wonder which we should aim at. Personally, I like FOTW when they have an interesting role/story on top of technical quality. (re @MolecularPilot: I feel like maybe we could have something like [[en:WP:FA]], where there's "featured [05:32:09] functions" that hav [05:32:10] e gone through a review ...) [05:54:59] Yeah, definetetly, agree with the last point 100%! 🙂 [08:02:56] I think a 2-tier system like they have on commons and you proposed would be perfect, I just put down some thoughts about the process and criteria at [[Wikifunctions:Function review]], anyone is welcome to improve it or leave their thoughts! 🙂 [10:31:52] Thanks for kicking this off. I think "Featured" should have a community vote rather than be one person's decision. Some of the "Quality" points can link elsewhere to require best practice (as you've done with the naming conventions. I've edited quite a few, in ways that I think should be agreeable. (re @MolecularPilot: I think a 2-tier system like they have on commons [10:31:52] and you pro [10:31:52] posed would be perfect, I just put down some thoughts about the pro...) [10:37:02] I haven't touched the documentation one yet, because I have strong reservations about it, and would probably end up pruning it in ways you might disagree with. Basically, I don't think it hits what we're after for a multilingual project. Unless there is good reason, I think the original ZID_keyIDs should be retained throughout, because they are what every language [10:37:02] speaker will ex [10:37:02] pect on WF, so will be intelligible across languages. Comments can be encouraged in complex implementations, but in simple implementations, I hope the code can speak for itself (mindful that most users speak very few languages). (re @MolecularPilot: I think a 2-tier system like they have on commons and you proposed would be perfect, I just put down some thoughts about [10:37:02] the pro...) [10:55:51] Although I support this initiative, I don't think it replaces FOTW for quite a while, because I think most of what is useful about FOTW is the explanations and analysis in the writing. [11:23:33] Yes, the conversion is exact, but the float is inherently inaccurate to ±1 * 2^n (or something). This is reasonably obvious if you can see all the significant figures, but once it’s expressed as a fraction, it becomes obscure (especially if the fraction is simplified). Even an explicit range may be opaque when expressed as a fraction though, so perhaps we should just see [11:23:33] which [11:23:34] digit in a decimal representation corresponds to the inaccuracy (10^–16, in the case of pi?) 🤷‍♂️ (re @Toby: Actually the conversion from float to rational is exact. The imprecision is that Z20862 is an approximation of the underlying ir...) [12:55:41] Ironically, I can only calculate the approximate error using float at the moment, but it looks like Wikifunctions “thinks” that Z20862 differs from a better approximation by about -1.2246468e-16. I used 3.14159265358979323846264338327950 (32 decimal places) in Z21785 (re @Toby: Actually the conversion from float to rational is exact. The imprecision is that Z20862 is an [12:55:41] appro [12:55:41] ximation of the underlying ir...) [19:42:58] 🤔 I created Z21789 for approximating rational numbers as decimal strings but getcontext().prec is not recognised, so default decimal precision of 28 applies as a maximum, presumably 🤷‍♂️ [22:14:12] We can do better without inbuilt functions. I might try that over the weekend, but it would be good to know how you want the final digit rounding to work. (re @Al: 🤔 I created Z21789 for approximating rational numbers as decimal strings but getcontext().prec is not recognised, so default dec...) [22:23:00] Yes, I did wonder about specifying the rounding option separately… but we should still have a default of, say, round to nearest (away from zero when equal) 🤷‍♂️ (re @Toby: We can do better without inbuilt functions. I might try that over the weekend, but it would be good to know how you want the fin...) [22:32:50] Can we return an actual decimal string? The first test requires exponential notation, which we could use a separate display function for. (re @Al: 🤔 I created Z21789 for approximating rational numbers as decimal strings but getcontext().prec is not recognised, so default dec...) [22:40:24] I suppose so. It’s just a bit tricky counting the digits. But I suppose that could be yet another parameter: switch to exponential after some magnitude(s) of exponent (perhaps with Boolean: use engineering notation?) (re @Toby: Can we return an actual decimal string? (e.g. "0.00000000000000012246468") The first test requires exponential notation, which w...) [22:42:10] If writing the long division function by hand, it would be easier to just return it as a long string then let other functions summarise long strings in whatever notation they like. (re @Al: I suppose so. It’s just a bit tricky counting the digits. But I suppose that could be yet another parameter: switch to exponenti...) [22:44:18] Either way, define it how you like, and I could do the strict decimal elsewhere and compose it into yours with different display options. (re @Toby: If writing the long division implementation by hand, it would be easier to just return it as a long string then let other functi...) [22:44:39] Yes, I was just thinking about the alternative of specifying decimal places. But if you’re just doing long division, how do you decide when to terminate? (re @Toby: If writing the long division implementation by hand, it would be easier to just return it as a long string then let other functi...) [22:44:52] Although since you've already set up the function signature, it's best to just leave this one without extra boolean parameters. [22:46:08] Yes, I was assuming I would just import your work via a composition 😏 (re @Toby: Although since you've already set up the function signature, it's best to just leave this one without extra boolean parameters.) [22:46:16] I will terminate when I reach parameter_2 number of significant digits? (re @Al: Yes, I was just thinking about the alternative of specifying decimal places. But if you’re just doing long division, how do you ...) [22:47:27] Ah, not pure long division, then? (re @Toby: I will terminate when I reach parameter_2 number of significant digits?) [22:48:26] Okay as long as you're clear what format you want returned, and at what point it switches to Engineering notation. PS, also consider what you want when you ask for less significant digits than there are before the decimal point. e.g. decimal_string(123456789, 3) = "123000000"? (re @Al: Yes, I was assuming I would just import your work via a composition 😏) [22:50:00] ?? pretty much. I suppose it depends exactly which version of the long division algorithm you learned. (re @Al: Ah, not pure long division, then?) [22:50:36] I’m not, but Python is. 1.23e+6, apparently 😏 (re @Toby: Okay as long as you're clear what format you want returned, and at what point it switches to Engineering notation. PS, also con...) [22:54:05] I think our version would continue indefinitely unless you got recurring digits 🤷‍♂️ (re @Toby: ?? pretty much. I suppose it depends exactly which version of the long division algorithm you learned.) [23:51:18] I specifically disagree with the no-drive-by-noms thing. Users not involved are the best to nominate imho (re @MolecularPilot: I think a 2-tier system like they have on commons and you proposed would be perfect, I just put down some thoughts about the pro...) [23:51:27] Otherwise looks fine