Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124274
Subject: Re: [PHP-DEV] [RFC] [Discussion] Allow int type argument to BCMath
 function
To: internals@lists.php.net
References: <668B4C78.2000808@adviesenzo.nl>
 <8FA0DE3B-2AF4-4110-9836-14E035DC8169@sakiot.com>
Message-ID: <668B6428.9030705@adviesenzo.nl>
Date: Mon, 8 Jul 2024 05:59:36 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <8FA0DE3B-2AF4-4110-9836-14E035DC8169@sakiot.com>
Content-Type: multipart/alternative;
 boundary="------------070504080007090506080607"
From: php-internals_nospam@adviesenzo.nl (Juliette Reinders Folmer)

This is a multi-part message in MIME format.
--------------070504080007090506080607
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On 8-7-2024 5:18, Saki Takamachi wrote:
> Hi Juliette,
>
>> Hi Saki,
>>
>> Just wondering: why `int|string` instead of `float|string` ?
>> In my experience, floats are the more pertinent type for which to use the BCMath extension.
>>
>> Smile,
>> Juliette
> Since floating point numbers always contain a certain amount of error, I believe that they are not suitable as arguments for BCMath.
Okay, so in that case, I must be missing something.
> For example, 0.285 becomes 0.284999... in floating point. From the perspective of arbitrary precision math, there is no universally agreeable way to properly handle values ​​like this: there will always be people who want to treat it as 0.285, and people who want to treat it as 0.284999....

I honestly don't understand what you are saying here.

If 0.285 is a string, then no type conversion would be needed to pass it 
to BCMath anyhow.
Otherwise, 0.285 would be a floating point number already.

If the type for BCMath would become `int|string`, in non-strict mode, 
there would be quite a significant change in behaviour for the BCMath 
functions as passing the _float_ 0.285 would previously result in the 
string "0.285" being passed to the BCMath function, but would now result 
in the integer 0 being passed.

I think this BC-break will need to be called out as it is not mentioned 
in the RFC.
I also think this BC-break should be enough reason not to accept the RFC.

Smile,
Juliette








--------------070504080007090506080607
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 8-7-2024 5:18, Saki Takamachi wrote:<br>
    </div>
    <blockquote
      cite="mid:8FA0DE3B-2AF4-4110-9836-14E035DC8169@sakiot.com"
      type="cite">
      <pre wrap="">Hi Juliette,

</pre>
      <blockquote type="cite">
        <pre wrap="">Hi Saki,

Just wondering: why `int|string` instead of `float|string` ?
In my experience, floats are the more pertinent type for which to use the BCMath extension.

Smile,
Juliette
</pre>
      </blockquote>
      <pre wrap="">
Since floating point numbers always contain a certain amount of error, I believe that they are not suitable as arguments for BCMath.</pre>
    </blockquote>
    Okay, so in that case, I must be missing something.<br>
    <blockquote
      cite="mid:8FA0DE3B-2AF4-4110-9836-14E035DC8169@sakiot.com"
      type="cite">
      <pre wrap="">For example, 0.285 becomes 0.284999... in floating point. From the perspective of arbitrary precision math, there is no universally agreeable way to properly handle values ​​like this: there will always be people who want to treat it as 0.285, and people who want to treat it as 0.284999....</pre>
    </blockquote>
    <br>
    I honestly don't understand what you are saying here.<br>
    <br>
    If 0.285 is a string, then no type conversion would be needed to
    pass it to BCMath anyhow.<br>
    Otherwise, 0.285 would be a floating point number already.<br>
    <br>
    If the type for BCMath would become `int|string`, in non-strict
    mode, there would be quite a significant change in behaviour for the
    BCMath functions as passing the _float_ 0.285 would previously
    result in the string "0.285" being passed to the BCMath function,
    but would now result in the integer 0 being passed.<br>
    <br>
    I think this BC-break will need to be called out as it is not
    mentioned in the RFC.<br>
    I also think this BC-break should be enough reason not to accept the
    RFC.<br>
    <br>
    Smile,<br>
    Juliette<br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <br>
  </body>
</html>

--------------070504080007090506080607--