Skip to content

copysign/signum/whatever to differentiate ±0.0? #22660

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
XeCycle opened this issue May 8, 2025 · 3 comments
Closed

copysign/signum/whatever to differentiate ±0.0? #22660

XeCycle opened this issue May 8, 2025 · 3 comments
Labels
enhancement New feature or an improvement of an existing feature

Comments

@XeCycle
Copy link
Contributor

XeCycle commented May 8, 2025

Description

Currently we have sign() which is the same as numpy.sign, in that it converts 0.0 and -0.0 to 0.0. In the absence of copysign I failed to find any tools to differentiate 0.0 and -0.0, unless I take that series and call numpy.copysign on it. Can we have expr.copysign(expr) so that I can polars.lit(1).copysign(polars.col("c"))?

@XeCycle XeCycle added the enhancement New feature or an improvement of an existing feature label May 8, 2025
@orlp
Copy link
Member

orlp commented May 8, 2025

Polars doesn't respect the difference between 0.0 and -0.0 in general in its data model: https://docs.pola.rs/user-guide/concepts/data-types-and-structures/#floating-point-numbers.

Why do you want this?

@XeCycle
Copy link
Contributor Author

XeCycle commented May 8, 2025

These values may be parsed from feather/parquet/whatever; in an IPC application using arrow streaming format, if this sign bit can be used to mark two different cases, I can drop a boolean column and thus reduce memory usage and/or IO transfers. I agree that's not a good design, and it isn't usually useful but IMO it doesn't hurt to include it?

@orlp
Copy link
Member

orlp commented May 8, 2025

I don't think that's a good enough reason, sorry. And as mentioned before, we don't actually respect the sign bit for zeroes/NaNs in Polars and may drop it arbitrarily, so your idea wouldn't work robustly in Polars either.

@orlp orlp closed this as not planned Won't fix, can't repro, duplicate, stale May 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or an improvement of an existing feature
Projects
None yet
Development

No branches or pull requests

2 participants