[04:43:03] This looks like it will really benefit from a good renderer and parser. [05:22:04] Yes :) (re @Toby: This looks like it will really benefit from a good renderer and parser.) [05:23:05] I think that we should get rid of the "Floating point special value" type and replace it with the proper representation as laid out in IEEE 754. The current situation looks really really concerning to me. [05:24:05] Not Gregorian-date level concerning, but I think we may want to consider a discussion on it before we remove the testing label to minimize damage if we do want to change it [05:29:56] My reasoning for this is that: [05:29:57] 1. Having a key that overrides and ignores the value of all other keys is weird and hard to work with [05:29:58] 2. This whole point of this type is a close match of the IEEE standard. Why not match it if we can? [05:30:00] 3. This system would make reliably performing operations on values easier and match them with the exact standard [07:07:56] I haven't tried it yet, so take this with a grain of salt. Why would our internal representation matter to the reliability of performing operations? Any in code will be reliable if the code conversion is correct. Any in composition are up to us to get right. (re @Feeglgeef: My reasoning for this is that: [07:07:57] 1. Having a key that overrides and ignores the value of all other keys is weird and hard to work ...) [07:10:06] Also, exceptions which override regular behaviour seem like exactly how exceptions should work. [07:31:09] My understanding is that the special values leave quite a few things undefined, e.g. the exact bits for a NaN etc. The special values allow to abstract away from this. [07:31:10] I take objection to the statement that it is not following the IEEE standard. It is. [07:31:12] I am kinda wondering if having signaling NaNs and quiet NaNs at all was the right choice, as JS and Pything don't seem to model these. Maybe we should just remove these two values. [07:34:06] Thanks, I hope I fixed that https://www.wikifunctions.org/wiki/Z20885?uselang=en&diff=prev&oldid=147121 (re @Feeglgeef: The python type converter outputs -2 as a natural number inside of an integer with a negative sign. You are missing a math.abs :...) [14:23:45] But the keys are still there :/ (re @Toby: Also, exceptions which override regular behaviour seem like exactly how exceptions should work.) [14:25:11] The IEEE standard tells you how to represent specific special values, it doesn't say you introduce an effective 10-12ish more bytes for your representation. (re @vrandecic: My understanding is that the special values leave quite a few things undefined, e.g. the exact bits for a NaN etc. The special v...) [16:55:21] The standard speaks about the bit representation of floats. We aren't really storing the bits anyway, but a structure that captures the semantics faithfully and interoperably. There are special values the bit patterns can represent. We have a field to represent those special values. There are 1:1 mappings for each valid value, just semantically more explicit. [16:56:05] If we were to represent the special values through numbers in the exponent and the mantissa instead, the special values would be implicit. [20:45:34] Newsletter 184: [20:46:46] Newsletter 184: [20:46:48] * Function of the Week: age [20:46:49] * Call for Functions: Intros for year articles [20:46:51] * Recent Changes in the software [20:46:52] * News in Types: Double-precision floating-point numbers [20:46:54] * Newsletter taking a break [20:46:55] https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-12-19 [21:49:46] What are the other "flagship functions?" (re @vrandecic: Newsletter 184: [21:49:48] * Function of the Week: age [21:49:49] * Call for Functions: Intros for year articles [21:49:51] * Recent Changes in the software [21:49:52] * Ne...) [21:52:36] Something that would be nice for the Wikipedia integration is to know which wiki a function was called on. Perhaps the Wikifunctions object would provide Wikifunctions.wiki, set to none if called on WF, and a wiki name string if called on another wiki, like "dagwiki" [21:53:34] This would be useful if, for example, a wiki had already set up many function calls but wanted to change the output for only their wiki. [21:54:30] Like South Korea used to have a different legal age system, so the Age function might have checked for krwiki [21:55:53] kowiki* [21:57:26] There should also be more information, like wiki language, namespace, page title, etc (re @Feeglgeef: Something that would be nice for the Wikipedia integration is to know which wiki a function was called on. Perhaps the Wikifunct...) [22:28:35] [Positive, "I am the globglogabgalab", +"The shwabble-dabble-wabble-gabble flibba blabba blab", "positive zero" being a correct and fully supported representation of +0 just seems wrong (re @Feeglgeef: But the keys are still there :/)