Re: [PHP-DEV] Supporting object types in BCMath

2024-03-19 Thread Saki Takamachi
Hi Jordan,

> I've done a lot of performance tuning on my arbitrary precision library, and 
> will simply state for everyone here that I think the amount of development 
> effort involved in improving performance of the BCMath library is almost 
> certainly going to see a return on your effort that is not worth it. There 
> have been discussions over the last year on possibly working on bundling a 
> new arbitrary precision C library and providing something that is performant 
> enough to be generally useful in core, but that's not even at the RFC stage, 
> just investigations.
> 
> I wouldn't say that improving BCMath is a waste of time, but there is also 
> probably lower hanging fruit once you get past things like Saki has here. 
> DevEx improvements.

BCMath is slow, but currently no other extension can replace it in terms of 
computational accuracy. Therefore, I would like to advance these proposals with 
the aim of improving usability rather than improving performance.

Since we have already completed the implementation of the important processes 
when creating the prototype, we will start preparing the RFC.

Regards.

Saki

Re: [PHP-DEV] Supporting object types in BCMath

2024-03-17 Thread Jordan LeDoux
On Sun, Mar 17, 2024 at 5:05 PM Saki Takamachi  wrote:

> Hi Jordan,
>
> > Using a BCNum inside a loop is the use case, where every loop would
> result in memory allocation for a new object, as well as the overhead of
> the constructor, etc.
> >
> > Granted, only people who REALLY know what they are doing should be doing
> this. Though my library which essentially IS a wrapped for BCMath that is
> upgradeable if you install other extensions (like ext-decimal) does support
> both, I suggest using primarily immutables in my docs.
> >
> > That said, the C library itself for BCMath is insanely inefficient as
> far as arbitrary precision math goes, so I would suggest that people don't
> get their hopes up too much on the performance front.
>
> I just sent an email, and you're right about performance. Therefore, the
> point of this proposal seems to be simply to improve convenience.
>
> Regards.
>
> Saki


I've done a lot of performance tuning on my arbitrary precision library,
and will simply state for everyone here that I think the amount of
development effort involved in improving performance of the BCMath library
is almost certainly going to see a return on your effort that is not worth
it. There have been discussions over the last year on possibly working on
bundling a new arbitrary precision C library and providing something that
is performant enough to be generally useful in core, but that's not even at
the RFC stage, just investigations.

I wouldn't say that improving BCMath is a waste of time, but there is also
probably lower hanging fruit once you get past things like Saki has here.
DevEx improvements.

Jordan


Re: [PHP-DEV] Supporting object types in BCMath

2024-03-17 Thread Saki Takamachi
Hi Jordan,

> Using a BCNum inside a loop is the use case, where every loop would result in 
> memory allocation for a new object, as well as the overhead of the 
> constructor, etc.
> 
> Granted, only people who REALLY know what they are doing should be doing 
> this. Though my library which essentially IS a wrapped for BCMath that is 
> upgradeable if you install other extensions (like ext-decimal) does support 
> both, I suggest using primarily immutables in my docs.
> 
> That said, the C library itself for BCMath is insanely inefficient as far as 
> arbitrary precision math goes, so I would suggest that people don't get their 
> hopes up too much on the performance front.

I just sent an email, and you're right about performance. Therefore, the point 
of this proposal seems to be simply to improve convenience.

Regards.

Saki

Re: [PHP-DEV] Supporting object types in BCMath

2024-03-17 Thread Saki Takamachi
Hi,

I created a prototype, although it's pretty rough. It can overload operators 
and calculate not only between `BcNum` but also between `BcNum` and `int` or 
`string`.
https://github.com/php/php-src/pull/13741

I compared the execution times.

Test code:
```


Re: [PHP-DEV] Supporting object types in BCMath

2024-03-17 Thread Jordan LeDoux
On Sat, Mar 16, 2024 at 8:39 AM Saki Takamachi  wrote:

> Hi Barney,
>
> Thanks, that's what I was starting to worry about too. It seems like a
> good idea to support only immutability, as you say earlier in your proposal.
>
> Regards.
>
> Saki


Using a BCNum inside a loop is the use case, where every loop would result
in memory allocation for a new object, as well as the overhead of the
constructor, etc.

Granted, only people who REALLY know what they are doing should be doing
this. Though my library which essentially IS a wrapped for BCMath that is
upgradeable if you install other extensions (like ext-decimal) does support
both, I suggest using primarily immutables in my docs.

That said, the C library itself for BCMath is insanely inefficient as far
as arbitrary precision math goes, so I would suggest that people don't get
their hopes up too much on the performance front.

Jordan


Re: [PHP-DEV] Supporting object types in BCMath

2024-03-16 Thread Saki Takamachi
Hi Barney,

> I would suggest if you do this only supporting immutable objects, or at least 
> making immutable the default, the one with with the simpler name, and 
> reserving the mutable version specifically for when people want to use 
> mutability. The strings used with bcmath today are effectively immutable.
> 
> It's hard to see why a number should be mutable though. Users of the class 
> can always wrap an immutable up it in a mutable object if they want.
> 
> If you do have both mutable and immutable it might be worth giving the 
> methods separate names to make the distinction clearer - e.g. "add" for 
> mutable, "plus" for immutable, and maybe making the add method return void.

Thanks, that's what I was starting to worry about too. It seems like a good 
idea to support only immutability, as you say earlier in your proposal.

Regards.

Saki

Re: [PHP-DEV] Supporting object types in BCMath

2024-03-16 Thread Barney Laurance

On 16/03/2024 05:22, Saki Takamachi wrote:

Yet another idea is to also support immutable objects, like DateTime.

e.g.
```
$num1 = new BcNum('1.235');
$num1imm = new BcNumImmutable('1.235');
$num2 = new BcNum('2.001');

$num1result = $num1->add($num2);
$num1immResult = $num1imm->add($num2);
I would suggest if you do this only supporting immutable objects, or at 
least making immutable the default, the one with with the simpler name, 
and reserving the mutable version specifically for when people want to 
use mutability. The strings used with bcmath today are effectively 
immutable.


It's hard to see why a number should be mutable though. Users of the 
class can always wrap an immutable up it in a mutable object if they want.


If you do have both mutable and immutable it might be worth giving the 
methods separate names to make the distinction clearer - e.g. "add" for 
mutable, "plus" for immutable, and maybe making the add method return void.

[PHP-DEV] Supporting object types in BCMath

2024-03-15 Thread Saki Takamachi
Hi internals,

BCMath currently only has procedural functions. This is a bit unwieldy for some 
design patterns and I came up with the idea of ​​supporting object types like 
mysqli.

Yet another idea is to also support immutable objects, like DateTime.

e.g.
```
$num1 = new BcNum('1.235');
$num1imm = new BcNumImmutable('1.235');
$num2 = new BcNum('2.001');

$num1result = $num1->add($num2);
$num1immResult = $num1imm->add($num2);

$num1->getValue(); // '3.236'
$num1result->getValue(); // '3.236'

$num1imm->getValue(); // '1.235'
$num1immResult->getValue(); // '3.236'
```

The reason why the class name is not "BCNum" is because it needs to follow the 
current PHP naming convention. As an example, the class name of a PDO subclass 
has a name such as "PdoOdbc".

I look forward to your feedback.

Regards.

Saki