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.bany...@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 :) Especially in some >> intermediary values while performing complex calculations. I could be wrong, >> but fractional numbers limited to 64 bits sound like a bandaid. The language >> will tell users "hey, you can do something general, but if you want >> something else please don't use me at all or involve bandaids with >> extensions". My key point is not only to allow working with decimals, but >> also to make all the alternatives useless, cover their functionality by >> builtin tools, to free users from thinking about workarounds and bandaids. >> From my POV, introducing a new decimal type that does not cover the >> GMP/bcmath/ext-decimal functionality is pointless and a waste of time. > > > 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.
