[00:25:08] Great to see. I just took a look inside the converters, and it looks like a tiny speedup is possible. At the start of each it tries to make sure the input type is a string. The second time it checks can be inside the first condition, so that if it skips the first condition (because it's already a string), it doesn't even need to test it again, it can go straight on to [00:25:08] converting. [00:28:00] True. It really should be a while loop, to be honest, but I am scared of loops šŸ˜„ That would be even faster. [00:28:01] I would be surprised if that kind of speedup would make any difference, though. I know that time outs are a real peril currently, but these are mostly due to network, rarely due to actual execution, I think (but yeah, we really need better data and metrics to support that intuition -- it is on the way!) [00:30:12] I updated Z17410 -- is that what you had in mind? [00:35:04] Yes, thanks. I agree that I'm scrutinising speed harder than usual because I'm frustrated by timeouts. I'm looking forward to the better metrics. I guess for really simple functions then type conversion may be as slow as the actual function execution. But agree that network may overwhelm both. [00:35:51] I understand the frustration! [00:36:30] Also updated Z17411 [00:36:54] The thing is, the improved implementation is not just faster, but also more robust, I guess [00:37:39] Yes I didn't check whether more than two steps was ever necessary. (re @vrandecic: The thing is, the improved implementation is not just faster, but also more robust, I guess) [00:38:20] it *might* in some cases. Also, it didn't deal well with zero steps. Now it can do any number of steps, including zero. [03:05:45] I'm tempted to unilaterally change these from integer to natural number type, but realised that discussion is warranted: Z17424 Z17442 [03:25:34] IMO the above cases should be strictly typed as Natural Numbers, and we shouldn't bother making a separate integer version of them. But on the other hand, I've already made separately output-typed versions of the absolute value of int function: Z17128 and Z17144. So maybe I'm being inconsistent? [04:18:33] I think the basic functions here should just be Natural number functions. If some use requires an Integer version, thatā€™s fair enough, but I wouldnā€™t create it ahead of time ā€œjust in caseā€ šŸ¤·ā€ā™‚ļø (re @Toby: IMO the above cases should be strictly typed as Natural Numbers, and we shouldn't bother making a separate integer version of th...) [04:29:57] Low confidence. I dunno. Since they already exist, I'd keep them. But Al's point is also good. I really don't know. [04:41:45] So letā€™s leave those, rename the Integer versions and create Natural number equivalents for Weekdays (consistent with what we have for months). [16:02:44] For Integers, are +0 and -0 undefined or equal to zero? We didnā€™t update the Type Proposalā€™s ā€œIdentityā€ section, so it asserts that zero is always positive. Z17461 tests positive and negative zero against each other, asserting equality. Z17463 fails here because it requires the Signs to be equal. [18:28:03] I would say that, eventually, the validitor should mark positive and negative zero as invalid, and we should update the proposal's text. If no one complains, happy to do that. [18:41:22] The text needs quite a few changes. Iā€™m happy to revise it if weā€™re all in agreement. (re @vrandecic: I would say that, eventually, the validitor should mark positive and negative zero as invalid, and we should update the proposal...) [18:42:00] Indeed. Happy to leave that with you. [21:44:33] Newsletter 161: Welcome, Daphne! [21:44:34] https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-06-26 [21:45:25] Also: [21:45:25] * Input needed: Design proposal towards better multi-linguality of the About widget [21:45:27] * Volunteersā€™ Corner on July 1st, 2024 [21:45:28] * Recent Changes in the software [21:45:30] * New Type: Day of the Week [21:45:31] * Function of the Week: subtract Integers [23:19:22] 6349