Hi Rowan, > That's why I mentioned the two different groups of users. The scale and > rounding mode aren't there for group (a), who just want the scale to be > managed automatically; they are there for group (b), who want to guarantee a > particular result has a particular scale. The result of $a->add($b, 2, > Round::HALF_UP) will always be the same as $a->add($b)->round(Round::HALF_UP) > but is more convenient, and in some cases more efficient, since it doesn't > calculate unnecessary digits. > > Remember also the title and original aim of the RFC: add object support to > BCMath. The scale parameter is already there on the existing functions > (bcadd, bcmul, etc), so removing it on the object version would be > surprising. The rounding mode is a new feature, but there doesn't seem a good > reason not to include it everywhere as well.
Ah, I understand. There may certainly be use cases where demand specifies a scale smaller than the maximum scale in order to save computational costs. That makes sense to me. Also, considering the two groups you presented, the group that wants to control the scale is probably not going to use operator calculations, even though they could provide various options in the constructor. Unless look at the contents of objects in the calculation process using var_dump or something, can't understand the state just by looking at the code, which can lead to bugs. They probably don't like that kind of code. > Again, the aim was to match the functionality of the existing functions. It's > likely that users will migrate code written using bcdiv() to use > BCMath\Number->div() and expect it to work the same, at least when specifying > a scale. Having it behave differently by rounding up the last digit by > default seems like a bad idea. > > Thinking about the implementation, the truncation behaviour also makes sense: > the library isn't actually rounding anything, it's calculating digit by > digit, and stopping when it reaches the requested scale. > > The whole concept of rounding is something that we are adding, presumably by > passing $scale+1 to the underlying library functions. It's a nice feature to > add, but not one that should be on by default, given we're not writing the > extension from scratch. I was thinking about this today, and I think both are correct opinions on whether to set the initial value to HALF_UP or TOWARD_ZERO. It's just a matter of prioritizing whether consistency with existing behavior or consistency within a class, and they can never be met simultaneously. Therefore, I am considering adding a more detailed explanation to the RFC on this issue and taking a second vote to decide. Regards. Saki
