Change in type promotion introduced in Numpy 2.0. Fixes to edf.py.

[tompollard]

As discussed in #493, numpy 2.0 introduced changes to type promotion. The change is outlined at: https://numpy.org/devdocs/numpy_2_0_migration_guide.html#changes-to-numpy-data-type-promotion

Running the tests in weak_and_warn raises the following warnings:

tests/io/test_convert.py::TestEdfToWfdb::test_edf_uniform
  /Users/tompollard/projects/wfdb-python/wfdb/io/convert/edf.py:409: UserWarning: result dtype changed due to the removal of value-based promotion from NumPy. Changed from int16 to int64.
    temp_all_sigs[i].flatten() - baseline[i]

tests/io/test_convert.py::TestEdfToWfdb::test_edf_non_uniform
  /Users/tompollard/projects/wfdb-python/wfdb/io/convert/edf.py:420: UserWarning: result dtype changed due to the removal of value-based promotion from NumPy. Changed from int16 to int64.
    (temp_sig_data[start_ind:stop_ind] - baseline[i])

tests/io/test_convert.py::TestEdfToWfdb::test_edf_non_uniform
  /Users/tompollard/projects/wfdb-python/wfdb/io/convert/edf.py:414: UserWarning: result dtype changed due to the removal of value-based promotion from NumPy. Changed from int16 to int64.
    sig_data[:, i] = (temp_sig_data - baseline[i]) / adc_gain_all[i]

This pull request addresses the issue by setting temp_all_sigs and temp_sig_data to np.int64.

For reference, temp_all_sigs and temp_sig_data are initially set as np.int64:

wfdb-python/wfdb/io/convert/edf.py

Lines 402 to 404 in c6d4fd9

	temp_sig_data = np.fromfile(edf_file, dtype=np.int16)
	temp_sig_data = temp_sig_data.reshape((-1, sum(samps_per_block)))
	temp_all_sigs = np.hsplit(temp_sig_data, np.cumsum(samps_per_block)[:-1])

baseline is set to int64 here:

wfdb-python/wfdb/io/convert/edf.py

Lines 353 to 355 in c6d4fd9

	adc_gain = [float(format(a, ".12g")) for a in adc_gain_all]
	baseline = (digital_max - (physical_max * adc_gain_all) + 1).astype("int64")

[tompollard]

@bemoody this is ready for review. Please could you take a look?

[cbrnr]

This looks good 🚀!

[tompollard]

Thanks @cbrnr! I think once this is addressed, we should be good to go with #511