Skip to content

Conversation

@liyafan82
Copy link
Contributor

@github-actions
Copy link

@liyafan82 liyafan82 force-pushed the fly_0710_div branch 4 times, most recently from 7e9aede to 39f1d7d Compare July 14, 2020 10:17
@kszucs kszucs requested review from bkietz and wesm July 14, 2020 10:30
Copy link
Member

@wesm wesm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for starting this. I'm going to pull this down and make some changes per my comments

@wesm
Copy link
Member

wesm commented Jul 14, 2020

This can't be merged yet. Divide by zero in the unchecked case causes SIGFPE process crash.

We should probably return null when dividing by zero, this is what Impala does

https://github.com/apache/impala/blob/b5805de3e65fd1c7154e4169b323bb38ddc54f4f/be/src/exprs/operators-ir.cc#L60

I'm curious what other database-type systems do

@wesm
Copy link
Member

wesm commented Jul 14, 2020

cc @pitrou

@pitrou
Copy link
Member

pitrou commented Jul 14, 2020

This will wait for 2.0.

@pitrou
Copy link
Member

pitrou commented Jul 14, 2020

But, yes, I'll take a look later.

@paddyhoran
Copy link
Contributor

paddyhoran commented Jul 14, 2020

We have this implemented with SIMD (which was tricky) on the Rust side. We currently return a Result for division by zero.

@liyafan82
Copy link
Contributor Author

Thanks for starting this. I'm going to pull this down and make some changes per my comments

@wesm Thanks a lot for your effort. Your changes look much more reasonable than mine.

@liyafan82
Copy link
Contributor Author

This can't be merged yet. Divide by zero in the unchecked case causes SIGFPE process crash.

We should probably return null when dividing by zero, this is what Impala does

https://github.com/apache/impala/blob/b5805de3e65fd1c7154e4169b323bb38ddc54f4f/be/src/exprs/operators-ir.cc#L60

I'm curious what other database-type systems do

I made some initial investigations, and it shows that some systems return null upon divide by zero (e.g. Impala and Hive (https://stackoverflow.com/questions/41165708/hive-dividing-numbers-from-the-same-column)), while others returns an error (like MySQL (https://www.got-it.ai/solutions/sqlquerychat/sql-help/data-manipulation/mysql-divide-by-zero-error-querychat/) and SQL Server (https://stackoverflow.com/questions/23230041/how-to-protect-sql-statement-from-divide-by-zero-error/23230084))

Anyway, we should handle it, instead of letting the process crash.

@liyafan82 liyafan82 force-pushed the fly_0710_div branch 3 times, most recently from 7103e27 to 418e8ac Compare July 15, 2020 12:04
Copy link
Member

@nealrichardson nealrichardson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for doing this. Could you please be sure to add this function to https://github.com/apache/arrow/blob/master/docs/source/cpp/compute.rst?

@liyafan82
Copy link
Contributor Author

Thanks for doing this. Could you please be sure to add this function to https://github.com/apache/arrow/blob/master/docs/source/cpp/compute.rst?

Done. Thanks for your kind reminder.

@liyafan82 liyafan82 force-pushed the fly_0710_div branch 3 times, most recently from 3c2c8d7 to dbd6c7e Compare August 13, 2020 02:16
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
return left / right;
if (ARROW_PREDICT_FALSE(right == 0)) {
ctx->SetStatus(Status::Invalid("divide by zero"));
return 0;
}
return left / right;

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your suggestion.
According to the IEEE 754 standard, dividing by zero should be well-defined for floating point numbers. Please see, for example, https://dl.acm.org/doi/10.1145/103162.103163, page 26.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is true, but division by zero can result in SIGFPE if feenableexcept() or a hardware exception if _control87() are used. For example:

g++ -lm -xc++ - <<!
#include <fenv.h>
int main(int argc, char* argv[]) {
  feenableexcept(FE_ALL_EXCEPT);
  return static_cast<int>(1.0 / 0.0);
}
!
./a.out # abort

These are rare, so maybe we don't need to support them (or at least restrict this check to the checked division kernel), but they do represent a potential crash when dividing by 0.0. @pitrou ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say if the user really wants to enable FP exceptions process-wise, we shouldn't try to counteract them.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, I withdraw this suggestion

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please keep this table in alphabetical order.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. Thanks for your kind reminder.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you move the zero divisor mention to the body of the docstring (together with "If either argument is null...")?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. Thank you for the good suggestion.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please don't remove these checks, instead write the tests so that they don't require approximate equality checks.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have restored the checks.
I still think it makes sense to provide approx equality checks for scalar?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it does make sense.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not useful to test so many values. We know the CPU handles division properly. Instead, focus on test cases that may trigger specific behaviour:

  • empty array
  • nulls
  • zeros
  • for floating-point: infinities, perhaps not-a-number

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the good suggestion.
I have removed some test cases, and made sure the remaining cases cover the above items, with one exception: the inifinity comparisons should depend on another PR: #7826

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#7826 was merged now. Also, the tested values are still plethoric IMHO, which makes the tests less readable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot for your effort. I have added test case for infinity.
In addition, I have removed/simplified more test cases, please check if it looks good to you.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should also check what happens when the overflow checks are disabled?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When overflow checks are disabled, we get SIGFP, and the tests crash.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, we should definitly not crash on overflow. In this case, I think overflow should be detected and a dummy value be output (0 perhaps?).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds reasonable. I have updated the PR accordingly.

@liyafan82 liyafan82 force-pushed the fly_0710_div branch 3 times, most recently from cc9e3e2 to 0fed34c Compare August 17, 2020 10:12
@liyafan82 liyafan82 force-pushed the fly_0710_div branch 2 times, most recently from 15bd314 to 2b7204d Compare August 19, 2020 09:28
@liyafan82
Copy link
Contributor Author

After more experiments, I find @bkietz is right, as the test case crashed on AMD64 Ubuntu 18.04 when dividing by floating point 0.
So I have accepted his suggestions (Thank you @bkietz ).

@nealrichardson
Copy link
Member

@pitrou if you're satisfied, could you please merge?

@pitrou
Copy link
Member

pitrou commented Aug 20, 2020

I think unchecked floating point division by zero should simply return an infinite, but we can leave that for a separate JIRA.

@pitrou pitrou closed this in cb7d1c1 Aug 20, 2020
@liyafan82
Copy link
Contributor Author

I think unchecked floating point division by zero should simply return an infinite, but we can leave that for a separate JIRA.

@pitrou Thanks for your feedback, and sorry I did not take care of this problem. I will fix it up in the follow up issue.

pitrou added a commit that referenced this pull request Dec 7, 2020
As discussed in #7748 (comment), we need to compare scalars approximately in some scenarios.

Also:
* Fix comparison of same-pointer NaN values
* Fix scalar comparison result when both inputs are null (ARROW-8956)
* Fix scalar kernel result type when result is null scalar

Closes #8438 from liyafan82/fly_1012_scl

Authored-by: Antoine Pitrou <antoine@python.org>
Signed-off-by: Antoine Pitrou <antoine@python.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants