# [RFC] Config setting to force all math operations to pass through BCMath library. - Thread: https://externals.io/message/58681 - Original archive: https://news-web.php.net/php.internals/58681 - Started by Michael Morris on 2012-03-06T21:03:59+00:00 - Messages: 25 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #58681 — Michael Morris — 2012-03-06T21:03:59+00:00 URL: https://externals.io/message/58681#58681 https://wiki.php.net/rfc/php_ini_bcmath_default This is the only other RFC I've been rummaging around in my head but hadn't brought up. --- ## #58684 — Anthony Ferrara — 2012-03-06T21:18:42+00:00 URL: https://externals.io/message/58681#58684 · In reply to: #58681 I initially like the concept (arbitrary precision operations). But please don't add another ini setting. Especially one where *logic* can change depending on the setting. I don't want a case where pow(2, 65)-1 will return different answers depending on the ini. That's just asking for problems. Instead, perhaps a pythonic approach may be useful (storing as int/float for small values, but auto-converting to arbitrary precision if the int/float can't exactly represent what was requested/computed)... Just a thought to make it useful without the ini complexity or performance hits. Although this will present a significant BC break (internally, zend engine wise), so it would probably be limited to a major release anyway... Just a thought... Anthony > https://wiki.php.net/rfc/php_ini_bcmath_default > > This is the only other RFC I've been rummaging around in my head but > hadn't brought up. --- ## #58685 — Michael Morris — 2012-03-06T21:22:09+00:00 URL: https://externals.io/message/58681#58685 · In reply to: #58684 > I initially like the concept (arbitrary precision operations). > > But please don't add another ini setting.  Especially one where > *logic* can change depending on the setting.  I don't want a case > where pow(2, 65)-1 will return different answers depending on the ini. >  That's just asking for problems. I edited the RFC while you were sending this for clarification. This setting would only affect the math operators (+,/,*,-) mapping them to their bcmath equivalents. Math functions like pow would not be affected. > > Instead, perhaps a pythonic approach may be useful (storing as > int/float for small values, but auto-converting to arbitrary precision > if the int/float can't exactly represent what was > requested/computed)...  Just a thought to make it useful without the > ini complexity or performance hits. > > Although this will present a significant BC break (internally, zend > engine wise), so it would probably be limited to a major release > anyway... > With a setting there would be no BC break since, if you turn it on, presumably you want it on. Also, for scripts where the author wasn't aware of the peril of floating point math the setting could actually fix their existing code. --- ## #58687 — Anthony Ferrara — 2012-03-06T21:31:29+00:00 URL: https://externals.io/message/58681#58687 · In reply to: #58685 > > […] > > I edited the RFC while you were sending this for clarification. This > setting would only affect the math operators (+,/,*,-) mapping them to > their bcmath equivalents.  Math functions like pow would not be > affected. Actually, I see that as even worse. Why would 2 * 4 be possible to be different from pow(2, 3)? That doesn't really make sense (to me). I think if it was added, all of the math related extensions would need to be (should be) updated as suits. Otherwise it's just another random inconsistency... > > […] > > With a setting there would be no BC break since, if you turn it on, > presumably you want it on.  Also, for scripts where the author wasn't > aware of the peril of floating point math the setting could actually > fix their existing code. When I said BC break, I'm talking about at the engine level. So all 3pd code that hooks into the engine (PECL extensions mainly) would be broken, as the structure of the ZVal would need to change to accommodate the bignum representation... --- ## #58688 — Michael Morris — 2012-03-06T21:37:36+00:00 URL: https://externals.io/message/58681#58688 · In reply to: #58687 > > Actually, I see that as even worse.  Why would 2 * 4 be possible to be > different from pow(2, 3)?  That doesn't really make sense (to me).  I > think if it was added, all of the math related extensions would need > to be (should be) updated as suits.  Otherwise it's just another > random inconsistency... The problem is that not all the math functions have BCmath equivalents. Bit of scope creep here if that is to be done. > > > When I said BC break, I'm talking about at the engine level.  So all > 3pd code that hooks into the engine (PECL extensions mainly) would be > broken, as the structure of the ZVal would need to change to > accommodate the bignum representation... BCMath returns the value as a string. I don't know what the ramification of that inside the engine is, but numbers end up being held as strings when this is active. I'm not trying to make light of these problems - they are significant. But PHP's current behavior is, to a non-cs major, not intuitive. I've progressed in my career to where I personally aren't bothered by this problem, but there are a lot of beginning scripters that can be caught with this. --- ## #58690 — Tomas Kuliavas — 2012-03-06T21:47:46+00:00 URL: https://externals.io/message/58681#58690 · In reply to: #58681 2012.03.06 23:03 Michael Morris rašė: > https://wiki.php.net/rfc/php_ini_bcmath_default > > This is the only other RFC I've been rummaging around in my head but > hadn't brought up. PHP has something similar with mbstring function overloading. If people use both string and mbstring functions, they can no longer trust string functions. mbstring function overloading makes string functions unreliable. Functions, that are not charset aware by default, can start operating in different charset with a single flip in interpreter config. First you start cursing, then you have to implement workarounds to deal with features designed for people, who want to use different functions without changing a single line in their code. You are asking to do same thing in math functions. If you want to use bcmath, use bcmath in your code. -- Tomas --- ## #58692 — Pierre Joye — 2012-03-06T22:02:38+00:00 URL: https://externals.io/message/58681#58692 · In reply to: #58681 hi Michael, Nice idea but technically impossible to implement without massive performance loss. There was an idea to actually replace the math ops with MPIR implementation, but tightly integrated. That's something that could be very good to have. However it is a huge task. Cheers, > https://wiki.php.net/rfc/php_ini_bcmath_default > > This is the only other RFC I've been rummaging around in my head but > hadn't brought up. > > -- > > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #58693 — Daniel Macedo — 2012-03-06T22:03:11+00:00 URL: https://externals.io/message/58681#58693 · In reply to: #58688 Michael, I'm with Anthony, in that you shouldn't change behaviour of this nature with an ini setting. I would bring more pain than what it takes away. This is one of those gotchas that everyone comes across, like you noted. The main issue is that floating point arithmetic != real number arithmetic; and bc functions do solve the issue, but make for some ugly code in complex operations... Since Anthony mentioned Python, maybe the discussion should be if PHP should/could support decimal like Python does http://docs.python.org/library/decimal Now that would be something interesting to see discussed!! --- ## #58694 — Michael Morris — 2012-03-06T22:05:02+00:00 URL: https://externals.io/message/58681#58694 · In reply to: #58690 On Tue, Mar 6, 2012 at 4:47 PM, Tomas Kuliavas wrote: > 2012.03.06 23:03 Michael Morris rašė: > > […] > > PHP has something similar with mbstring function overloading. If people > use both string and mbstring functions, they can no longer trust string > functions. mbstring function overloading makes string functions > unreliable. Functions, that are not charset aware by default, can start > operating in different charset with a single flip in interpreter config. > First you start cursing, then you have to implement workarounds to deal > with features designed for people, who want to use different functions > without changing a single line in their code. You are asking to do same > thing in math functions. No, I am not. This RFC involves the operators, not the functions. Addition, division, multiplication, subtraction. The PHP math functions will behave as they always have. > > If you want to use bcmath, use bcmath in your code. I do use it. It's a pain in the ass to read because you have to LISP nest all the operations. You can't tell me this is easy or intuitive to read... bcadd( bcsub( $bill['penalty'], $bill['rounding'], 2),bcmul( $bill['taxdue'], bcmul( $penalty, $monthsAhead, 2 ), 2 ), 2 ) Compared to $bill['penalty'] - $bill['rounding'] + $bill['taxdue'] * $penalty * $monthsAhead; You can do it, but it's eye bleeding. --- ## #58696 — Daniel Macedo — 2012-03-06T22:12:49+00:00 URL: https://externals.io/message/58681#58696 · In reply to: #58694 > I do use it.  It's a pain in the ass to read because you have to LISP > nest all the operations.  You can't tell me this is easy or intuitive > to read... > > bcadd( bcsub( $bill['penalty'], $bill['rounding'], 2),bcmul( > $bill['taxdue'], bcmul( $penalty, $monthsAhead, 2 ), 2 ), 2 ) > > Compared to > > $bill['penalty'] - $bill['rounding'] + $bill['taxdue'] * $penalty * > $monthsAhead; > > You can do it, but it's eye bleeding. I agree with you, how about having the bcmath extension support a more general (and even better, non-BC-breaking) function supporting the order of math operations (and maybe even math functions)... Something like a bc(string $operations [, int $scale = 2]) Supporting passing: bc("(29.99 + $a) * $b - pow(10, $c) / 2"); Came across something like that in the manual: http://php.net/ref.bc#107014 How's that for a quick 'n dirty idea to solve this issue? ~ Daniel Macedo --- ## #58697 — Tom Boutell — 2012-03-06T22:41:55+00:00 URL: https://externals.io/message/58681#58697 · In reply to: #58696 Excellent idea. bcmath is already not the highest performance thing in the world, so adding a function that parses a more reasonable looking expression would not be an unacceptable compromise for most. It also doesn't give you the false impression that since operators do the right thing functions are going to do the right thing too. That's very muddy and confusing. > > > […] > > I agree with you, how about having the bcmath extension support a more > general (and even better, non-BC-breaking) function supporting the > order of math operations (and maybe even math functions)... Something > like a bc(string $operations [, int $scale = 2]) > > Supporting passing: bc("(29.99 + $a) * $b - pow(10, $c) / 2"); > > Came across something like that in the manual: http://php.net/ref.bc#107014 > How's that for a quick 'n dirty idea to solve this issue? > > ~ Daniel Macedo > > -- > > > -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com --- ## #58698 — Derick Rethans — 2012-03-06T22:43:07+00:00 URL: https://externals.io/message/58681#58698 · In reply to: #58681 > https://wiki.php.net/rfc/php_ini_bcmath_default > > This is the only other RFC I've been rummaging around in my head but > hadn't brought up. I know Scott has/had a patch for a special big num type that uses bcmath. But don't know what's the status. Scott? cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #58703 — Kris Craig — 2012-03-06T23:25:24+00:00 URL: https://externals.io/message/58681#58703 · In reply to: #58698 Do we have any solid data on the performance difference between arithmetic operations with bcmath and without? To me, that would be immensely helpful in framing this. I like the idea, but the potential performance drag concerns me. Knowing exactly how big a drag we're looking at would make it easier to put this into some sort of context IMHO. --Kris --- ## #58723 — Pierre Joye — 2012-03-07T08:58:08+00:00 URL: https://externals.io/message/58681#58723 · In reply to: #58698 he was using mpir. The idea was based on a plan I discussed with him to add large integers support transparently to php. Not sure either what's the status :) > > > > […] > > I know Scott has/had a patch for a special big num type that uses > bcmath. But don't know what's the status. Scott? > > cheers, > Derick > > -- > http://derickrethans.nl | http://xdebug.org > Like Xdebug? Consider a donation: http://xdebug.org/donate.php > twitter: @derickr and @xdebug > > -- > > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #58728 — Derick Rethans — 2012-03-07T10:05:33+00:00 URL: https://externals.io/message/58681#58728 · In reply to: #58723 Pierre, The mailinglist guidelines also are for you, so let me repeat what I wrote yesterday: > Please read > "http://ch2.php.net/reST/php-src/trunk_README.MAILINGLIST_RULES" which > states: > > "3. Do not top post. Place your answer underneath anyone you wish to > quote and remove any previous comment that is not relevant to your > post." > > For more information on how to quote properly on mailinglists: > > http://www.netmeister.org/news/learn2quote.html cheers, Derick --- ## #58729 — Pierre Joye — 2012-03-07T10:12:17+00:00 URL: https://externals.io/message/58681#58729 · In reply to: #58728 > The mailinglist guidelines also are for you, so let me repeat what I > wrote yesterday: To write a one line reply to another one line reply is just fine. Make us all a favour, don't waste even more bandwidth and use a mail client that can deal with that, thanks :) Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #58730 — Peter Cowburn — 2012-03-07T10:20:18+00:00 URL: https://externals.io/message/58681#58730 · In reply to: #58729 Hi Pierre, The length of the reply being replied > > > to is irrelevant. The length of the reply is also > > […] > irrelevant. Derick's point (unless I'm mistaken) was to remind everyone of the accepted etiquette. > > To write a one line reply to another one line reply is just fine. > > Make us all a favour, don't waste even more bandwidth and use a mail > client that can deal with that, thanks :) > Cheers, > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org > > -- > > > > Top posting puts the reply out of context. Which greatly distracts from the readability of a thread, particularly when several sub-conversations happen within the larger thread. P.S. Just to be safe, I have top, middle and bottom posted this reply and included the entire contents of all of the earlier posts in the thread. --- ## #58731 — Lester Caine — 2012-03-07T10:28:13+00:00 URL: https://externals.io/message/58681#58731 · In reply to: #58729 Pierre Joye wrote: > > […] > To write a one line reply to another one line reply is just fine. So why include all the rest of the crap as well ... THAT is the waste of bandwidth, and a pain to deal with what ever client one is using. The bulk of your previous quoting was totally unnecessary and on some threads several pages of 'sigs and adverts' is what we are moaning about, so please set an example to others. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #58732 — Pierre Joye — 2012-03-07T10:31:59+00:00 URL: https://externals.io/message/58681#58732 · In reply to: #58730 The only fact that this reminder ended in such a discussion pretty much makes my point. Most of the times I do clean out before replying, but I really do not need mailing list police and certainly not willing to argue even more about this topic, read: I have other things to do that to deal with such discussions :) Cheers, --- ## #58741 — Reindl Harald — 2012-03-07T13:38:36+00:00 URL: https://externals.io/message/58681#58741 · In reply to: #58729 Am 07.03.2012 11:12, schrieb Pierre Joye: > > > > […] > > To write a one line reply to another one line reply is just fine. > > Make us all a favour, don't waste even more bandwidth and use a mail > client that can deal with that, thanks :) why do you not understand the simple fact that NO CLIENT can fix this, not now and not in the future - answer 4 - answer 2 - initial post - answer 1 - answer 3 should i draw you a picture for help? --- ## #58742 — Marco Tabini — 2012-03-07T13:40:49+00:00 URL: https://externals.io/message/58681#58742 · In reply to: #58741 > should i draw you a picture for help? Yes, but please make sure that it is on 24# cream paper. And draw in charcoal, because professionals don't use pencils. --- ## #58747 — Sebastian Bergmann — 2012-03-07T18:31:39+00:00 URL: https://externals.io/message/58681#58747 · In reply to: #58728 Am 07.03.2012 11:05, schrieb Derick Rethans: > > […] Couldn't agree more, such quoting is really annoying. While we are at the topic of etiquette: please use your realname when posting to this list. Thanks! -- Sebastian Bergmann Co-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ --- ## #58750 — Kris Craig — 2012-03-07T18:53:44+00:00 URL: https://externals.io/message/58681#58750 · In reply to: #58747 On Wed, Mar 7, 2012 at 10:31 AM, Sebastian Bergmann wrote: > Am 07.03.2012 11:05, schrieb Derick Rethans: > > […] > > Couldn't agree more, such quoting is really annoying. While we are at > the topic of etiquette: please use your realname when posting to this > list. Thanks! > > -- > Sebastian Bergmann Co-Founder and Principal Consultant > http://sebastian-bergmann.de/ http://thePHP.cc/ > > -- > > > > You guys make a valid point, but I think Pierre does as well. Creating a stink over a quick one-liner reply seems a bit excessive IMHO. If this is really such a problem, we need to try and think of a solution other than just "policing," which obviously hasn't worked. Just my five cents (damn inflation!). --Kris --- ## #58753 — Derick Rethans — 2012-03-07T19:07:27+00:00 URL: https://externals.io/message/58681#58753 · In reply to: #58750 > On Wed, Mar 7, 2012 at 10:31 AM, Sebastian Bergmann wrote: > > > […] This bit is not needed, so trim it! > You guys make a valid point, but I think Pierre does as well. Creating a > stink over a quick one-liner reply seems a bit excessive IMHO. If this is > really such a problem, we need to try and think of a solution other than > just "policing," which obviously hasn't worked. Part of quoting correctly, is to trim out things you're not replying too. And remove signatures as well (any proper client does that!). Which means, everything after the "-- " + return should be removed. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #58754 — Lester Caine — 2012-03-07T20:19:52+00:00 URL: https://externals.io/message/58681#58754 · In reply to: #58753 Derick Rethans wrote: > Part of quoting correctly, is to trim out things you're not replying > too. And remove signatures as well (any proper client does that!). Which > means, everything after the "-- " + return should be removed. Exactly ... One line answers are not a problem ... they don't need any more than that :) -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php