Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121945
MIME-Version: 1.0
References: <18c42fdbb30.2831.17a3710df6d58f02ca570cc47e197a63@interi.co>
In-Reply-To: <18c42fdbb30.2831.17a3710df6d58f02ca570cc47e197a63@interi.co>
Date: Thu, 7 Dec 2023 14:36:31 +0000
Message-ID: <CAFPFaMLZ3MeGXt5OPmAkwM-n-eZcp1gT7RQCnpXSyHxZThOn2g@mail.gmail.com>
To: Alex Pravdin <alex.pravdin@interi.co>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="00000000000074bb50060bec651e"
Subject: Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type
From: george.banyard@gmail.com ("G. P. B.")

--00000000000074bb50060bec651e
Content-Type: text/plain; charset="UTF-8"

On Thu, 7 Dec 2023 at 06:36, Alex Pravdin <alex.pravdin@interi.co> wrote:

> Hello internals,
> [...]
> GMP:
> - Workaround: implements the GMP class that allows basic math operations.
> - Requires using separate functions for the rest of operations.
>
> - Objects are always casted to true, GMP(0) will equal to true.
>

This is incorrect, GMP object do _not_ support casts to bool
See https://3v4l.org/LHpD1


> It works the same as "float" in terms of its usage and type casting except
> for one thing. Float value can be passed to a decimal argument or
> typecasted with a warning like "Float to decimal conversion may incur
> unexpected results".
>
> Decimal to float conversion is allowed and smooth:
>
> function f (float $value) {}
>
> f(0.2);
>
> f(0.2d); // allowed with no warnings
>

I disagree with this part, floats can not represent decimal values properly
e.g.
$f1 = 0.1;
$f2 = 0.2;
$f3 = 0.3;
var_dump($f1 + $f2 === $f3);

will return false.
As such, floats are not at all compatible with decimals.

Moreover, the whole point of adding a warning when implicit conversions
from int to float happen was to be able to warn before elevating the
warning to a TypeError.
Therefore, introducing behaviour that warns instead of throwing a TypeError
is already a no-go from my PoV.


> [...]
>
> Literal numbers in the code are converted to floats by default. If
> prepended by the "(decimal)" typecast, the decimal result is produced
> without an intermediary float.
>

This behaviour is rather suboptimal, I'd rather have literals be decimals,
as decimals to floats should always be a reasonable implicit coercion
considering we already do int to float.


> New declare directive "default_decimal" is added. When used, literals and
> math operations return decimal by default instead of float. This is to
> simplify creating source files working with decimals only.
>

Please no, no new declare directives that affect engine behaviour.
Strict types was already a mistake because of this IMHO.


> New language construct "as_decimal()" is added to produce decimal math
> results for literals and math operations instead of float without
> intermediary float:
>
> $var = 5 / 2; // returns float 2.5
> $var = as_decimal(5 / 2); // returns decimal 2.5
>
> This is a kind of "default_decimal" for a specific operation.
>

Again, this should return a decimal instead IMHO.


> If mixed float and decimal operands are used in a math operation, decimal
> is converted to float by default. If "default_decimal" directive or
> "as_decimal()" construct is used, float is converted to decimal (with a
> warning):
>
> $f = (float) 0.2;
> $d = (decimal) 0.2;
>
> $r = $f + $d; // returns float result by default
> $r = as_decimal($f + $d); // returns decimal result with a warning about
> implicit float to decimal conversion
>
> All builtin functions that currently accept float also accept decimal. So
> users don't need to care about separate function sets, and PHP developers
> don't need to maintain separate sets of functions. If such functions get
> the decimal parameter, they return decimal. If they have more than one
> float parameter and mixed float and decimal passed, decimals converted to
> float by default. If "default_decimal" or "as_decimal" used, float is
> converted to decimal with the warning.
>

Messing with the return value type has already proved controversial.
And as I said previously, I am dead against having implicit float to
decimal conversions.
Making the functions type generic is something that I am fine, however.


> The new type uses libmpdec internally to perform decimal calculations
> (same
> as Python).
>

I really don't think we need arbitrary precision decimals.
I'm also not convinced using a floating point spec is the most sensible,
due to the rounding errors this is going to introduce.
The non-arbitrary IEEE 754-2008 specification cannot describe the decimal
123457.1467 exactly, which is frankly pointless.

Decimals, or more broadly rational numbers that, outside numerical
computations, that are going to be used are not going to need huge
denominators.

I've been thinking about this for a while, and I personally think that
rational numbers are just better than trying to support only decimals.
And considering we have 64 bits to play with for a new zval type splitting
the bits into a 32-bit unsigned integer for the numerator and an 32-bit
signed integer for the denominator should provide us with enough reasonable
rational numbers.
As any number that do not fit in this structure seems to be something
relegated to the world of numerical computation where floats are what are
mostly used anyway.


> All of the points above are subject to discussions, it is not an RFC
> candidate right now. So please share your opinions.
>
> I know that the implementation of this will require a lot of work. But I
> don't think this is a stopper from formulating the requirements.
> Sometimes,
> any project requires big changes to move forward. I'm pretty sure this
> functionality will move PHP to the next level and expand its area of
> applications. My thoughts here are mostly from the user's perspective, I'm
> not so familiar with PHP internal implementation. But I think this feature
> can be a good goal for PHP 9.
>

Yes, this is a major project, and as said above I have also thought about
adding a rational number type.
But the main hurdle for this is changing the zval structure and applying
the change everywhere to the engine and extensions.

Best regards,

Gina P. Banyard

--00000000000074bb50060bec651e--