Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:120978 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 42351 invoked from network); 4 Sep 2023 18:23:19 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 4 Sep 2023 18:23:19 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 4DF40180504 for ; Mon, 4 Sep 2023 11:23:18 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS24940 176.9.0.0/16 X-Spam-Virus: No X-Envelope-From: Received: from chrono.xqk7.com (chrono.xqk7.com [176.9.45.72]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 4 Sep 2023 11:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bastelstu.be; s=mail20171119; t=1693851796; bh=rYubTOkpogNTWdvd/YALx+l6vjL2kLhrUZTfzQ+gTSQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type:from:to:cc:subject:message-id; b=QC09eul+H2cl948B6CznssSWz1hPFCMRKfc7Etzjk757AFVgzj1cf9hFZ06HUPM5N XzCZeBWKZWp8QSbzJrLKDeW+WDE4cA1Y6sQNReYALiywZencP0hwbGxn7GZ0QtJerZ P+nlojlQMSbB69DpWUq9Kw7ITNziztVE22GPg2l0xM5oovApDJkNxzRaUAwnoIGF5+ YS2CHQcUuwOemPE5d2tSL6TgWEldHWR3Fqoca+8JNHb4G3WJ+dH30fHaM8TSLkuFDK ECvxlt2rItBSsn4t3C+l3z13hSINqpJLRegZpgFfX0GZPPSSEAVNpHGVLQcz1fvJW8 D1vBVrgA8aRHg== Message-ID: <9a19120d-1767-6214-c728-c67a9a98f977@bastelstu.be> Date: Mon, 4 Sep 2023 20:23:13 +0200 MIME-Version: 1.0 Content-Language: en-US To: =?UTF-8?Q?Alexandru_P=c4=83tr=c4=83nescu?= Cc: Jorg Sowa , PHP internals References: <7f23f0ac-bba6-5997-b737-2a252205cf85@bastelstu.be> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] [RFC] [Discussion] Add 4 new rounding modes to round() function From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=) Hi On 9/3/23 17:50, Alexandru Pătrănescu wrote: > I believe consistency is important and using UP for "away from zero" and > DOWN for "towards zero" sounds good to me. That was so far used > consistently everywhere, as far as I'm aware. > Documentation is very clear about what they mean, and you can always think > that both positive infinity and negative infinity are up while zero is down. I believe that the code should be easy to understand without needing to consult the documentation. I don't find it obvious at all that "up" would be the infinity with the same signum rather than the positive infinity. This would likely be something I would need to look up all the time. In fact, let me quote from the Wikipedia article linked in the RFC: https://en.wikipedia.org/wiki/Rounding#Rounding_half_up > However, some programming languages (such as Java, Python) define their half up as round half away from zero here. Rounding "up" in Wikipedia is defined as rounding towards positive infinity: https://en.wikipedia.org/wiki/Rounding#Rounding_up > round up (or take the ceiling, or round toward positive infinity): y is the smallest integer that is not less than x. I'd also like to refer to this exchange of Mastodon regarding a very similar issue with PHP 8.3's new IntervalBoundary enum: https://phpc.social/@asgrim/109318512018298154 The terminology "closed" and "open" matches the standard terminology in maths, but without the necessary background in maths it is not obvious and indeed "inclusive" and "exclusive" might've been easier to understand for everyone, including mathematicians [1]. In this case of rounding the existing behavior of "up" meaning "towards the same-signum infinity" rather than "positive infinity" appears to even contradict the definition used by Wikipedia which I also expect to be the mathematical definition (but I'm happy to be corrected here). "Away from zero" should be clear to everyone with a basic understanding of English. Introducing a brand-new RoundingMode enum (using union types) I suggested in my first email would nicely solve the naming problem and would also make the API more obvious to use due to stronger typing in the long run. > Yes, we can have some extra constants for the four ones that contain "up" > or "down" with "away from zero" and "towards zero", but I find it > unnecessary. Best regards Tim Düsterhus [1] Back then I didn't have the energy to create a follow-up RFC and now it's definitely too late. At least the naming is mathematically accurate.