[FEA] min/max segmented reduce for string and decimal

[revans2]

Is your feature request related to a problem? Please describe.
This is a follow on request for #9621.

It would be really great if we could also support String and DECIMAL_32, DECIMAL_64, and DECIMAL_128 with this same API for min and max.

In the short term I am going to use the old code I had for String/DECIMAL_128 and will try to bit cast the DECIMAL_32 and DECIMAL_64 values, before and after.

[bdice]

@revans2 I discussed adding decimal support with @isVoid and we're going to work on this soon! It may or may not make the 22.04 release but we have a game plan.

Can you elaborate a bit on what you expect for string reductions? I didn't find much in the code about existing reductions for string types -- can you list (or find in the code) the reduction types you would expect to see? Thanks! 👍

[jrhemstad]

I didn't find much in the code about existing reductions for string types -- can you list (or find in the code) the reduction types you would expect to see?

Pretty much all other reductions support min/max on strings and just use the string_view::operator< function.

Typically we have to add a level of indirection and actually compute ARGMIN/ARGMAX and then perform a gather.

[isVoid]

How about decimal types? Each fixed point column is supposed to have a uniform scale. However, since the length of each segment can be different, the product of these segments may possess different scales. One way I can think of this is since output_dtype is required, we can cast them to the desired type as a post-processing step. (From which I realized the current fixed point reduction seems to have ignored output_dtype)

[revans2]

How about decimal types? Each fixed point column is supposed to have a uniform scale. However, since the length of each segment can be different, the product of these segments may possess different scales.

I care about min and max I am not concerned with product right now and min/max do not change the scale. All of these problems have been solved by groupby aggregations. If the groupby aggregation is not supported for this type, then I would not see any reason to support it for a segmented reduction. If it is supported then I would expect the result to be the same as what groupby does. Being inconsistent is a bigger problem.

[github-actions]

This issue has been labeled inactive-30d due to no recent activity in the past 30 days. Please close this issue if no further response or action is needed. Otherwise, please respond with a comment indicating any updates or changes to the original issue and/or confirm this issue still needs to be addressed. This issue will be labeled inactive-90d if there is no activity in the next 60 days.

[bdice]

A status update since this was marked as stale: #10447 will address the string min/max case. We will need another PR to address decimal types. I would probably limit the scope to min/max aggregations for now if that is enough to resolve this issue.

[github-actions]

This issue has been labeled inactive-30d due to no recent activity in the past 30 days. Please close this issue if no further response or action is needed. Otherwise, please respond with a comment indicating any updates or changes to the original issue and/or confirm this issue still needs to be addressed. This issue will be labeled inactive-90d if there is no activity in the next 60 days.