Johanna Sörngård
Johanna Sörngård
If this were implemented with the types in this crate I would map each row to an `EnumeratePixels(Mut)` instead of a normal slice iterator.
I think I personally would prefer that API as it would allow, as you say, the user to call either `iter` or `par_iter` on the slices, which gives more options...
I think it is a good idea to have them be consistent, since then you can just add a `par_` in front and magically have parallelism. But it also sounds...
It seems the CI fails due to issues that are unrelated to this PR?
Ah, I hadn't seen that! Very nice. Makes sense to not merge. Should I delete the PR, or is it something for the future?
I also have a project that's semi-related to this issue: I have developed an implementation of the Lambert W function: https://crates.io/crates/lambert_w. Would integrating this capability be interesting? It is `no_std`...
It is possible to specify a custom epsilon, I do it a lot in the [tests of my `lambert_w`](https://github.com/JSorngard/lambert_w/blob/ed159dcad5d0c9de33114bed09ea6a985d72466d/tests/integration_tests.rs#L76) crate. Perhaps there's some mistake?
Something interesting for this PR might be the crate [`rustversion`](https://crates.io/crates/rustversion) which can conditionally mark functions as `const` if the user is using a modern enough compiler, and leave the function...
I also face this issue with gnuplot 6.0 patchlevel 1.
This problem remains on criterion version 0.6.0.