Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120375
Date: Sun, 21 May 2023 13:18:28 +0100
To: internals@lists.php.net
User-Agent: K-9 Mail for Android
In-Reply-To: <CA+kxMuSP1TTB5141-5ePJWZT5_DZ8rCHvkh0ikKBcnXYSMV5zg@mail.gmail.com>
References: <05b7e019-27d4-e6a9-2088-f712c22317a9@mabe.berlin> <CA+kxMuSP1TTB5141-5ePJWZT5_DZ8rCHvkh0ikKBcnXYSMV5zg@mail.gmail.com>
Message-ID: <4D8DE606-5E99-4D6F-962E-CBE1392C4B94@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] rounding integers
From: rowan.collins@gmail.com (Rowan Tommins)

On 21 May 2023 13:00:30 BST, Dan Ackroyd <Danack@basereality=2Ecom> wrote:
>On Sun, 21 May 2023 at 06:16, Marc <marc@mabe=2Eberlin> wrote:
>>
>> Do you think this could be an acceptable BC-break
>
>No=2E Suggesting changing a 30 year old maths operations is a huge BC bre=
ak=2E
>
>> or should this be a different function?
>
>Just make your own that does precisely what you want=2E=2E=2E

I agree on the first point, but disagree on the second=2E It's far too lat=
e to change round() itself, but the lack of built-in functions for converti=
ng to int in a controlled way is frustrating, particularly as the fashion m=
oves towards stronger typing in general=2E

On the surface, it sounds like a trivial operation, but there's a lot of e=
dge cases to think about (limits of FP precision, negatives including negat=
ive zero, etc), and shipping a robust implementation of int_round, int_floo=
r and int_ceil in core would save everyone having to rediscover them the ha=
rd way=2E

Regards,

--=20
Rowan Tommins
[IMSoP]