Re: [PHP-DEV] [RFC] [Discussion] Rounding Integers as int
Hi On 9/30/23 08:26, Marc Bennewitz wrote: The deprecation would act as an information for upcoming behavior change, not classical deprecation of future removal. If the new behavior is what you want, than you don't need to change anything as a deprecation message should not break anything. At the same time people Correct, the deprecation message itself would not break anything. However when the new behavior is the behavior I desire, it would: 1. Cause noise in my logs, because the deprecation would continue to be emitted until the behavioral change is finally implemented. 2. Be confusing when working in preparing my application for future PHP versions by handling all deprecations. The only solutions would be either adding an '@' in front of every call to round, ceil, floor (which might suppress additional errors I *do* care about) or ignoring this specific deprecation within the error handler of the application after verifying that I checked all locations for correctness. There is no way for me to reliably mark only this specific deprecation as acknowledged / handled for a specific place within my code. This also extends to library developers who are already under pressure by users to make their libraries deprecation free on or before the release of a new PHP version. As the library doesn't control the error handler, they can't just ignore this specific deprecation for their library, without casting the input to float, despite being happy with the new behavior that will arrive in PHP 9. In other words, this deprecation is not really actionable to me as a developer, because I can't migrate to the new behavior on my own pace. Best regards Tim Düsterhus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Proposal to unbundle imap/pspell/oci8 extensions for PHP 8.4
On Thu, 28 Sep 2023, Jakub Zelenka wrote: > On Wed, Sep 27, 2023, 14:14 Derick Rethans wrote: > > > The ext/imap extension isn't going to disappear, it is going be > > unbundled as we can not guarantee the underlaying library is > > maintained. Not only is it no longer maintained, the original > > purveyors have removed any mention of it from their website. > > > > For most people, there will be little change here. On Debian for > > example, "php-" is used for both bundled and PECL'ed > > extensions. > > > > Although it's unlikely that it gets any maintainer so it will most > likely stop building and won't be available in the future PHP > versions. I think we should be clear about this and note that those > extensions will no longer be supported by PHP core dev team which > likely means their end at some point in the future unless someone > steps in to maintain them. I have added words describing that to the RFC. cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support Host of PHP Internals News: https://phpinternals.news mastodon: @derickr@phpc.social @xdebug@phpc.social twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [External] : [RFC} Unbundle ext/imap, ext/pspell, and ext/oci8
On Thu, 28 Sep 2023, Christopher Jones wrote: > > On 27/9/2023 11:27 pm, Derick Rethans wrote: > > Hi, > > > > after the initial introduction, here is the formal RFC to unbundle the > > imap, pspell, and oci8 extensions and move them to PECL, for PHP 8.4. > > > > https://wiki.php.net/rfc/unbundle_imap_pspell_oci8 > > A small point: the bug URL for OCI8 in the RFC includes issues for > PDO_OCI - which is not part of the RFC. Sorry, that was an oversight on my side, as I had intended (for similar reasons as ext/oci8), to also unbundle it. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Adding bcround, bcfloor and bcceil to BCMath
On Tue, Oct 3, 2023, 4:13 PM Saki Takamachi wrote: > yes, they do, as do almost all floating points implementation. > > Memory limited float values and their respective operations are still > useful in many areas, but financial values and the likes. Scaled integers > are the way for accuracy. > > > Also, side note, gmp recommends to rely on https://www.mpfr.org/ for > accurate FP operations > > > Hi > > This seems to be a floating point number with extremely high precision > compared to regular long doubles. However, as you say, even though the > accuracy is very high, errors still occur. (the error is so small that it > almost never becomes a problem.) > > By its very nature, BCMath does not introduce any errors. It is debatable > whether floating point calculations in GMP can play the role of BCMath. > so does gmp. The point made about gmp earlier is more about the sustainability of gmp vs bcmath.
Re: [PHP-DEV] [RFC] [Discussion] Adding bcround, bcfloor and bcceil to BCMath
Hi, On 03.10.23 00:48, Jorg Sowa wrote: Hello, Recently I was trying to fix and clean some of the stuff within the BCmath extension along with Girgias who helped me. I wanted to enrich this extension with similar functions that GMP contains and improve the performance, however, I went to some conclusions and stopped it. 1. BCMath extension isn't fast enough compared to other existing arbitrary precision PHP extensions. Comparison: https://php-decimal.github.io/#performance 2. BCMath doesn't have OO API and thus it may break the backward compatibility as Claude noticed. 3. GMP GNU library provides support for float numbers, however, its functionality is not exposed in the PHP extension. And BCMath doesn't provide as many functions as GMP. There was an RFC back in 2014 from Sara : https://wiki.php.net/rfc/gmp-floating-point (never put to vote) and another one from 2013 : https://wiki.php.net/rfc/gmp_number (never put to vote). Also I think to remember about a proposal to have GMP natively supported for numbers in PHP but I can't find it anymore. Kind regards, Jorg Best, Marc
Re: [PHP-DEV] [RFC] [Discussion] Rounding Integers as int
Hi, On 26.09.23 12:39, Marc Bennewitz wrote: I'd like to put a new RFC under discussion: https://wiki.php.net/rfc/integer-rounding I tried to make the RFC text a bit more clear. As I'm not a native English speaker I would be very welcome for wording suggestions and/or grammar fixes especially for the deprecation message. About the deprecation - as it's not a classical deprecation but a notice about upcoming behavior change. Would it make sense to have an additional vote, if or if not to trigger it in 8.next? Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Adding bcround, bcfloor and bcceil to BCMath
> yes, they do, as do almost all floating points implementation. > > Memory limited float values and their respective operations are still useful > in many areas, but financial values and the likes. Scaled integers are the > way for accuracy. > > > Also, side note, gmp recommends to rely on https://www.mpfr.org/ for accurate > FP operations Hi This seems to be a floating point number with extremely high precision compared to regular long doubles. However, as you say, even though the accuracy is very high, errors still occur. (the error is so small that it almost never becomes a problem.) By its very nature, BCMath does not introduce any errors. It is debatable whether floating point calculations in GMP can play the role of BCMath. Regards. Saki
Re: [PHP-DEV] [RFC] [Discussion] Adding bcround, bcfloor and bcceil to BCMath
On Tue, Oct 3, 2023, 12:25 PM Saki Takamachi wrote: > > I thought GMP was a function for integers, so I wasn't expecting that tbh. > > However, even if GMP supported floating point numbers, wouldn't it end up > having the inherent error problem of floating point numbers? > yes, they do, as do almost all floating points implementation. Memory limited float values and their respective operations are still useful in many areas, but financial values and the likes. Scaled integers are the way for accuracy. Also, side note, gmp recommends to rely on https://www.mpfr.org/ for accurate FP operations best, >
