fix EDF export

[drammock]

The export code for EDF files was calling np.pad incorrectly, causing the channels axis to also get padded with however many extra samples were needed to make equal-sized data blocks along the time axis. Marking as draft because it's the end of the day and I haven't had time to write a test yet. This should shrink almost all exported EDF files, possibly quite significantly. EDIT: the error is self-correcting in the output, because the extra channels are never added to the exported file (there's a for-loop over the channels in the original raw). But it is a bug in that it triggers allocating an unnecessarily large intermediate array, and for me was leading to MemoryErrors when the pad value was big.

https://numpy.org/doc/stable/reference/generated/numpy.pad.html

[drammock]

This turns out to be tricky to test, because the array that is created with the padded values doesn't survive the exporting process. But here's a demonstration:

(Pdb) p pad_width
999
(Pdb) p data.shape
(4, 1001)
(Pdb) data2 = np.pad(data, (0, int(pad_width)), "edge")
(Pdb) p data2.shape
(1003, 2000)  # <----- went from 4 channels to 1003 channels

the reason it doesn't show up in the output is that there's later a loop over the channels in the original raw so the excess spurious channels (which are always at the end) are never added to the list of EDFSignals that ultimately get written to file. In lieu of a test, I've stuck a couple assert statements inline that cause the existing test_edf_padding test to fail on main.

[cbrnr]

Good catch! I didn't know that padding was applied to all axes either, but it makes sense.

[drammock]

CI fails look like they might all be due to random number generator issues?

Linux pip-pre

• assert_allclose: mne/forward/tests/test_make_forward.py::test_make_forward_dipole:721
• assert_allclose: mne/preprocessing/tests/test_fine_cal.py::test_fine_cal_systems[fil]:292
• mne/preprocessing/tests/test_maxwell.py::test_other_systems - RuntimeWarning: Estimated head radius (10.9 cm) is above the 99th percentile for adult head size
• assert median difference < tolerance: mne/simulation/tests/test_raw.py::test_simulate_raw_bem[testing_data]:398

Windows pip-pre

• mne/preprocessing/tests/test_fine_cal.py::test_compute_fine_cal[VectorView] - assert 62 < np.float64(61.578209335821576)
• mne/preprocessing/tests/test_fine_cal.py::test_fine_cal_systems[kit] - AssertionError: Shielding factor not 2.300 <= 2.275 < 2.800
  assert 2.3 <= np.float64(2.2748473564245675)
• mne/preprocessing/tests/test_fine_cal.py::test_fine_cal_systems[ctf] - RuntimeError: No usable segments found
• mne/preprocessing/tests/test_fine_cal.py::test_fine_cal_systems[fil] - AssertionError: Shielding factor not 125.000 <= 152.489 < 145.000
  assert np.float64(152.4889126829783) < 145
• mne/decoding/tests/test_search_light.py::test_search_light_basic

Locally I have NumPy 2.1.3 (currently numba forbids anything higher), but regardless I can't find anything in the NumPy changelogs from 2.1.3 onward that seems likely to affect assert_allclose or NumPy's random generators (this is the closest: numpy/numpy#28006). Needs further investigation.

[larsoner]

Often these things crop up due to some change in linalg, like an update to OpenBLAS for example. It changes slightly the results of pseudo-inversion etc. and so some tolerances are too strict. We usually just bump them as long as they aren't way out of range. These all look bumpable to me

[drammock]

Often these things crop up due to some change in linalg, like an update to OpenBLAS for example. It changes slightly the results of pseudo-inversion etc. and so some tolerances are too strict. We usually just bump them as long as they aren't way out of range. These all look bumpable to me

OK, I bumped whatever I could figure out how to bump. I suspect that these two won't actually be fixed by my changes though:

• mne/preprocessing/tests/test_maxwell.py::test_other_systems - RuntimeWarning: Estimated head radius (10.9 cm) is above the 99th percentile for adult head size (because I was unable to reproduce, I wasn't even sure which system was causing the warning)

• mne/decoding/tests/test_search_light.py::test_search_light_basic (unexpected skip: sklearn int_t / long long mismatch which AFAICT should not be happening anymore?)

[larsoner]

Okay I think the differences are due to changes in fmin_cobyla actually. In theory the results should now be more accurate, but it does mean that some of our checks will need to change a bit

[larsoner]

... I'll merge this one as-is and then open a separate PR for the cobyla stuff.

[larsoner]

Thanks @drammock !