python-stratify
python-stratify copied to clipboard
stratify gives strange results if heights run in opposite directions
z_targ = np.array([0.0, 1.0, 2.0, 3.0, 4.0])
z_source = np.array([0., 0.5, 1.5, 2.5, 3.5, 4.5])
data_source = z_source.copy()
out = stratify.interpolate(z_targ, z_source, data_source)
print(out)
# now flip data to be interpolated
z_source = np.flip(z_source)
data_source = np.flip(data_source)
out = stratify.interpolate(z_targ, z_source, data_source)
print(out)
Gives:
[0. 1. 2. 3. 4.] [ 0. nan nan nan nan]
Either the reversed heights should raise a ValuError or (better) the input heights should be flipped internally before doing the interpolation
Thanks @nhsavage, this is a known area to the devs, so it's good to have it flagged here 👍
@nhsavage If you also flip the z_targ, then stratify works as expected
>>> z_targ = np.flip(z_targ)
>>> out = stratify.interpolate(z_targ, z_source, data_source)
>>> print(out)
[4. 3. 2. 1. 0.]
Is this a reasonable answer?
@nhsavage If you also
flipthez_targ, thenstratifyworks as expected Is this a reasonable answer?
yes I know - I have used this a workd around in my code but shouldn't stratify at least raise an exception to avoid this sort of thing happening silently?
What would you prefer happened here?
I'm guessing to at least raise an exception, but ideally perform the interpolation i.e., give the result [0. 1. 2. 3. 4.] with your flipped z_source and data_source, right?
What would you prefer happened here?
I'm guessing to at least raise an exception, but ideally perform the interpolation i.e., give the result
[0. 1. 2. 3. 4.]with your flippedz_sourceanddata_source, right?
yes that's exactly right
Thanks @nhsavage :smile:
In order to maintain a backlog of relevant issues, we automatically label them as stale after 500 days of inactivity.
If this issue is still important to you, then please comment on this issue and the stale label will be removed.
Otherwise this issue will be automatically closed in 28 days time.