[SciPy-Dev] Rationale behind *_gen and *_frozen in _multivariate.py

[josef.pktd at gmail.com]

On Wed, Jul 27, 2016 at 9:26 AM, Robert Kern <robert.kern at gmail.com> wrote:
> On Wed, Jul 27, 2016 at 2:04 PM, <josef.pktd at gmail.com> wrote:
>>
>> On Wed, Jul 27, 2016 at 8:44 AM, Robert Kern <robert.kern at gmail.com>
>> wrote:
>> > On Wed, Jul 27, 2016 at 12:36 PM, <josef.pktd at gmail.com> wrote:
>
>> >> some history in the following, Evgeni knows better the recent changes
>> >>
>> >> The original implementation of the distributions was mostly
>> >> "functional". Classes are used as namespace and to make implementation
>> >> easier, but users only used a single global instance of the
>> >> distribution classes.
>> >>
>> >> Because it is only a single global instance it cannot keep state, i.e.
>> >> store intermediate results and parameters as attributes. This was a
>> >> headache and source of bugs when state spilled over in the global
>> >> instance from one use to the next.
>> >
>> > That's not quite right, I don't think. Only the multivariate
>> > distributions,
>> > which are quite new, store intermediate results. No global state was
>> > ever
>> > stored in the "unfrozen" distribution instances. Storing intermediate
>> > results were not a consideration in adding frozen distributions.
>>
>> It took me a few months to figure out why the distributions sometimes
>> produces different, i.e. wrong, results, and to fix those bugs. Using
>> attributes and state might not have been the plan, but it was and is
>> in the actual implementation.
>>
>> (And it's the source of my allergy to the possibility of stale state
>> in statsmodels.)
>
> I'm pretty sure that we had frozen distributions before you encountered
> those bugs. We didn't add frozen distributions to get rid of those bugs. We
> added them for the API reasons I described.

Frozen distributions were there when I started and there were no
specific problems with them, AFAIR.

The API reasons that you described required that a distribution stores
the parameters as attributes. So, it required to have new
instances/objects for each new set of parameters.

That sounds like adding object orientation as API convenience, while I
would have preferred to additionally drop the global instances to make
the implementation simpler and less error-prone.

Josef

>
> https://mail.scipy.org/pipermail/scipy-user/2003-October/002278.html
>
> --
> Robert Kern
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> https://mail.scipy.org/mailman/listinfo/scipy-dev
>