this function seems confusing. I'll go back to it once I read the rest

_trim_padding was there only to cut away the outer zero-padded border from the embed=True result so that the test could compare just the inner region against the non-embedded output. I removed the helper entirely and now check the expected embedded output explicitly in the test itself :

expected = np.array(
    [
        [0.0, 0.0, 0.0, 0.0, 0.0],
        [0.0, 12.0, 21.0, 16.0, 0.0],
        [0.0, 27.0, 45.0, 33.0, 0.0],
        [0.0, 24.0, 39.0, 28.0, 0.0],
        [0.0, 0.0, 0.0, 0.0, 0.0],
    ],
    dtype=np.float64,
)

I've never seen the term "oracle" used in this meaning, nor could I find a reference for it. Where does this come from ?

https://stackoverflow.com/questions/23522166/what-is-a-test-oracle-and-what-is-it-used-for

this might me useful.

the name of the function seems a bit misleading to me. It's not a direct call precisely because it contains preliminary steps too.

Replaced it with _run_extension_with_zero_padding(...) so the name reflects the setup being done before calling the extension.

why is this the only example input with an explicit dtype ? I think it should be specified everywhere

Agreed, I made dtype=np.float64 explicit throughout the test inputs for consistency.

can you clarify, why is this behavior even expected ?

The original C implementation access the kernel in reverse indexing as :

 //see astropy/convolution/src/convolve.c  Line 315:

  for (ii = 0; ii < nkx; ++ii) {
      val = f[i_minus_wkx + ii];
      ker = g[nkx_minus_1 - ii];
      ...
  }

To be more clear:

ker = g[nkx_minus_1 - ii];

That is the flip. Instead of g[ii], it reads the kernel from the end toward the beginning(same pattern exists in 2D and 3D dimension).

This particular test case is to check if this is being done correctly in case of asymmetric kernel ([1, 2, 3] as kernel yield different output when flipped as [3, 2, 1]) .

I do not understand how this explains the test or its name. I'd appreciate clarifications

simply meaning that the direct extension should flip the (asymmetric) kernel, if it does not. that is not convolution (but correlation that slides the kernel without flipping)

please read my reply to the previous comment on this function for reference.

(perhaps i should have been clear about this whole idea in docstrings)

okay, I see that this flipping is evidently intentional within the C code, but I do not understand the nuance between convolution and correlation you're drawing. I'm absolutely not a math expert, so please educate me :) (a reference on the topic would go a long way)

Thanks for pointing that out, I was under the assumption of only 2 cases kernel flipped = convolution, and kernel not flipped = correlation, but the test should be broader than that, since it is a convolution extension, mentioning correlation is probably irrelevant here, I'll rename the function and the docstring.

update: I made the following changes to this function:

• added descriptive docstring to convey test intent clearly
• test case now checks kernel flip for 1D, 2D, and 3D
• renamed the function to reflect the behavior being tested more accurately

please see commit a76c39f and let me know if you require any further clarifications

I'm not sure exactly what "the padded coordinates" refers to.

this comment reads like you are exclusively writing the test against the existing behavior, instead of validating that the results are actually correct. Maybe the problem is only in the phrasing, but I would like to check with you first so we're clear what the actual approach is.

I agree with that, reworked the tests to move away from the Python reference helper and now use explicit expected values.

This is what I meant to suggest in my previous review: it's simpler to only pass arguments that modify the default behavior (that's what default values are for)

(please apply similar changes to all other call sites of this helper function)

Done! see commit e4f4a4c

might as well also state how it's expected to propagate; the behavior you're testing is a little bit more specific than that.

I added a simple example in docstrings if that what you meant by how, please see commit a8c3586
If you meant something else please let me know.

I did a double take here. This is misleading and relies on the test's body to modify the input.
I think it's actually preferable to hard code the actual input here.
You'll probably want to disable auto-formatting locally for a 3D literal array

Done ! please see commit 975b0ee.

Also ruff formatter would not allow to diable autoformating just for the 3D literals, nor for the @pytest.mark.parametrize decorator, so had to wrap the whole function (after formating it correctly)