On Mon, Feb 17, 2020 at 3:37 AM Lucas Roberts <rlucas7@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@python.org https://mail.python.org/mailman/listinfo/scipy-dev