[SciPy-dev] Please help prepare the 0.7 release notes

[Pierre GM]

On Dec 9, 2008, at 1:13 PM, josef.pktd at gmail.com wrote:
>>
>
> I don't know how many users actually knew that it was there since,
> without looking at the source, it was not visible, not imported in any
> __all__.

Ah, yes. The only advertisment was a post on the mailing list...

>
> My main concern right now was whether we should warn users, for
> example in the release notes, about possible coming changes in the
> API, if or when we try to make stats and mstats more consistent. Once
> mstats is advertised and will get more users, API cleanup will be more
> difficult.
>

We can indeed warn that it's a beta version that will stabilize in the  
next version, just like you did.


> I haven't started to compare stats and mstats more closely, but some
> improvements should be ported to the other version, e.g. quantiles and
> scoreatpercentiles, also I got one test failure in
> mstats.friedmanchisquare, that I didn't look into.





>
> I just looked briefly at mstats_basic:
> There are also many doc strings that can be ported to stats.stats, you
> even implemented an improved version of ks_twosamp. I should have
> looked there first, before making my changes.

I could have remembered and let you know... AFAIR, I checked my  
implementation w/ examples from stats books. Of course, I didn't  
document it at the time and now can't remmbr the details. (Let it be  
an example to younger generations of things not to do...)


> You chose a different
> name for the 2 sample KS test mstats.ks_twosamp versus stats.ks_2samp.

Did you put the alias ks_2samp to ks_twosamp, or did I ? Anyway, both  
should work.

>
> For the one-sided versus two-sided option you chose the terminology
> from R, alternative : {'two_sided', 'less', 'greater'} , which I
> didn't like so much, but since I made the change very recently, I will
> adjust the keyword arguments in kstest.
>
> Do we want to keep any such name differences?

Nope, the 2 methods should indeed have the same inputs. Using R's  
might make things easier for people coming from R...

>
> My time is also pretty limited right now, but, I think, we should do a
> more careful comparison before the next scipy release. But in that
> case, some indication, that the API might come under review, would be
> appropriate.


Sounds good, go for it.