Sorry for the so late reply, but I would like to continue the
discussion on this topic.
On Tue, Dec 12, 2023 at 10:04 PM G. P. B. <george.banyard@gmail.com> wrote:
I didn't know that the strict types directive was a mistake. My intention is to be able to write clean all-decimal units of code and not break the backward compatibility. The old code should work as it was before. At the same time, there are use cases when the whole class/project should be written with decimals only. As a user, I want to do that without complex language structures and excessive typehints or explicit conversions. The all-decimal code should be as clean as it is now with floats. This is why I proposed this directive. Can you suggest something better to achieve the same?
The issue is that I don't think having arbitrary precision decimals as a core language feature is a necessity compared to rational types.
A cast from rational to float wouldn't produce a large round trip, whereas trying to figure out arbitrary precision is more difficult.
But in any case, having a declare/INI or whatever that changes the behaviour of the engine/language is not a good design choice.
How can we introduce the ability to write user code in default
decimals and at the same time keep the old way of working as it was
before, to not introduce any troubles into the existing code and not
introduce performance issues? As a user, I would like to have a
choice. When I need speed and I don't care about rounding errors, I
will use default floats. When I need precise calculations and can
sacrifice some performance, I will use default decimals. And I would
like to be able to switch between these modes selectively, not
app-wide. Just give me a choice and inform me in the documentation
about the differences and pros/cons of both types.
I'm not in the context of the core team plans regarding "strict
types". Could you share some details here? What is the current plan
regarding it? To make strict types on by default eventually? Or
something else?
If you can suggest a better way of working with fractional numbers - please do
But IMO limiting the language by 64 bits is not a good way. It is more easy to go over the limit than you may think
Again, the use cases for arbitrary precision numbers seems rather limited, and having this as an extension does not seem problematic at all.
My current issue is that there is no way to represent "small" numbers such as 0.1 or 5.8 exactly.
Arbitrary precision is a totally different ballpark, be that for integers and/or fractional values and makes everything slow, just look at Python who is *finally* investing time and money to make the most common numbers (those that fit in a machine word) not be abysmally slow.
Honestly speaking, my current pain point is that I need to work with
precise money calculations in business automation and accounting
fields. I would like to see a good tool in the PHP language to do
that. As an engineer, I understand that it should be fast enough. I
suggested mpdecimal as a good enough option. If you could suggest
something else that would fit the majority of user needs, I'm totally
for it.
How quickly you would be able to read something like this: gmp_add(gmp_mul(gmp_div(gmp_sub($value, $add), $value2, $factor, gmp_sin($value3), gmp_intval($value))) ?
This absence of intuitive readability makes the development and support difficult and it's better to choose another language. This is what I want to change and make PHP powerful enough for this kind of applications.
GMP supports operator overloading, so you do not need to write this, and as far as I see, ext/decimal *also* supports operator overloading so you can just write it using the normal arithmetic operations.
Moreover, it supports type casts so you can just do (int) $GMP instead of gmp_intval($GMP);
And it also supports using the comparisons operatos on it instead of using gmp_cmp()The only thing that is, currently, not possible to do is a cast _to_ GMP using (GMP), but maybe that's something that could be added to the engine for internal objects, but I'm not sure about this.
If GMP can be converted to a scalar builtin language type, that also
will be totally fine from my point of view.
It seems, your main motivation to have this as a language feature is to have access to operator overloading and casting behaviour, that internal objects already support.
My points are the following:
- Work with scalar numeric types when I work with numbers, not with
objects or strings mimicking numbers. I want (bool)Decimal(0) to be
equal to false, not to true because non-null objects are always true.
- Have it as a built-in language feature allowing anyone to use it
without requiring extension installation.
- Keep backward compatibility for the code that already works with
floats while introducing an option to use only the new type when
performing math operations on numbers. And being able to have two
versions of the code working in the same app.
- IDEs and static analyzers sometimes go crazy when I do math
operations or comparisons on objects.
Which diminish the cost/benefit of making the engine changes, especially if the default behaviour doesn't change and one needs to maintain effectively two different versions of PHP depending on if it is in "decimal" or "floating" mode, which raises a plethora of questions just in its own.
As a developer, I don't see an issue with having two fractional
numeric types in the language. My old code with floats is working as
usual and doesn't break. If I want to introduce precise calculations
for money/accounting/whatever using decimals, I change my code and I'm
fully responsible for its maintenance. PHP has warnings to inform
developers if they do something wrong and this is what can be used to
prevent errors in the code. The only problem here that I foresee is
the division on two ints (and some other operations I think) should
return some specific type (float or decimal) and the language needs a
mechanism to determine the intention and return the proper result
type. This is why I suggested using "declare". In other cases, if at
least one of the operands is decimal we can always return decimals.