Native decimal scalar support and object types in BcMath - do we want both?

On Sun, Apr 7, 2024 at 2:45 PM Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> 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. 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. However, the actual numerical value that is used by every single one of these libraries is not guaranteed to be 64 bits or smaller, and for some of them is in fact guaranteed to be larger. 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. Both this and the precision/scale question are pretty significant design questions and choices. While the arbitrary precision values of these libraries will not fit inside a zval, they are on average smaller than PHP objects in memory, so it may not be a significant problem to eagerly copy them like we do with integers. However, if that is not the route that is taken, they could end up having scoping semantics that are similar to objects, even if we don't give them a full class entry with a constructor, properties, etc. This is part of the reason that, for example, the ext-decimal implementation which uses the MPDec library represents these numbers as an object with a fluent interface.

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.

The implementation for round-to-precision for BCMath would be much slower than the implementation for round-to-scale for MPDec/MPFR, even if the underlying calculations were done at the same performance. The main challenge for the precision vs. scale issue is that precision *also* includes the integer part for some implementations, while scale does not. But in general, it is easier to over-calculate using precision and then round/truncate to scale, then it is to calculate with scale not knowing until the calculation has been completed what your precision will be (for some kinds of calculations). The actual underlying math of the library is easier with scale than it is with precision. So, for instance, with a scale of 3, the minimum meaningful difference between two values is 0.001, so you can simply continue your calculation until the calculated error is less than this value. Fortunately, using libraries means that these underlying mathematical implementations do not need to be struggled with in whatever PHP implementation we do for either. 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. The best we can do at the moment is probably reference Rudi's implementation in ext-decimal. 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. PHP at the moment is not a language that has many applications in these spaces, with most of the actual use cases being money. My view is that this is driven by the language features, not because PHP is ill-suited to these applications or that developers using PHP have no applications that would benefit from these other capabilities. There are an array of features that are available readily in Python that are heavily used for these sorts of applications that PHP lacks, however PHP offers several things that might make it the more attractive option if it had similar mathematical features. PHP is, in general, faster than Python and more performant in the areas where the language is being used directly. However, Python allows direct access to some very low level capabilities that are implemented directly in C, and in those areas it certainly has an edge. For instance, Python has modules that allow for direct off-loading to GPUs. It has an extensive and performant set of mathematical libraries in NumPy and SciPy that make interacting with complex mathematics seamless and fast. PHP actually also has an extension to allow off-loading to a GPU, though even with extensions it has very little mathematical library support. The ext-decimal extension is probably the best example, and it has almost nothing beyond basic arithmetic. Python also has userspace operator overloading for its objects, which are extremely useful for all of these spaces, but that's an entirely different discussion than what we are talking about here. 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. This is, essentially, the thesis of the research and work that I have done in the space since joining the internals mailing list. Jordan

On 2024-04-08 12:17, Arvids Godjuks wrote:

Just to clarify this point, what's the formula to convert back and forth between a decimal and two integers? Are you thinking like scientific notation: decimal = coefficient * 10^exponent. 64 bits for the exponent seems excessive, and it might be nice to have more for the coefficient but maybe that doesn't matter too much.