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.
mir.test.shouldApproxonly 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 forshouldApprox, or other approaches.The code below fails because shouldApprox only accepts a floating point input.
The alterative, is to use
allwith a lambda, but this isn't so user-friendly and makes documented unit tests uglier.So it doesn't need
ShouldApproxto work with floating point slices, just an overload ofshouldApproxthat incorporates theall/lambda.The only reason to have an alternate version of
ShouldApproxwould be if you want to have a better error message for slices.