Skip to content
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

Feature Request: minmax, position min/max, product, and sum #1

Open
okaneco opened this issue Jul 15, 2024 · 2 comments
Open

Feature Request: minmax, position min/max, product, and sum #1

okaneco opened this issue Jul 15, 2024 · 2 comments

Comments

@okaneco
Copy link

okaneco commented Jul 15, 2024

Thanks for working on this.

There are two other function families that I find myself re-implementing a lot that I'd like to suggest as additions to the library.

minmax and more positions

  • minmax_simd
  • position_max_simd, position_min_simd, position_minmax_simd

It'd be nice to have these done in a single pass and without needing to successively call max/min then position.

Product and sum

  • product_simd, sum_simd

These are mainly for floating point numbers. Since floating point math isn't associative, if you call product/sum then you'll get scalarized operations. You have to use your own accumulators to get vectorized operations, otherwise the slice is operated on sequentially.

If product and sum are added, it should be noted in the documentation that the results will likely not be equal to .product::<float()/.sum::<float>().

@LaihoE
Copy link
Owner

LaihoE commented Jul 15, 2024

Thanks, minmax_simd, position_max_simd, position_min_simd, position_minmax_simd all seem very reasonable and will be adding them soon.

Originally I checked "product" and "sum" with i32's and the generated code was autovectorized and completely forgot about floats. The main question is how to communicate the float behaviour. I feel like mentioning it in the docs may not be quite enough... but idk. Maybe as an optional feature?

@okaneco
Copy link
Author

okaneco commented Jul 15, 2024

Making it an opt-in optional feature makes sense to reduce unexpected/unwanted behavior for users.

I don't have any great suggestions for names, float_extras perhaps? Not particularly concerned about this.

In nightly, they've landed intrinsics which allow for behavior similar to fast-math flags for floats and labeled them f[op]_algebraic but that's subject to change. There's no short and simple way to describe these operations unfortunately.
https://doc.rust-lang.org/1.79.0/std/index.html?search=algebraic

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants