fix : implement_try_eval_mode_arithmetic

[coderfender]

Which issue does this PR close?

Closes #2021

Rationale for this change

PR to support Try eval mode in native . Unfortunately neither DataFusion not Arrow crates support null on overflow ops which is the desired outcome in Spark (when Eval mode is set to Try)

What changes are included in this PR?

1. New UDF called checked_arithmetic which would perform checked_add / checked_subtract/ checked_multiply over operands and wraps overflow in a NULL . (There aren't direct DataFusion options / Arrow Kernel APIs which would provide this functionality out of the box and hence the need for custom kernel + UDF based solution)
2. On the Spark side, the check to fallback to Spark when the EVAL Mode is set to Try is removed for above arithmetic ops.

How are these changes tested?

1. Implemented unit tests with various overflow edge cases (add , subtract , multiple , divide etc)

[coderfender]

Hello @andygrove , I Implemented custom arrow kernels to perform checked_add , checked_sub and checked_mul (registered as UDFS) supporting Integral types only (similar to spark's behavior) . My hope is to repeat / reuse this for other ops (in future), now that there is a framework established.

Please take a look whenever you get a chance and I can make changes (if any) to support try eval mode. Thank you very much

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 58.45%. Comparing base (f09f8af) to head (bd002fa).
⚠️ Report is 381 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #2073      +/-   ##
============================================
+ Coverage     56.12%   58.45%   +2.33%     
- Complexity      976     1253     +277     
============================================
  Files           119      143      +24     
  Lines         11743    13192    +1449     
  Branches       2251     2370     +119     
============================================
+ Hits           6591     7712    +1121     
- Misses         4012     4256     +244     
- Partials       1140     1224      +84     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[coderfender]

@andygrove ,
Here is the summary of changes :

1. Spark's Try eval mode returns NULL in case there is a computation failure. Note that this is only supported / useful when the operands are integer (Int / Long) type since overflow on Float , Double and Decimal are non deterministic and/or return Nan/ Inf.
2. Since neither data fusion nor Arrow kernels have native implementation of Spark's Try eval mode , I went ahead and implemented custom UDFs (with custom Arrow kernels) which perform checked_add, checked_sub, checked_mul , checked_div which return None when overflow occurs.
3. I also verified that div and integer_div do work with the Try mode and added tests to check all possible edge cases.
4. fail_on_overflow param is added to create_physical_expr function to fork code to call UDF based on the Eval Option selected.
5. Once this PR gets approved / merged, I will go ahead and continue to use this framework to implement the EVAL mode for other ops such as cast while also refactoring abs , modulo operations

[andygrove]

@coderfender looks like there are some clippy issues to be resolved

[andygrove]

Please remove the leading _ from the variable name now that we are using the variable

[andygrove]

Performing this match operation on every row will be expensive. It would be better to invert this and to the match once and then have a different for loop for each operation, something like this:

match op {
  "checked_add" =>
    for i in 0..len {
      ...
    }
  "checked_sub" =>
    for i in 0..len {
      ...
    }    

[andygrove]

@coderfender I took a first pass through this, and I think this is looking good 👍

[andygrove]

Maybe consider passing in the eval mode here instead of a boolean? We'll eventually need to support all three modes.

[coderfender]

Sure thats a great idea!

[coderfender]

One of the TPC-H check failed with a network exception. @andygrove could you please re trigger that workflow whenever you get a chance?
Thank you

[coderfender]

@andygrove , thank you for restarting the failed job and glad to see that the checks have all passed. Please review once you get a chance and let me know if you think we need further changes.

Thank you

[andygrove]

We may eventually want to have a specialized version of the kernel for the scalar case to avoid the overhead of creating an array from the scalar. This does not need to happen as part of this PR, though.

[coderfender]

Sure ! I will create a follow up enhancement to track changes for a scalar impl. Thank you for the feed back @andygrove .

[andygrove]

LGTM. Thanks @coderfender

[andygrove]

@coderfender could you fix the conflicts?

[coderfender]

Thank you very much for the approval @andygrove . I am going to push a fix shortly after fixing conflicts.

[coderfender]

@andygrove , There is a test failure with the below error after rebase with main branch. I am currently investigating the failure and patch a potential fix

[coderfender]

@andygrove the checks have all passed. Thank you for your approval .Please merge once you get a chance

[coderfender]

Thank you very much for merging feature branch Andy . I created a new issue to extend on these changes and support ANSI mode for above arithmetic operations : #2137 (and raised a WIP PR #2136 )