Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122989
Feedback-ID: id5114917:Fastmail
Content-Type: multipart/alternative;
 boundary="------------7PngVxyl3eG3GjXZQ0dagxlE"
Message-ID: <3c74f433-be6b-4f20-beb0-f09db2fb39b6@rwec.co.uk>
Date: Fri, 5 Apr 2024 23:52:35 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type
To: internals@lists.php.net
References: <18c42fdbb30.2831.17a3710df6d58f02ca570cc47e197a63@interi.co>
 <CAFPFaMLZ3MeGXt5OPmAkwM-n-eZcp1gT7RQCnpXSyHxZThOn2g@mail.gmail.com>
 <CAOyH9yReYorVd1jDPyk_O73JUn1VvqEAz0Fb7mvQ6ke9k9FcZA@mail.gmail.com>
 <CAFPFaMKoH1PD_qaBPLw9pwid0NB5zyZYM7AgogYOWFhPVysEwQ@mail.gmail.com>
 <CAOyH9ySfZnVgpZkDbL+sP_DCmnyBaq4D=K9kHjsXXLhX-dOkcA@mail.gmail.com>
 <f4002280-bec7-459b-b65b-b261e4f52aad@rwec.co.uk>
 <CAMrTa2Gm4B++JvdddkHQkDDqWxmxLY6pCE7C5QeSPsV-08YRgw@mail.gmail.com>
 <9dfdd88a-f840-4933-b26b-8149a4381246@rwec.co.uk>
 <CAMrTa2FsLejL1GZi8-qVbq54_s2jA4SR_xL-OBSHR5u5hiZqoQ@mail.gmail.com>
Content-Language: en-GB
In-Reply-To: <CAMrTa2FsLejL1GZi8-qVbq54_s2jA4SR_xL-OBSHR5u5hiZqoQ@mail.gmail.com>
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

This is a multi-part message in MIME format.
--------------7PngVxyl3eG3GjXZQ0dagxlE
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 04/04/2024 23:31, Jordan LeDoux wrote:
>
> Well, firstly most of the financial applications that I've worked in 
> (I work for a firm that writes accounting software right now) do not 
> calculate intermediate steps like this with fixed precision, or even 
> have an interest in doing so.


My background is in e-commerce (specifically, travel) rather than 
finance. In that context, it's common to have a single-step operation 
like "per_person_price equals total_price divided by number of 
passengers" where both per_person_price and total_price are going to be 
expressed with the same accuracy.

The top two results for "money" on Packagist are 
https://www.moneyphp.org/ and https://github.com/brick/money both of 
which take this general model: the scale of values is fixed, and every 
operation that might produce fractions of that requires a rounding mode.


> Truly "fixed-precision" is not something that decimal should even try 
> to be, in my opinion. The use cases where you CANNOT simply round the 
> result at the end to fit your display output or your storage location 
> are very minimal.


In that case, why do we need to think about the scale or precision of a 
decimal at all? What would the syntax 1.234_d3 do differently from 1.234_d?


> I mean, what you are describing is how such OBJECTS are designed in 
> other languages like Python, but not scalars.


I don't see any connection at all between what I'm describing and 
objects. I'm talking about what operations make sense on a particular 
data type, regardless of how that data type is implemented.

To be honest, I'm not really sure what "scalar" means in this context. 
In PHP, we call strings "scalars" because they're neither "arrays" nor 
"objects"; but none of those have definitions which are universal to 
other languages.


> This kind of precision restriction isn't something you would place on 
> an individual value, it's something you would place on all 
> calculations. That's why in Python this is done with a global runtime 
> setting using `getContext().perc` and `getContext().rounding`. A 
> particular value having a precision of X doesn't imply anything 
> concrete about a calculation that uses that value necessarily.


Global settings avoid needing extra parameters to each operation, but 
don't really work for the use case I'm describing: different currencies 
have different "natural" scale, e.g. Japanese Yen have a scale of 0 (no 
fractional Yen), Bitcoin has a scale of 8 (100 million satoshis in 1 
bitcoin).  A program dealing with multiple currencies will want to 
assign a different scale to different values.


> Maybe we're just not understanding each other. Are you opposed to the 
> idea of doing this as a scalar?


Not at all; my first examples used method syntax, because I was basing 
them on https://github.com/brick/money In my last e-mail, I also gave 
examples using normal function syntax.

