Erik Hedvall
Erik Hedvall
Exactly, this is on the latest nightly, so it's on the horizon. I probably just copy-pasted that macro, so the rule was either necessary for something else or no longer...
It should be possible to replace it, so it's more optimal. If you exclude `Rgb` from the conversion macro for `Oklab` (and vice versa) and implement it yourself, you can...
Ouch, I don't think that macro is exported. You can add `ignore` after the backticks for now: ` ```ignore `
It's not exactly what `TypeId` is typically used for, but very handy in cases like this. The compiler should also optimize out the unused branch, since it's all constant values...
Thanks a lot for looking deeper into it!
Yes and I see it's not a small error. I would of course prefer if we can keep it fully generic if possible, but `f64` could be an option if...
I see, but that's promising! I think we can go with one iteration for now, so it matches the reference, and return to it later if there's any response to...
Going with what the reference does now doesn't prevent us from improving it later. But that said, I'm also open for other workarounds. Are the reference values from the C++...
...and tests with both `f64` and `f32`, where the `f32` version has a larger error can have its `f32` error tolerance increased. That way it's still a guard against large...
Sorry, I was a bit unclear. I was referring to the expected values in the CI tests. For example these, from `okhsv::tests::blue`: ```rust assert_abs_diff_eq!(okhsv.value, 1.0, epsilon = 1e-5); assert_abs_diff_eq!(okhsv.saturation, 1.0,...