Re: [RFC] [Discussion] Support object type in BCMath

Hi Barney, Jordan, > I think that's a sufficiently different data type that it should be a different class (if > required), and probably a separate RFC, and for now it's better to stay closer to the existing > BCMath API. > > Developers should be prepared to accept that an arbitrary precision decimal can't > represent 1/3 exactly, just like a binary float can't represent 1/10 exactly. > Again, my experience on the issue is with the development of my own library on the issue, > however in my case I fully separated that kind of object into its own class > Fraction, and gave the kinds of operations we've been > discussing to the class Decimal. Storing numerators and denominators > for as long as possible involves a completely different set of math. For instance, you need an > algorithm to determine the Greatest Common Factor and the Least Common Multiple in such a class, > because there are a lot of places where you would need to find the smallest common denominator or > simplify the fraction. > > Abstracting between the Fraction and > Decimal so that they worked with each other honestly introduced the > most complex and inscrutable code in my entire library, so unless fractions are themselves also a > design goal of this RFC, I would recommend against it. > Having two classes Fraction and > Decimal necessitated that I had a > Number class they both extended, as there are many situations where > I would want to type-hint "anything that calculation can be done on with arbitrary > precision" instead of specifically one or the other. I also provided the > NumberInterface, DecimalInterface, > and FractionInterface, though I don't think that would be > necessary here as this is much more just a wrapper for BCMath than an extension of it. The main goal > of my library was not to act as a wrapper for BCMath, it was to EXTEND BCMath with additional > capabilities, such as trigonometric functions that have arbitrary precision, so keep that in mind > when weighing input of mine that is referencing the work I have done on this topic. The design goals > were different. Agree. I was a little too focused on precision and lost sight of the larger goal. > In my library, if the scale is unspecified, I actually set the scale to 10 OR the length of the > input string, including integer decimals, whichever is larger. Since I was designing my own library > I could do things like that as convention, and a scale of 10 is extremely fast, even with the > horrifically slow BCMath library, but covers most use cases (the overwhelmingly common of which is > exact calculation of money). > > My library handles scale using the following design. It's not necessarily correct here, as > I was designing a PHP library instead of something for core, AND my library does not have to deal > with operator overloads so I'm always working with method signatures instead, AND it's > possible that my class/method design is inferior to other alternatives, however it went: > > 1. Each number constructor allowed for an optional input scale. > 2. The input number was converted into the proper formatting from allowed input types, and then > the implicit scale is set to the total number of digits. > 3. If the input scale was provided, the determined scale is set to that value. > 4. Otherwise, the determined scale at construction is set to 10 or the implicit scale of > "number of digits", whichever is larger. > 5. The class contained the roundToScale method, which allowed > you to provide the desired scale and the rounding method, and then would set the determined scale to > that value after rounding. It contained the round method with the > same parameters to allow rounding to a specific scale without also setting the internal determined > scale at the same time. > 6. The class contained the setScale method which set the value > of the internal determined scale value to an int without mutating the value at all. > 7. All mathematical operation methods which depended on scale, (such as div or pow), allowed an > optional input scale that would be used for calculation if present. If it was not present, the > internal calculations were done by taking the higher of the determined scale between the two > operands, and then adding 2, and then the result was done by rounding using the default method of > ROUND_HALF_EVEN if no rounding method was provided. > > Again, though I have spent a lot of design time on this issue for the math library I developed, > my library did not have to deal with the RFC process for PHP or maintain consistency with the > conventions of PHP core, only with the conventions it set for itself. However, I can provide a link > to the library for reference on the issue if that would be helpful for people that are contributing > to the design aspects of this RFC. The two use cases at issue here are when the div and pow's exponent are negative values. So how about allowing only these two methods to optionally set $scale and $roundMode ? - The constructor takes only $num and always uses implicit scaling. There is no option for the user to specify an arbitrary scale. - $scale: If specified, use that value, otherwise use 10. The scale specified here is added to the scale of the left operand and used as the scale of the result. In other words, (new Number('0.01')->div('3', 2)) results in '0.0030' // scale = 2 + 2 = 4. - $roundMode: Specifies the rounding method when the result does not fit within the scale. The initial value is PHP_ROUND_TOWARD_ZERO, which matches the behavior of the BCMath function. That is, just truncate. - If lucky enough to get the result within the scale, apply the implicit scale to the result. In other words, if calculate 1 / 2, the resulting scale will be 1, even if scale is null or specify a value such as 20 for scale. - The result of a calculation with operator overloading is the same as if the option was not used when executing the method. However, I'm not sure if naming it $scale is appropriate. Also, since BCMath\Number is not made into a final class, there is a possibility of implementing an inherited class in userland. Regarding this, is it better to make the calculation method a final method, or to use a function overridden by the user when executing from the opcode? Regards. Saki