feat: Support float 32 and float 64 in approx_distinct

[mkleen]

Which issue does this PR close?

• Relates to Support more types for approx_distinct function #22989 but does not close it. More types are coming.

Rationale for this change

• Float32 and Float64 were not supported in approx_distinct yet.
• Float32 and Float64 can be hashed generically via create_hashesin HLLAccumulator and HllGroupsAccumulator , exactly like the string/binary types over their bit patterns.
• Float32 and Float64 don't implement Hash on their native type so they can't use NumericHLLAccumulator.

What changes are included in this PR?

• Enable HLLAccumulator and HllGroupsAccumulator to support Float32 and Float64.
• Tests for the non-grouped and grouped path as part of approx_distinct.rst and aggregate.slt.
• Benchmarks for completeness.

Are these changes tested?

Yes.

Are there any user-facing changes?

Yes, approx_distinct supports now Float32 and Float64 but no breaking changes.

[mkleen]

@Jefffrey Thanks for the review!

[alamb]

What is the usecase for doing (bitwise) distinct for floats?

[mkleen]

What is the usecase for doing (bitwise) distinct for floats?

Would bitwise distinct fundamentally different from a normal (mathematical) distinct ? My intention was to just support float types here.

[mkleen]

The corner cases for floats such as -0.0, 0.0 and NaN are handled correctly because of this #22835.

[mkleen]

Ok, from reading up on this subject this whole pr is not a good idea.

[alamb]

Ok, from reading up on this subject this whole pr is not a good idea.

I am sorry to be a wet blanket @mkleen -- and I apologize if I have wasted any of your time. Thank you for all your contributions so far. They have made the project better.

[mkleen]

Ok, from reading up on this subject this whole pr is not a good idea.

I am sorry to be a wet blanket @mkleen -- and I apologize if I have wasted any of your time. Thank you for all your contributions so far. They have made the project better.

No worries, this is for what reviews are for. Thank you for pointing out I was on the wrong track!

[2010YOUY01]

Just to make sure I have the same understanding: is the concern that it is ambiguous whether nearly contiguous float values should be treated as distinct? For example:

-- Should these be treated as distinct or equal?
3.141590, 3.141591, 3.141592

I think the +-0.0 corner cases are not the key issue here, since they only make the result differ by a small constant and can also be special-cased.

I think it is still valuable to add a comment, or improve the error message, to explain why approx_distinct does not support float types.

[alamb]

Just to make sure I have the same understanding: is the concern that it is ambiguous whether nearly contiguous float values should be treated as distinct? For example:

Yeah -- and more specifically I think the idea is that since floating point values are typically not precise (they are subject to rounding error, etc) semantically trying to say "what are the distinct set of these values that are not exact" doesn't make much sense

I think it is still valuable to add a comment, or improve the error message, to explain why approx_distinct does not support float types.

Agreed