feat(rust): add decimal chunked comparison support

[joe-stifler]

I noticed that there is no comparison support for the Decimal(precision, scale) chunked. So this PR adds that.

Changes:

• Implement ChunkCompare for DecimalChunked.
• Only decimals with the same precision and scale are valid for comparison.

[joe-stifler]

First contribution... and I've been using polars only as a user. So apologies for any misconceptions.

[orlp]

I think this implementation is incorrect when the scale and precision are not equal.

[joe-stifler]

I think this implementation is incorrect when the scale and precision are not equal.

@orlp thanks for the comment. I agree with you. Requiring both decimals to have the same precision and scale is unnecessarily restrictive. After all, we have fixed-point data. But two notes regarding that:

1. The restriction of comparing only decimals with the same precision and scale happens in the arrow2 library. So maybe we should fix this restriction there, not here?

2. I decided not to tackle this restriction here to be consistent with the behavior of the arithmetic operations. From the following screenshot, you can see that we get errors when we try to add two decimals with different precision, even though the results don't overflow.

In summary, I'd be inclined to add the proper comparison between decimals of different precision/scale in the arrow2 library, as the comparison is applied there. But if this is not a good idea, I can try to also coerce_lhs_rhs to decimals with compatible types, although this opens some room for other issues (we need to rescale one of the decimals, or both, to a proper precision/scale that avoids overflow).

In any case, if you prefer to have this restriction for now, I'd like to return an error when precision/scale mismatch: Arrays must have the same precision and scale. In the end, this restriction, although not ideal, should already allow comparisons between decimals.

Please, let me know your thoughts regarding that.

[orlp]

I believe our intention is to rely less and less on arrow2 for computation. Perhaps @ritchie46 can chime in?

[ritchie46]

I believe our intention is to rely less and less on arrow2 for computation. Perhaps @ritchie46 can chime in?

Yes, that should all be handled in polars.

[stinodego]

Ref #12118

Thanks for the initiative on this issue. For now, I will close this PR as it hasn't been updated in a while, and the implementation is not complete. Plus it lacks tests implemented on the Python side.

If you want to pick this back up, feel free to rebase and re-open this PR to continue working on it. The issue is still very much relevant.