Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123045
Feedback-ID: id5114917:Fastmail
Content-Type: multipart/alternative;
 boundary="------------VlTkDBWUHXAv9ovfv8imiw0m"
Message-ID: <c3663fb3-1a78-4077-80b9-8431119fbb96@rwec.co.uk>
Date: Mon, 8 Apr 2024 20:21:38 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] Native decimal scalar support and object types in
 BcMath - do we want both?
To: internals@lists.php.net
References: <40553F28-2EC2-475A-BD8E-1D6517AA2A51@rwec.co.uk>
 <2B518F62-B774-45C9-82A2-EF6653AAE34E@sakiot.com>
 <A703D145-1A10-4C7E-9E0C-1F0BEF94CF99@rwec.co.uk>
 <CAMrTa2G+_v1aO_g7NLiLsTwquJaf9=Zj5bp2ODGzVSB3iGr6pw@mail.gmail.com>
 <0f3d0f89-3064-4d56-9fb2-801bb0cda8a5@rwec.co.uk>
 <CAMrTa2HgSSTT1wJPz0x4X=nW2ijQDmaGhdNGKx1rLePdBWGfwQ@mail.gmail.com>
Content-Language: en-GB
In-Reply-To: <CAMrTa2HgSSTT1wJPz0x4X=nW2ijQDmaGhdNGKx1rLePdBWGfwQ@mail.gmail.com>
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

This is a multi-part message in MIME format.
--------------VlTkDBWUHXAv9ovfv8imiw0m
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 07/04/2024 23:50, Jordan LeDoux wrote:
> By a "scalar" value I mean a value that has the same semantics for 
> reading, writing, copying, passing-by-value, passing-by-reference, and 
> passing-by-pointer (how objects behave) as the integer, float, or 
> boolean types.


Right, in that case, it might be more accurate to talk about "value 
types", since arrays are not generally considered "scalar", but have 
those same behaviours. And Ilija recently posted a draft proposal for 
"data classes", which would be object, but also value types: 
https://externals.io/message/122845


> As I mentioned in the discussion about a "scalar arbitrary precision 
> type", the idea of a scalar in this meaning is a non-trivial 
> challenge, as the zval can only store a value that is treated in this 
> way of 64 bits or smaller.


Fortunately, that's not true. If you think about it, that would rule out 
not only arrays, but any string longer than 8 bytes long!

The way PHP handles this is called "copy-on-write" (COW), where multiple 
variables can point to the same zval until one of them needs to write to 
it, at which point a copy is transparently created.


> The pointer for this value would fit in the 64 bits, which is how 
> objects work, but that's also why objects have different semantics for 
> scope than integers. Objects are potentially very large in memory, so 
> we refcount them and pass the pointer into child scopes, instead of 
> copying the value like is done with integers.


Objects are not the only thing that is refcounted. In fact, in PHP 4.x 
and 5.x, *every* zval used a refcount and COW approach; changing some 
types to be eagerly copied instead was one of the major performance 
improvements in the "PHP NG" project which formed the basis of PHP 7.0. 
You can actually see this in action here: https://3v4l.org/oPgr4

This is all completely transparent to the user, as are a bunch of other 
memory/speed optimisations, like interned string literals, packed 
arrays, etc.

So, there may be performance gains if we can squeeze values into the 
zval memory, but it doesn't need to affect the semantics of the new type.



> In general I would say that libbcmath is different enough from other 
> backends that we should not expect any work on a BCMath implementation 
> to be utilized in other implementations. It *could* be that we are 
> able to do that, but it should not be something people *expect* to 
> happen because of the technical differences.
>
> Some of the broader language design choices would be transferable 
> though. For instance, the standard names of various calculation 
> functions/methods are something that would remain independent, even 
> with the differences in the implementation.


Yes, that makes sense. Even if we don't have an interface, it would be 
annoying if one class provided $foo->div($bar), and another provided 
$foo->dividedBy($bar)


