-
Notifications
You must be signed in to change notification settings - Fork 28.5k
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
[2.4] revert [SPARK-26021][SQL] replace minus zero with zero in Platform.putDouble/Float #23389
Conversation
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.
Agreed that we shouldn't make behavior change in 2.4.
Test build #100467 has finished for PR 23389 at commit
|
retest this please. |
Test build #100469 has finished for PR 23389 at 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.
+1, LGTM.
This is a clean revert of SPARK-26021 (two patches).
Merged to branch-2.4
.
…tDouble/Float This PR reverts apache#23043 and its followup apache#23265, from branch 2.4, because it has behavior changes. existing tests Closes apache#23389 from cloud-fan/revert. Authored-by: Wenchen Fan <wenchen@databricks.com> Signed-off-by: Dongjoon Hyun <dongjoon@apache.org>
…tDouble/Float This PR reverts apache#23043 and its followup apache#23265, from branch 2.4, because it has behavior changes. existing tests Closes apache#23389 from cloud-fan/revert. Authored-by: Wenchen Fan <wenchen@databricks.com> Signed-off-by: Dongjoon Hyun <dongjoon@apache.org>
On the general logic: if this is a correctness issue, then to fix it, you have to change incorrect behavior. Why would it be better to leave the correctness issue in 2.4? this is, further, a second behavior change then. Is there more context? |
@cloud-fan @dongjoon-hyun given your email thread, I'm still not clear on the logic for reverting this one. Behavior changes are needed to fix correctness problems in behavior, no? and this has introduced two behavior changes in 2.4 now. I also just don't see any comments anywhere about the reasoning, but maybe I never found the right PR. Is this also something we need to discuss? |
Thanks, @srowen . In the email thread, I don't make a judge on any of the cases. I collected and share our behavior to make a more clear communication way to encourage this kind of discussions. :)
For the following question, #23043 (comment) was @cloud-fan 's decision comment on the original PR. That was the only one I found.
I feel in the same way with you, but I also remember that we made a different decision in this type of issues. For me, this has been a political decision instead of a technical decision. And, if there was a reverting request on the old branch, we tend to accept it because we are conservative and afraid of any unknown regression and pipeline failures.
|
Right, worth discussing. Everything is a judgment call, but I'd like to understand the 'judgment'. The logic can't be: "we can't fix correctness issues because it means changing incorrect behavior to correct behavior". I assume the logic was: the behavior change causes more problems than fixing the correctness, which could be fine. My particular issue here is that this PR changed a few things, and I infer that one thing was an issue (NaN handling?) when the important correctness issue was elsewhere (0.0 vs -0.0). Wholesale reverting might be the wrong call. |
It's a tradeoff between how serious is the bug and how risky is the patch. 0.0 vs -0.0 seems a minor bug (I don't know how this bug can cause serious problems in real-world queries) and the patch is non-trivial. |
What changes were proposed in this pull request?
This PR reverts #23043 and its followup #23265, from branch 2.4, because it has behavior changes.
How was this patch tested?
existing tests