-
Notifications
You must be signed in to change notification settings - Fork 7.9k
RFC: Add 4 new rounding modes to round() function #12056
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Add 4 new rounding modes to round() function #12056
Conversation
I personally think it looks great, but maybe an RFC is needed. |
581cc0e
to
3116fd0
Compare
This will need to be rebased for #12220 |
2e6c3e0
to
9906413
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some suggestions for the implementation to unify the use of modf
in a single location, instead of moving it into each branch. I did not check, but expect that to reduce the amount of assembly generated for this function.
NEWS
Outdated
@@ -25,6 +27,8 @@ Standard: | |||
. Partly fix GH-12143 (Incorrect round() result for 0.49999999999999994). | |||
(timwolla) | |||
. Fix GH-12252 (round(): Validate the rounding mode). (timwolla) | |||
. Added 4 new rounding modes to the round(). (Jorg Sowa) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should not be updating NEWS - this is updated by person merging the PR together with UPGRADING.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was told in my other PRs to update UPGRADING
file. So I see there are different opinions on this and I'm not sure now which should I follow.
If I update the UPGRADING file in the same PR isn't it easier for the person merging PR? This saves time for them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure who told you that but it's usually done by commiter because those files (especially NEWS) might change often so it might lead to conflicts. It's not a big issue for master only change and UPGRADING as they don't change that often but it's still usually done by commiter at the time of the commit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is easier to have the committer of the PR to update UPGRADING then push this task on the person merging the PR.
Especially as UPGRADING is only ever touched in master.
But NEWS, AFAIK, is only ever used to inform about bug fixes in patch releases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm confused what should be included in NEWS and UPGRADING. Do you think it would be useful to add little description to the header of those files?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apparently, and I've only learned this only recently, you should update both UPGRADING and NEWS.
The only case when UPGRADING is not updated is for bug fixes in release branches.
/** | ||
* @var int | ||
* @cvalue UNUM_ROUND_DOWN | ||
*/ | ||
public const ROUND_TOWARD_ZERO = UNKNOWN; | ||
/** | ||
* @var int | ||
* @cvalue UNUM_ROUND_UP | ||
*/ | ||
public const ROUND_AWAY_FROM_ZERO = UNKNOWN; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should be done in a separate follow up PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have included this change in the same RFC. Do you think I should create separate PR for this, or it's fine to keep it in this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left this in the same PR as it was accepted in the same RFC.
9c1e650
to
e364387
Compare
a03abbf
to
7acc226
Compare
Thank you for the comments. I have addressed them all. As the RFC has been approved, I'm kindly asking for the final review of the code. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implementation LGTM now. I'll likely merge at the end of the week, unless someone complains or beats me to it. Thank you!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll let @TimWolla merge this.
@jorgsowa Now merged after re-adding some original test cases (makes the diff easier to check that there are only additions and no changes), adding UPGRADING notes and slightly rephrasing NEWS. Thank you for your patience! Don't forget to update the RFC page to the “Implemented” status. |
This PR introduces fours new modes to the
round()
function:PHP_ROUND_CEILING
,PHP_ROUND_FLOOR
,PHP_ROUND_AWAY_FROM_ZERO
andPHP_ROUND_TOWARD_ZERO
.Those four modes are frequently used in accounting and are heavily requested by the PHP users. Two first comments in
round()
documentation page is about this feature and how can it currently be achieved in the userland. However if we already have 4 existing modes it's not big effort to implement next four modes which are more popular than existingPHP_ROUND_HALF_EVEN
andPHP_ROUND_HALF_ODD
and in fact completing all of the most popular rounding modes.The RFC for the change has been approved: https://wiki.php.net/rfc/new_rounding_modes_to_round_function