Re: Proposal: Arbitrary precision native scalar type

On Wed, 3 Apr 2024, Jordan LeDoux wrote: > On Mon, Mar 18, 2024 at 1:35 PM Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> > wrote: > > > > > Where things get more complicated is with *fixed-precision* decimals, > > which is what is generally wanted for something like money. What is the > > correct result of decimal(1.03, precision: 2) / 2 - decimal(0.515, 3)? > > decimal(0.51, 2)? decimal (0.52, 2)? an error? And what about decimal(10) / > > 3? > > > > If you stick to functions / methods, this is slightly less of an issue, > > because you can have decimal(1.03, 2)->dividedBy(2, RoundingMode::DOWN) == > > decimal(0.51, 2); or decimal(1.03, 2)->split(2) == [ decimal(0.52, 2), > > decimal(0.51, 2) ] Example names taken directly from the brick/money > > package. > > > > At that point, backwards compatibility is less of an issue as well: make > > the new functions convenient to use, but distinct from the existing ones > > > I came back to this discussion after my last reply on the BCMath as an > object thread, because we went through a very similar discussion there with > regard to operators. > > I think that, roughly, the fixed precision should be defined on the scalar > itself: > > 1.234_d3 > > 1.234 is the value, _d makes it a decimal type, and 3 shows that this value > has a precision of 3. (Actually, it has a SCALE of 3, since precision is > significant digits, and also includes the integer portion). But when it > comes to fixed-precision values, it should follow rules very similar to > those we discussed in the BCMath thread: Woound't it be much better to capture this complex information in an Object, and then allow operators on this? Like... Saki was pretty much suggesting with her BCMatch/Number class RFC? I can't imagine people looking at code understanding a syntax like this right away, let alone of what it all means. cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support mastodon: @derickr@phpc.social @xdebug@phpc.social