Parachute refuses a numpy integer trigger but accepts a numpy float

[thc1006]

Describe the bug

Parachute takes a numeric trigger as a deployment height, and the check is

if isinstance(trigger, (int, float)):

numpy.float64 subclasses float, so it passes. numpy.int64 and numpy.int32 subclass neither, so they fall through to

ValueError: Unable to set the trigger function for parachute 'main'.
Trigger must be a callable, a float value or one of the strings ('apogee').

The message says "a float value", and the caller did pass a number. Which numeric type it happens to be decides whether the parachute can be built.

To Reproduce

Parachute("main", cd_s=10.0, trigger=numpy.float64(800), sampling_rate=105, lag=1.5)  # fine
Parachute("main", cd_s=10.0, trigger=numpy.int64(800),   sampling_rate=105, lag=1.5)  # ValueError

int 800             accepted
float 800.0         accepted
numpy.float64(800)  accepted
numpy.int64(800)    ValueError
numpy.int32(800)    ValueError

A height read from an array, or out of a config parsed by pandas, arrives as numpy.int64 if it has no decimal point, so this is reachable without anyone reaching for a numpy scalar on purpose.

Expected behavior

A whole number is a height whichever integer type it is:

from numbers import Real

if isinstance(trigger, Real) and not isinstance(trigger, bool):

bool wants excluding either way. It is an int, so trigger=True is currently taken as a height of one metre, silently.

Additional context

Found while narrowing the matching check in #1103. I had widened the stochastic wrapper to numbers.Real and had to put it back, because accepting a type Parachute refuses only moves the failure from validation to create time. The wrapper follows this check rather than improving on it, so widening here would let both agree.

Verified on develop at 235dc6e, NumPy 2.5.1.

Signed-off-by: thc1006 84045975+thc1006@users.noreply.github.com