What I'm saying is that $x / 2 doesn't have a good answer if $x is a 
fixed-precision number which can't be divided by 2 without exceeding 
that precision. You need a third operand, the rounding mode, so you 
can't write it as a binary operator, and need some kind of function like 
decimal_div(decimal $dividend, int|decimal $divisor, RoundingMode 
$roundingMode). How you implement "decimal" doesn't change that at all.


Regards,

-- 
Rowan Tommins
[IMSoP]

--------------7PngVxyl3eG3GjXZQ0dagxlE
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 04/04/2024 23:31, Jordan LeDoux
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAMrTa2FsLejL1GZi8-qVbq54_s2jA4SR_xL-OBSHR5u5hiZqoQ@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div class="gmail_quote">
          <div><br>
          </div>
          <div>Well, firstly most of the financial applications that
            I've worked in (I work for a firm that writes accounting
            software right now) do not calculate intermediate steps like
            this with fixed precision, or even have an interest in doing
            so.</div>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>My background is in e-commerce (specifically, travel) rather than
      finance. In that context, it's common to have a single-step
      operation like "per_person_price equals total_price divided by
      number of passengers" where both per_person_price and total_price
      are going to be expressed with the same accuracy.<br>
    </p>
    <p>The top two results for "money" on Packagist are
      <a class="moz-txt-link-freetext" href="https://www.moneyphp.org/">https://www.moneyphp.org/</a> and <a class="moz-txt-link-freetext" href="https://github.com/brick/money">https://github.com/brick/money</a> both
      of which take this general model: the scale of values is fixed,
      and every operation that might produce fractions of that requires
      a rounding mode.<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CAMrTa2FsLejL1GZi8-qVbq54_s2jA4SR_xL-OBSHR5u5hiZqoQ@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">Truly "fixed-precision" is not
          something that decimal should even try to be, in my opinion.
          The use cases where you CANNOT simply round the result at the
          end to fit your display output or your storage location are
          very minimal.</div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>In that case, why do we need to think about the scale or
      precision of a decimal at all? What would the syntax 1.234_d3 do
      differently from 1.234_d?<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CAMrTa2FsLejL1GZi8-qVbq54_s2jA4SR_xL-OBSHR5u5hiZqoQ@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">I mean, what you are describing is how
          such OBJECTS are designed in other languages like Python, but
          not scalars. </div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>I don't see any connection at all between what I'm describing and
      objects. I'm talking about what operations make sense on a
      particular data type, regardless of how that data type is
      implemented.</p>
    <p>To be honest, I'm not really sure what "scalar" means in this
      context. In PHP, we call strings "scalars" because they're neither
      "arrays" nor "objects"; but none of those have definitions which
      are universal to other languages.<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CAMrTa2FsLejL1GZi8-qVbq54_s2jA4SR_xL-OBSHR5u5hiZqoQ@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">This kind of precision restriction
          isn't something you would place on an individual value, it's
          something you would place on all calculations. That's why in
          Python this is done with a global runtime setting using
          `getContext().perc` and `getContext().rounding`. A particular
          value having a precision of X doesn't imply anything concrete
          about a calculation that uses that value necessarily.<br>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>Global settings avoid needing extra parameters to each operation,
      but don't really work for the use case I'm describing: different
      currencies have different "natural" scale, e.g. Japanese Yen have
      a scale of 0 (no fractional Yen), Bitcoin has a scale of 8 (100
      million satoshis in 1 bitcoin).  A program dealing with multiple
      currencies will want to assign a different scale to different
      values.<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CAMrTa2FsLejL1GZi8-qVbq54_s2jA4SR_xL-OBSHR5u5hiZqoQ@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <div>Maybe we're just not understanding each other. Are you
            opposed to the idea of doing this as a scalar?</div>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>Not at all; my first examples used method syntax, because I was
      basing them on <a class="moz-txt-link-freetext" href="https://github.com/brick/money">https://github.com/brick/money</a> In my last e-mail, I
      also gave examples using normal function syntax.</p>
    <p>What I'm saying is that $x / 2 doesn't have a good answer if $x
      is a fixed-precision number which can't be divided by 2 without
      exceeding that precision. You need a third operand, the rounding
      mode, so you can't write it as a binary operator, and need some
      kind of function like decimal_div(decimal $dividend, int|decimal
      $divisor, RoundingMode $roundingMode). How you implement "decimal"
      doesn't change that at all.<br>
    </p>
    <p><br>
    </p>
    <p>Regards,<br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Rowan Tommins
[IMSoP]</pre>
  </body>
</html>

--------------7PngVxyl3eG3GjXZQ0dagxlE--