[briangow]

As discussed in #515, an overflow can occur when calculating ADC parameters from limited-precision physical signal data. The root cause of this overflow is precision loss. When computing min/max values during parameter calculation, insufficient floating-point precision at boundaries (e.g. int32 boundaries) leads to gain/baseline values that cause digital samples to overflow by exactly 1 value.

The fix ensures float64 precision is used throughout ADC parameter calculation and conversion:

• In calc_adc_params(): Convert physical signals to float64 before computing min/max
• In adc_inplace(): Convert to float64 before performing gain/baseline arithmetic

Users can now safely provide lower-precision physical data (e.g., float32) without validation errors.

This PR includes a test for the overflow which uses the data supplied by @Ivorforce in #515. The test checks that:

• float32 input data can be written with fmt=32 without overflow
• digital values stay within the valid range
• the physical signal round-trips accurately through write/read

[tompollard]

Thanks Brian. I checked this against current main: the CSV reproduces the overflow (IndexError on channel 1), the fix resolves it, and both the min/max and adc_inplace changes are needed.

A few requests:

• Could you update the branch from main? It predates Fix ADC gain formula #551 and the recent pandas changes, so import wfdb currently fails on the branch with pandas 3.

• In calc_adc_params, we don't need to copy the full signal to float64 just to get min/max. Converting float32 to float64 doesn't change the values; what matters is that minvals/maxvals are float64, so the gain/baseline arithmetic runs in float64. Something like this gives the same result without the extra copy:

  minvals = np.nanmin(self.p_signal, axis=0).astype("float64")
  maxvals = np.nanmax(self.p_signal, axis=0).astype("float64")
  # expanded path:
  minvals.append(float(np.nanmin(ch)))
  maxvals.append(float(np.nanmax(ch)))
  
  It'd be good to update the comments to say this.

• In the non-inplace path of adc(), .copy() followed by astype("float64") now copies twice for float32 input. Passing .astype("float64") instead of .copy() would avoid that.

[tompollard]

Thanks Brian, looks great. Before we merge, could you add a changelog fragment, e.g. changelog.d/adc-float32-overflow.rst? Something like: "Fixed wrsamp failing with an out-of-range error when writing float32 physical signals, by computing ADC parameters in float64."

[briangow]

Added the changelog @tompollard , thanks.

[tompollard]

Looks good, thanks!