> For money calculations, scale is always likely to be a more useful 
> configuration. For mathematical calculations (such as machine learning 
> applications, which I would say is the other very large use case for 
> this kind of capability), precision is likely to be the more useful 
> configuration. Other applications that I have personally encountered 
> include: simulation and modeling, statistical distributions, and data 
> analysis. Most of these can be done with fair accuracy without 
> arbitrary precision, but there are certainly types of applications 
> that would benefit from or even require arbitrary precision in these 
> spaces.


This probably relates quite closely to Arvid's point that for a lot of 
uses, we don't actually need arbitrary precision, just something that 
can represent small-to-medium decimal numbers without the inaccuracies 
of binary floating point. That some libraries can be used for both 
purposes is not necessarily evidence that we could ever "bless" one for 
both use cases and make it a single native type.


> My intuition at the moment is that a single number-handling API would 
> be challenging to do without an actual proposed implementation on the 
> table for MPDec/MPFR. 


I think it would certainly be wise to experiment with how each library 
can interface to the language as an extension, before spending the extra 
time needed to integrate it as a new zval type.


> But even with these extensions available in PHP, they are barely used 
> by developers at all because (at least in part) of the enormous 
> difference between PECL and PIP. For PHP, I do not think that 
> extensions are an adequate substitute like PIP modules are for Python.


Yes, this is something of a problem. On the plus side, a library doesn't 
need to be incorporated into the language to be widely installed, 
because we have the concept of "bundled" extensions; and in practice, 
Linux distributions add a few "popular" PECL extensions to their list of 
installable binary packages. On the minus side, even making it into the 
"bundled" list doesn't mean it's installed by default everywhere, and 
userland libraries spend a lot of effort polyfilling things which would 
ideally be available by default.


> This is, essentially, the thesis of the research and work that I have 
> done in the space since joining the internals mailing list.


Thanks, there's some really useful perspective there.

Regards,

-- 
Rowan Tommins
[IMSoP]

--------------VlTkDBWUHXAv9ovfv8imiw0m
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 07/04/2024 23:50, Jordan LeDoux
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAMrTa2HgSSTT1wJPz0x4X=nW2ijQDmaGhdNGKx1rLePdBWGfwQ@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div class="gmail_quote">
          <div>By a "scalar" value I mean a value that has the same
            semantics for reading, writing, copying, passing-by-value,
            passing-by-reference, and passing-by-pointer (how objects
            behave) as the integer, float, or boolean types.</div>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>Right, in that case, it might be more accurate to talk about
      "value types", since arrays are not generally considered "scalar",
      but have those same behaviours. And Ilija recently posted a draft
      proposal for "data classes", which would be object, but also value
      types: <a class="moz-txt-link-freetext" href="https://externals.io/message/122845">https://externals.io/message/122845</a><br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CAMrTa2HgSSTT1wJPz0x4X=nW2ijQDmaGhdNGKx1rLePdBWGfwQ@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <div>As I mentioned in the discussion about a "scalar
            arbitrary precision type", the idea of a scalar in this
            meaning is a non-trivial challenge, as the zval can only
            store a value that is treated in this way of 64 bits or
            smaller.</div>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>Fortunately, that's not true. If you think about it, that would
      rule out not only arrays, but any string longer than 8 bytes
      long! </p>
    <p>The way PHP handles this is called "copy-on-write" (COW), where
      multiple variables can point to the same zval until one of them
      needs to write to it, at which point a copy is transparently
      created.</p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CAMrTa2HgSSTT1wJPz0x4X=nW2ijQDmaGhdNGKx1rLePdBWGfwQ@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <div>The pointer for this value would fit in the 64 bits,
            which is how objects work, but that's also why objects have
            different semantics for scope than integers. Objects are
            potentially very large in memory, so we refcount them and
            pass the pointer into child scopes, instead of copying the
            value like is done with integers.</div>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>Objects are not the only thing that is refcounted. In fact, in
      PHP 4.x and 5.x, *every* zval used a refcount and COW approach;
      changing some types to be eagerly copied instead was one of the
      major performance improvements in the "PHP NG" project which
      formed the basis of PHP 7.0. You can actually see this in action
      here: <a class="moz-txt-link-freetext" href="https://3v4l.org/oPgr4">https://3v4l.org/oPgr4</a></p>
    <p>This is all completely transparent to the user, as are a bunch of
      other memory/speed optimisations, like interned string literals,
      packed arrays, etc.</p>
    <p>So, there may be performance gains if we can squeeze values into
      the zval memory, but it doesn't need to affect the semantics of
      the new type.<br>
    </p>
    <p><br>
    </p>
    <br>
    <blockquote type="cite"
