On Sun, Apr 7, 2024 at 8:27 AM Rowan Tommins [IMSoP] <imsop....@rwec.co.uk> wrote:
> > > On 7 April 2024 15:38:04 BST, Saki Takamachi <s...@sakiot.com> wrote: > >> In other words, looking at how the efforts overlap doesn't have to mean > abandoning one of them, it can mean finding how one can benefit the other. > > > >I agree that the essence of the debate is as you say. > >However, an argument must always reach a conclusion based on its purpose, > and combining two arguments with different purposes can make it unclear how > to reach a conclusion. > > Well, that's the original question: are they actually different purposes, > from the point of view of a user? > > I just gave a concrete suggestion, which didn't involve "combining two > arguments", it involved splitting them up into three projects which all > complement each other. > > It feels like both you and Jordan feel the need to defend the work you've > put in so far, which is a shame; as a neutral party, I want to benefit from > *both* of your efforts. It really doesn't matter to me how many mailing > list threads that requires, as long as there aren't two teams making > conflicting designs for the same feature. > > Regards, > Rowan Tommins > [IMSoP] > Eh, my first reply wasn't really about defending anything. It was to inform. I have been doing small bits of work, research, and investigation into an MPDec or MPFR implementation for years, and I'm likely to continue doing my research on that regardless of whatever is discussed in this thread. Rowan, my point wasn't so much that a discussion like this one is pointless, it was that MOST of the people who actually vote on RFCs don't reply at all to internals, so a discussion like this actually does not help anyone understand the opinion of MOST of the people that actually need to be convinced. We hope the discussion is representative of the people who do not engage with it, but we don't know for sure. In any case, an alternative implementation using MPDec/MPFR probably can't be done until 9.0 at the earliest, but Saki's improvements to BCMath are ready to merge now, essentially. > Is there anything in the proposal which would actually be different if it was based on a different library Yes. BCMath uses fixed-scale, all the other libraries use fixed-precision. That is, the other libraries use a fixed number of significant digits, while BCMath uses a fixed number of digits after the decimal point. So, for instance, it would not actually be possible without manual rounding in the PHP implementation to force exactly 2 decimal digits of accuracy in the result and no more with MPDec. The idea of money, for instance, wanting exactly two digits would require the implementation to round, because something like 0.00000013 has two digits of *precision*, which is what MPDec uses, but it has 8 digits of scale which is what BCMath uses. Jordan
