[SciPy-Dev] Adding a convenient method to create ufuncs in for scipy.stats

[Joshua Wilson]

ps--if we decide to abstract out the infrastructure I'd be willing to
write the code.

On Thu, Mar 16, 2017 at 3:28 PM, Joshua Wilson
<josh.craig.wilson at gmail.com> wrote:
>> Can we abstract out the build infrastructure to a common place?
>
> This should be fairly easy to do. It could be set up so that each
> module that needs ufuncs could have a local config file (cribbed off
> of the current `FUNCS` string in `generate_ufuncs.py`).
>
> Though I also don't object to adding more functions to special.
>
> On Thu, Mar 16, 2017 at 3:14 PM, Robert Kern <robert.kern at gmail.com> wrote:
>> On Thu, Mar 16, 2017 at 12:39 PM, Warren Weckesser
>> <warren.weckesser at gmail.com> wrote:
>>>
>>> On Thu, Mar 16, 2017 at 3:19 PM, Warren Weckesser
>>> <warren.weckesser at gmail.com> wrote:
>>>>
>>>> I'm working on an update to the Frechet distribution in scipy.stats (see
>>>> https://github.com/scipy/scipy/issues/3258 and
>>>> https://github.com/scipy/scipy/pull/3275).
>>>>
>>>> Instead jumping through the "lazy_where" hoops that are required for
>>>> conditional computations, it would be much easier to create a ufunc for the
>>>> standard PDF, CDF and possibly other required functions.  Easier, that is,
>>>> if I use the ufunc generation tools that we have over in scipy.special.
>>>> Would there be any objections to this?  We already have quite a few
>>>> functions for probability distributions in scipy.special:
>>>> https://docs.scipy.org/doc/scipy/reference/special.html#raw-statistical-functions
>>>>
>>>> I wouldn't mind creating ufuncs for some of the other distributions, too.
>>>> A ufunc implementation is more efficient, simplifies the code in
>>>> scipy.stats, and automatically handles broadcasting.
>>>>
>>>> I'm bringing this up here to see if anyone has any objections to the
>>>> expansion of the statistical functions in scipy.special.
>>>>
>>>> Warren
>>>
>>> In my previous email, the heading hints at an alternative that I didn't
>>> mention in the text.  The question implied in the heading is: what do folks
>>> think about adding ufunc generation tools to scipy.stats, instead of
>>> generating the ufuncs in scipy.special.  There are a lot of conditional
>>> computations in scipy.stats that would benefit from being implemented as
>>> ufuncs, but probably don't need to be public functions.  So instead of
>>> adding more functions to scipy.special, perhaps we could add code in
>>> scipy.stats for generating ufuncs, many of which would be private.  Of
>>> course, we could just generate private ufuncs in scipy.special, and only use
>>> them in scipy.stats.
>>
>> +1 for adding additional more standard PDF/CDF functions to scipy.special as
>> needed.
>>
>> There's already precedent for putting statistics-related but not
>> distribution-related ufuncs into scipy.special, specifically for the
>> conditional operations, e.g. boxcox(). On the other hand, if the functions
>> you are thinking of would not be part of the public API, then I'd prefer to
>> implement them in scipy.stats instead of scipy.special.
>>
>> What work do you think is entailed in implementing the ufuncs in
>> scipy.stats? Is there infrastructure we need to duplicate? Can we abstract
>> out the build infrastructure to a common place? I haven't looked at the
>> build details for scipy.special in some time.
>>
>> --
>> Robert Kern
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> https://mail.scipy.org/mailman/listinfo/scipy-dev
>>