cite="mid:CAMrTa2HgSSTT1wJPz0x4X=nW2ijQDmaGhdNGKx1rLePdBWGfwQ@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <div>In general I would say that libbcmath is different enough
            from other backends that we should not expect any work on a
            BCMath implementation to be utilized in other
            implementations. It *could* be that we are able to do that,
            but it should not be something people *expect* to happen
            because of the technical differences.</div>
          <div><br>
          </div>
          <div>Some of the broader language design choices would be
            transferable though. For instance, the standard names of
            various calculation functions/methods are something that
            would remain independent, even with the differences in the
            implementation.<br>
          </div>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>Yes, that makes sense. Even if we don't have an interface, it
      would be annoying if one class provided $foo-&gt;div($bar), and
      another provided $foo-&gt;dividedBy($bar)<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CAMrTa2HgSSTT1wJPz0x4X=nW2ijQDmaGhdNGKx1rLePdBWGfwQ@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <div>For money calculations, scale is always likely to be a
            more useful configuration. For mathematical calculations
            (such as machine learning applications, which I would say is
            the other very large use case for this kind of capability),
            precision is likely to be the more useful configuration.
            Other applications that I have personally encountered
            include: simulation and modeling, statistical distributions,
            and data analysis. Most of these can be done with fair
            accuracy without arbitrary precision, but there are
            certainly types of applications that would benefit from or
            even require arbitrary precision in these spaces.</div>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>This probably relates quite closely to Arvid's point that for a
      lot of uses, we don't actually need arbitrary precision, just
      something that can represent small-to-medium decimal numbers
      without the inaccuracies of binary floating point. That some
      libraries can be used for both purposes is not necessarily
      evidence that we could ever "bless" one for both use cases and
      make it a single native type.</p>
    <p><br>
    </p>
    <p>
      <blockquote type="cite">My intuition at the moment is that a
        single number-handling API would be challenging to do without an
        actual proposed implementation on the table for MPDec/MPFR. </blockquote>
    </p>
    <p><br>
    </p>
    <p>I think it would certainly be wise to experiment with how each
      library can interface to the language as an extension, before
      spending the extra time needed to integrate it as a new zval type.<br>
      <br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CAMrTa2HgSSTT1wJPz0x4X=nW2ijQDmaGhdNGKx1rLePdBWGfwQ@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <div>But even with these extensions available in PHP, they are
            barely used by developers at all because (at least in part)
            of the enormous difference between PECL and PIP. For PHP, I
            do not think that extensions are an adequate substitute like
            PIP modules are for Python.<br>
          </div>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>Yes, this is something of a problem. On the plus side, a library
      doesn't need to be incorporated into the language to be widely
      installed, because we have the concept of "bundled" extensions;
      and in practice, Linux distributions add a few "popular" PECL
      extensions to their list of installable binary packages. On the
      minus side, even making it into the "bundled" list doesn't mean
      it's installed by default everywhere, and userland libraries spend
      a lot of effort polyfilling things which would ideally be
      available by default.</p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CAMrTa2HgSSTT1wJPz0x4X=nW2ijQDmaGhdNGKx1rLePdBWGfwQ@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <div>This is, essentially, the thesis of the research and work
            that I have done in the space since joining the internals
            mailing list.</div>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>Thanks, there's some really useful perspective there.</p>
    <p>Regards,</p>
    <pre class="moz-signature" cols="72">-- 
Rowan Tommins
[IMSoP]</pre>
  </body>
</html>

--------------VlTkDBWUHXAv9ovfv8imiw0m--