Narrow the return types of the functions in fft._helper

@Jeitan

Please describe the feature or change you would like to see:

The current return types are annoying broad, which could lead to issues with external library function signatures with too narrow input types, like matplotlib.

This was originally pointed out by @Jeitan in numpy/numpy#28076 (comment)

Not sure if it's worth a separate issue, but I think I see a typo in what I think is the test: in test\static\accept\fft.pyi, it looks like the tests for fftfreq are repeated twice, when I suspect that the second ones are supposed to be testing rfftfreq. Maybe? If I change the second ones to rfftfreq, at least basedpyright seems fine with it still.

I saw it because I thought I would take a look at this as something possibly within my grasp I could help with, but I fear I may be in over my head. It looks like the stubs for fftfreq are accepting an ArrayLike (and the tests supply an ndarray) for the 'd' parameter, when the documentation clearly states it's a scalar. Is that an implementation detail or a typo? Everywhere else in that module the ArrayLike is used appropriately. If it's a typo I could take a stab at fixing.

Not sure if it's worth a separate issue, but I think I see a typo in what I think is the test: in test\static\accept\fft.pyi, it looks like the tests for fftfreq are repeated twice, when I suspect that the second ones are supposed to be testing rfftfreq. Maybe? If I change the second ones to rfftfreq, at least basedpyright seems fine with it still.

Good catch! A PR for this is certainly welcome welcome :)

I saw it because I thought I would take a look at this as something possibly within my grasp I could help with, but I fear I may be in over my head.

Yea I took a look, and it's indeed not as easy as it looks. Array-like's are notoriously difficult to properly type, and in this case, there's also shape-typing involved. I'll work on this soon, and will ping you once I have the PR ready, in case you're interested.

It looks like the stubs for fftfreq are accepting an ArrayLike (and the tests supply an ndarray) for the 'd' parameter, when the documentation clearly states it's a scalar.

Yea the documentation is not the whole truth in this case. Because in practice it'll work with anything that's broadcastable with a 1d array of shape (n,), i.e.

>>> import numpy as np
>>> np.fft.fftfreq(4, np.linspace(.1, .2, 8).reshape(2, 4))
array([[ 0.        ,  2.1875    , -3.88888889, -1.75      ],
       [ 0.        ,  1.45833333, -2.69230769, -1.25      ]])

So if d is a scalar-like, it'll return a 1d array, and otherwise, it'll return an array with the same shape as d (s.t. np.shape(d)[-1] == n).

Yea the documentation is not the whole truth in this case. Because in practice it'll work with anything that's broadcastable with a 1d array of shape (n,), i.e.

Ah, I thought it might be something like that. I will leave it to you then because I definitely don't know the code well enough heh.

I can fix the test typo though!

I made PR #346 for the typo :-)

Navigation Menu

Repository navigation

Narrow the return types of the functions in `fft._helper` #339

Please describe the feature or change you would like to see:

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Narrow the return types of the functions in fft._helper #339

Description

Please describe the feature or change you would like to see:

Activity

Jeitan commented on Mar 20, 2025

jorenham commented on Mar 20, 2025

Jeitan commented on Mar 20, 2025

Jeitan commented on Mar 20, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Narrow the return types of the functions in `fft._helper` #339