Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:122946 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id A85591A009D for ; Thu, 4 Apr 2024 21:20:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1712265645; bh=wccfPrUv2ubNMevJOnYJxyLW3Xe99ClePw+sL49i/jY=; h=Date:Subject:To:References:From:In-Reply-To:From; b=a5W2J+6PI5dqldRKmTPwXET0H6jhZHyG8D+xkMskeGtYu1ftXzs/3IlAPMuaXF2uK ky4JqiKjsxffhW47gbiLNAJJM74QdNqegZB4nzvj4Fog7FQd4R+5QJGKymNUoU8sLO NfO8Em+Et79PxTaxIvr5dCXG5bMBAM4e0ws8SvOkiv1jFoemGVQqXuYZ5H/VM0Qu6T QIiEINhFnZvmwVmHXxsXuEkAVXUloFs07MFbTUetZ1qP14IihuE3Km96ie+gCNbIiR BluIOdxPjnCdNF5IYjEjGv7dmk/l1VBg9Y7r5inij0Qv1RFUNFlcEA1S/3QvO55cNn +mYTxpY/P2F4A== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D85F91801DB for ; Thu, 4 Apr 2024 21:20:42 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: * X-Spam-Status: No, score=1.0 required=5.0 tests=BAYES_50,DMARC_MISSING, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,SPF_HELO_PASS,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from gliadin.co.uk (gliadin.co.uk [80.82.115.221]) by php-smtp4.php.net (Postfix) with ESMTP for ; Thu, 4 Apr 2024 21:20:41 +0000 (UTC) Received: from [192.168.0.17] (hari-18-b2-v4wan-169870-cust740.vm1.cable.virginm.net [92.239.242.229]) by gliadin.co.uk (Postfix) with ESMTPSA id D8C56FA2870 for ; Fri, 5 Apr 2024 00:20:11 +0300 (MSK) Content-Type: multipart/alternative; boundary="------------RWQZ7loAS3FTiVoTY20TH8Wd" Message-ID: Date: Thu, 4 Apr 2024 22:20:11 +0100 Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath To: internals@lists.php.net References: <4F094EDA-5058-407D-AF39-06FD934FDE1F@sakiot.com> <91111e11ee72ffd18e1a1b2412246d00@gliadin.co.uk> <94B21565-9129-4379-A720-F4EDDD0A8D84@sakiot.com> <2c2f2731-acee-4c70-93d9-8ec6d9edc4db@redmagic.org.uk> Content-Language: en-US In-Reply-To: From: barney@redmagic.org.uk (Barney Laurance) This is a multi-part message in MIME format. --------------RWQZ7loAS3FTiVoTY20TH8Wd Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 04/04/2024 22:10, Jordan LeDoux wrote: > > > On Thu, Apr 4, 2024 at 1:59 PM Barney Laurance > wrote: > > Hi again, > > On 27/03/2024 00:40, Saki Takamachi wrote: >>> Do we also need `toFloat` and `toInt` functions? Seems like using explicit functions will be safer than casting. >>> >>> For toInt I'd expect an exception if the value is outside the range of possible ints. For toFloat it might be nice to have a flag >>> argument to give the developer the choice of having it throw if the value is outside the range of floats or return INF or -INF, >>> or possibly the user should just check for infinite values themselves. >> I was thinking about those features too. However, I'm concerned that proposing too many features will complicate the RFC and make it difficult to get it approved. > > Coming back to this point, I think these are basic features that > people would expect to be there - I think I would find just > slightly frustrating to start learning how to use a class like > this and then > find that it doesn't have these functions. Casting and calling > `intval` or `floatval` all feel like slightly awkward workarounds > that shouldn't be needed in a greenfield project. We know that the > string > inside the object is always a numeric string, so it should be > easier to parse it as an int than to parse it as a date or a JSON > document. Code doing the latter should stand out as odd looking. > > > > The class cannot guarantee that it can return a value in the type you > request however, so the way that is handled would need to be decided. > The value can easily be outside of the range of an int. Should it > return a float silently in that case for `toInt()`? What if the value > is beyond the range of a float? That would be a very rare situation, > as floats can represent extremely large numbers (with very reduced > accuracy), but I would expect it to throw an exception if that > happened. Ideally an exception that I could catch and ignore, since I > can almost surely deal with that error in most situations. > > What about a number that is so small that it can't fit in a float? > Similar situation, though I expect it would occur slightly more often > than a number being too large to fit in a float, even though it would > also be rare. > > I think these helper functions belong in the RFC, but they aren't > quite straightforward, which is what I think Saki was alluding to. > Yes I agree there are subtleties to work out for these functions. I don't think there's such a thing as a number to small to fit in a float. Converting from decimal to float is always an approximation, sometimes the best approximation available as a float will be either 0 or -0. --------------RWQZ7loAS3FTiVoTY20TH8Wd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On 04/04/2024 22:10, Jordan LeDoux wrote:


On Thu, Apr 4, 2024 at 1:59 PM Barney Laurance <barney@redmagic.org.uk> wrote:
Hi again,

On 27/03/2024 00:40, Saki Takamachi wrote: 
Do we also need `toFloat` and `toInt` functions? Seems like using explicit functions will be safer than casting.

For toInt I'd expect an exception if the value is outside the range of possible ints. For toFloat it might be nice to have a flag
argument to give the developer the choice of having it throw if the value is outside the range of floats or return INF or -INF,
or possibly the user should just check for infinite values themselves.

I was thinking about those features too. However, I'm concerned that proposing too many features will complicate the RFC and make it difficult to get it approved.

Coming back to this point, I think these are basic features that people would expect to be there - I think I would find just slightly frustrating to start learning how to use a class like this and then
find that it doesn't have these functions. Casting and calling `intval` or `floatval` all feel like slightly awkward workarounds that shouldn't be needed in a greenfield project. We know that the string
inside the object is always a numeric string, so it should be easier to parse it as an int than to parse it as a date or a JSON document. Code doing the latter should stand out as odd looking.



The class cannot guarantee that it can return a value in the type you request however, so the way that is handled would need to be decided. The value can easily be outside of the range of an int. Should it return a float silently in that case for `toInt()`? What if the value is beyond the range of a float? That would be a very rare situation, as floats can represent extremely large numbers (with very reduced accuracy), but I would expect it to throw an exception if that happened. Ideally an exception that I could catch and ignore, since I can almost surely deal with that error in most situations.

What about a number that is so small that it can't fit in a float? Similar situation, though I expect it would occur slightly more often than a number being too large to fit in a float, even though it would also be rare.

I think these helper functions belong in the RFC, but they aren't quite straightforward, which is what I think Saki was alluding to.


Yes I agree there are subtleties to work out for these functions. I don't think there's such a thing as a number to small to fit in a float. Converting from decimal to float is always an approximation, sometimes the best approximation available as a float will be either 0 or -0.
--------------RWQZ7loAS3FTiVoTY20TH8Wd--