[SciPy-Dev] changing default for median_absolute_deviation

[Ralf Gommers]

On Mon, Feb 17, 2020 at 3:37 AM Lucas Roberts <rlucas7 at vt.edu> wrote:

> Hi scipy-dev,
>
> Looking for guidance if the change warrants ignoring deprecation policy or
> if I should create a deprecation warning for existing behavior to change
> defaults in median_absolute_deviation()
>

Hi Lucas, I think you can't do either of those things. Ignoring deprecation
policy should only be done if something is a clear bug. In the absence of
that, there's no good reason to silently (or even with a warning) return a
different numerical value.

Here, the choice seems to be between leaving as is or deprecating the
function and introducing it with a different name.


> PR:
> https://github.com/scipy/scipy/pull/11431
>
> [CONTEXT]
> In this PR:
> https://github.com/scipy/scipy/pull/9637
> the median_absolute_deviation() function was added to scipy.stats
> the function takes in a scale argument that allows for a robust estimator
> of the scale (robust to outliers). The choice of scale constant assuming
> normal input data seemed reasonable to me at the time.
> However, in this PR:
> https://github.com/scipy/scipy/issues/11090
> a few thought otherwise and we came to the conclusion that the default
> scale should be 1 which would also ensure internal consistency with the
> stats.iqr() function (similar signature and functionality).
>
> I've opened a PR to change the defaults here:
> https://github.com/scipy/scipy/pull/11431
> and pinged those on the 11090 issue.
>
> [ON DEPRECATION]:
>
> [REASON FOR]
> Main reason to not follow deprecation policy are:
> 1. Following deprecation policy would maintain existing confusing behavior
> for up to 1 year from now.
> 2. Function released in 1.3.0 so somewhat new
> 3. Seems the default is confusing users and is non-obvious and
> inconsistent with iqr() default
>

(3) is the main reason to do something here probably, but skipping a
deprecation warning still isn't warranted.


> [REASON NOT]
> 1. Some users may depend on existing default
> 2. Defaults with normal scaling exist in several places (c.f. 11090 issue
> comments)
> 3. Deprecation warning needs to be done to give fair warning of the
> change.
>
> [COMMENTS]
> I haven't much experience here with deprecations, when to do it vs
> consider a defect so would appreciate any guidance.
>

Defect = incorrect behavior (rather than confusing behavior).


> If we think the deprecation cycle should follow, should I leave the PR and
> open a separate deprecation PR?
> https://github.com/scipy/scipy/pull/11431
> Alternately could revert changes and convert to a deprecation warning PR.
>

I'll comment on PR and issue in more detail.

Cheers,
Ralf



> Thanks in advance.
> --
> -Lucas
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20200308/9f484259/attachment.html>