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

Improve user-friendliness of shouldApprox for floating point slices #452

Open
jmh530 opened this issue Jan 30, 2023 · 1 comment
Open

Improve user-friendliness of shouldApprox for floating point slices #452

jmh530 opened this issue Jan 30, 2023 · 1 comment

Comments

@jmh530
Copy link
Contributor

jmh530 commented Jan 30, 2023

mir.test.shouldApprox only works with floating point numbers. This requires some workaround when working with floating point slices. Some kind of improvement in the user-friendliness would be a positive. This could include an overload for shouldApprox, or other approaches.

The code below fails because shouldApprox only accepts a floating point input.

import mir.test: shouldApprox;
import mir.ndslice.slice: sliced;

void main() {
  auto x = [1.0, 2, 3, 4];
  auto y = x.sliced;
  y.shouldApprox == y;
}

The alterative, is to use all with a lambda, but this isn't so user-friendly and makes documented unit tests uglier.

import mir.test: shouldApprox;
import mir.ndslice.slice: sliced;
import mir.algorithm.iteration: all;

void main() {
    auto x = [1.0, 2, 3, 4];
    auto y = x.sliced;
    y.all!((a, b) => a.shouldApprox == b)(y);
}

So it doesn't need ShouldApprox to work with floating point slices, just an overload of shouldApprox that incorporates the all/lambda.

The only reason to have an alternate version of ShouldApprox would be if you want to have a better error message for slices.

@jmh530
Copy link
Contributor Author

jmh530 commented Feb 9, 2023

This might be complicated to implement more generally for the different kinds of slices that could be passed to it. (e.g. with all you have to use it multiple times with (some?) 2+ dimensional slices).

Another approach would be to define a shouldApproxEqual that is basically (a, b) => a.shouldApprox == b. Since it would return a bool it would be a drop-in replacement for approxEqual with better error messages.

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

1 participant