Hello all, 

As per the reasons and discussion held within this thread we will be moving forward with the deprecation `stats.threshold` unless we can find a compelling argument against it.

So please, if you have an opinion to share on this matter, feel free to respond here. Otherwise we will merge gh-4976 with the deprecation in the next three or four days, most likely.

Kind regards,
Abraham.

2015-06-25 17:51 GMT-05:00 Abraham Escalante <aeklant@gmail.com>:
I think we should move forward with the deprecation since `np.clip` pretty much covers this and as Ralf points out, the function doesn't seem to fit in `scipy.stats`.

It would make more sense for `np.clip` to be enhanced with the option to use the same value to substitute anything below and above the limits, although that would be outside the scope of this project. It may be a nice addition.

Regards,
Abraham.

2015-06-21 9:52 GMT-05:00 Ralf Gommers <ralf.gommers@gmail.com>:


On Fri, Jun 19, 2015 at 9:30 AM, Julian Taylor <jtaylor.debian@googlemail.com> wrote:
On 18.06.2015 14:27, josef.pktd@gmail.com wrote:
>
>
> On Thu, Jun 18, 2015 at 6:16 AM, Julian Taylor
> <jtaylor.debian@googlemail.com <mailto:jtaylor.debian@googlemail.com>>
> wrote:
>
>     On Wed, Jun 17, 2015 at 10:44 PM, Abraham Escalante
>     <aeklant@gmail.com <mailto:aeklant@gmail.com>> wrote:
>     > Hello all,
>     >
>     > As part of the ongoing scipy.stats improvements we are pondering the
>     > deprecation of `stats.threshold` (and its masked array counterpart:
>     > `mstats.threshold`) for the following reasons.
>     >
>     > The functionality it provides is nearly identical to `np.clip`.
>     > Its usage does not seem to be common (Ralf made a search with searchcode; it
>     > is not used in scipy as a helper function either).
>
>     I don't think those are sufficient reasons for deprecation.
>     It does fullfil a purpose as its not exactly the same np.clip, the
>     implementation is simple and maintainable and its documented well.
>     There has to be something bad or dangerous about the function to
>     warrant issuing warnings on usage.

Those are not the only possible reasons for deprecation. In this case it's a function that doesn't really fit in scipy.stats and seems to have become a public function only by accident. The goal here, like for multiple other recent deprecations, is to make scipy.stats a coherent package of statistics functions that are well documented and tested. In this case docs/tests are OK but the function simply doesn't belong in Scipy.

 
> I pretty much share the view of David, It has interesting use cases but
> it's not worth it.

I don't see the cost in keeping it, but the cost of removing it is
unknown. Just because we can't find any users does not mean they don't
exist.

You could make that argument about any deprecation.

While the Scipy deprecation policy is similar to Numpy, this kind of case is the main difference in my opinion. There's a reason Scipy still has an 0.xx version number.

Ralf

 


_______________________________________________
SciPy-Dev mailing list
SciPy-Dev@scipy.org
http://mail.scipy.org/mailman/listinfo/scipy-dev