Reopened to trigger waiting tests.

Thank you for working on this.

I would describe this is more forcing an up-conversion that preventing a down conversion (as it looks like np.corrolate is preserving the types passed in) but that is neither here nor there. The current best work-around for users is to do np.asarray(data, dtype=float) before passing it in to ensure that we are working with floats all the way through.

Could you add a simple test that passing in a list of ints does not raise?

Sure thing, I will add the test case today.

Thanks for the review!

@tacaswel I wrote the test, but in one of the CI tests, it compares against the original main and fails. Am I missing something trivial here? For your reference, the permalink of the error is reproduced below:

https://dev.azure.com/matplotlib/matplotlib/_build/results?buildId=33482&view=logs&j=aa39683c-d595-5f65-0b25-75adb2a2e3f3&t=2551f7a6-26d7-58a2-495a-78f1a540557c&l=292

        if normed:
>           correls = correls / np.sqrt(np.dot(x, x) * np.dot(y, y))
E           RuntimeWarning: overflow encountered in scalar multiply

I am very confused why this is only happening on windows, but this looks like a real warning from numpy and our tests are set to fail on any warning.

Given that we are looking for "does this fail", what is the simplest (smallest) input data we can get away with using?

Alternative would be to upcast to float sooner which would likely elide the precision warning (though may still have slight imprecision due to inexact float calcs).

e.g.

    correls = np.correlate(x, y, mode="full").astype(float)

(And then keep the /=)

        if normed:
>           correls = correls / np.sqrt(np.dot(x, x) * np.dot(y, y))
E           RuntimeWarning: overflow encountered in scalar multiply

I am very confused why this is only happening on windows, but this looks like a real warning from numpy and our tests are set to fail on any warning.

Given that we are looking for "does this fail", what is the simplest (smallest) input data we can get away with using?

This may be due to the system default long in Windows vs Linux. So, trying explicit int64 now.

Looks good @abcnishant007 !

Are you comfortable squashing your commits (see https://matplotlib.org/stable/devel/development_workflow.html#rewriting-commit-history)?

Thanks for the review @tacaswell. I targeted two commits- 1 for the change and 1 for the test. I did the cleaning and squashing using rebase, but while changing the commit message of the first commit, there was a dummy merge. Now, GitHub won't let me squash that merge commit anymore.

If this is unacceptable, I can create a new pull request with exactly two commits and the same changes as this one. What do you think?

It looks like you fell into the trap of: https://matplotlib.org/devdocs/devel/development_workflow.html#pushing-with-force

You are probably [these are destructive commands, understand them before you run them!]

git reset --hard SHA_OF_COMMIT_YOU WANT
git push --force-with-lease

away from getting rid of the merge (and duplicate) commits.

Thanks for the guidance! Yes, that was the trap. Finally, I managed to fix it by:

• using reset --hard
• and then re-introducing the two commits.
• finally push with --force

Now, we have a clean commit history of two commits, one for the fix, other for the test.

tried to re-trigger CI to pick up a fix on main for the mypy error.

I think the mypy subtest issue is resolved after re-running the tests.