fix typos in crates/burn-jit/src/tests/conv2d.rs and may include bugs

[tiruka]

During development, I found some typos. This pr fixes them.

Checklist

• Confirmed that run-checks all script has been executed.
• Made sure the book is up to date with changes in this PR.

Related Issues/PRs

#2545

Changes

% typos --diff --color always
--- ./crates/burn-jit/src/tests/conv2d.rs       original
+++ ./crates/burn-jit/src/tests/conv2d.rs       fixed
@@ -130 +130 @@
-    fn nchw_to_nhwc_should_match_into_contiguos() {
+    fn nchw_to_nhwc_should_match_into_contiguous() {

Testing

After fixing it, typos --diff --color always prints nothing.

Additional Comments

This mistake was injected by the following prs.
[Optimization] Implicit gemm rewrite (#2545).
The reason I added _2 suffix is there is already exactly the same name test function.
I considered a new name based on the test content, but the test contents are also very similar, except the last argument as follows.

    #[test]
    fn nchw_to_nhwc_should_match_into_contiguous() {
        let test_device = Default::default();
        let input =
            Tensor::<TestBackend, 4>::random([4, 72, 53, 56], Distribution::Default, &test_device);

        type Float = <TestBackend as Backend>::FloatElem;

        let output = nchw_to_nhwc::<TestRuntime, Float>(input.clone().into_primitive().tensor());
        let output_ref = into_contiguous(
            input
                .clone()
                .permute([0, 2, 3, 1])
                .into_primitive()
                .tensor(),
        );

        into_data_sync::<TestRuntime, Float>(output)
            .assert_approx_eq(&into_data_sync::<TestRuntime, Float>(output_ref), 4);
    }

    #[test]
    fn nchw_to_nhwc_should_match_into_contiguous_2() {
        let test_device = Default::default();
        let input =
            Tensor::<TestBackend, 4>::random([4, 72, 53, 56], Distribution::Default, &test_device);

        type Float = <TestBackend as Backend>::FloatElem;

        let output = nchw_to_nhwc::<TestRuntime, Float>(input.clone().into_primitive().tensor());
        let output_ref = into_contiguous(
            input
                .clone()
                .permute([0, 2, 3, 1])
                .into_primitive()
                .tensor(),
        );

        into_data_sync::<TestRuntime, Float>(output)
            .assert_approx_eq(&into_data_sync::<TestRuntime, Float>(output_ref), 1); # This 1 is different.
    }

I have no idea about the test and targeted function, but it is strange even though the context and inputs are the same but the result output is different, and the tests are passed. I am worried if there are bugs.
Just deleting one test is not enough solution, so I submit a PR to rename it.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 81.86%. Comparing base (c890af8) to head (1e7081a).
Report is 3 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2581      +/-   ##
==========================================
- Coverage   81.86%   81.86%   -0.01%     
==========================================
  Files         833      833              
  Lines      106465   106449      -16     
==========================================
- Hits        87162    87146      -16     
  Misses      19303    19303              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[laggui]

I have no idea about the test and targeted function, but it is strange even though the context and inputs are the same but the result output is different, and the tests are passed. I am worried if there are bugs.
Just deleting one test is not enough solution, so I submit a PR to rename it.

Actually, deleting one of the test might be the solution 😅

As you pointed out, both tests do the exact same thing. But the equality assertion on one has more precision tolerance than the other. assert_approx_eq checks for equality up to a certain precision. The test with precision 1 is not as strict as precision 4 (up to 4 decimal points). So we could simply keep the test with precision 4.

My guess is that the duplicate was added by mistake.

[tiruka]

@laggui Thank you for your explanation. I got it. Later I will make changes to delete the latter one.