Make datatypes opt-in

[ritchie46]

Hi @jvdd I am considering adding these to polars, but given that we define our own NaN handling, I only want to expose it for integer backed data.

Could the floating points be feature gated? Polars compile times are really strained so I'd rather not include code we don't need. Let me know what you think!

[jvdd]

Hey @ritchie46, glad to hear that you are considering to include argminmax in polars!

I am certainly open to add a "float" feature (which I would include in the default features). Once PR #21 is finished this should only require adding a single line before the impl_float! macro :)

[ritchie46]

Great to hear! I will tune back in later then. 👍

[jvdd]

As #21 is +/- finished and actually concerns the NaN handling, I'm quite interested in hearing your opinion on how you believe NaNs should be handled :)

Basically, I see three options:

• (1) ignore NaNs: return index of highest / lowest non-NaN value (e.g., numpy.nanargmax)
• return NaNs:
  • (2) use Option<usize> as return type and return None (e.g., numpy.argmax)
  • (3) return index of the first NaN

Before PR #21, the only supported case was option (1) - which was the default behavior.
PR #21 changes the default behavior to option (3), and supports option (1) via the new nanargminmax function.

By quickly scanning the polars code, I believe polars complies with option (2)? Is there any reason why this option is favored over option (3)?

[jvdd]

Hey @ritchie46,

Just released v0.5.0, this release introduces the "float" feature (which is a default feature - for backwards compatibility) and also adds nan-handling (ignoring vs returning).