headers
David Cournapeau | 1 Nov 04:15
Picon

Re: Renaming fftpack to fft, removing backends

On Sat, Nov 1, 2008 at 4:25 AM, Robert Kern <robert.kern <at> gmail.com> wrote:
> On Fri, Oct 31, 2008 at 11:23, Stéfan van der Walt <stefan <at> sun.ac.za> wrote:
>> 2008/10/28 Robert Kern <robert.kern <at> gmail.com>:
>>>> How: For 0.7, we could rename it while keeping scipy.fftpack as an empty
>>>> placeholder (like scipy.linsolve), and deprecating scipy.fftpack.
>>>
>>> This needs to be handled carefully. scipy.fft() already exists. It
>>
>> scipy.fft() just contributes to SciPy root pollution.  Unlike with
>> NumPy, we still have the opportunity to organise SciPy well, and I
>> don't think fft() belongs at the top level.
>
> I agree that it doesn't belong there. Personally, I would like to
> remove everything from the top-level. However, I don't particularly
> agree that we have no constraints on reorganizing scipy. With numpy we
> made a clear statement that the API was going to change up until 1.0,
> at which point we made some promises of stability. Consequently, we
> felt comfortable changing the API before 1.0 without concern for
> breaking people's code. With scipy, that's not the case. 1.0 is not
> and has never been the arbitrary dividing line between instability and
> stability for this project. scipy is installed, people are using it,
> and we have an obligation not to break their code for minor
> tidying-up.

If we have this policy, it only makes sense to follow it strictly. API
compatibility is mostly a binary thing: either we allow breakage, or
we don't. To break "a bit" is the same as breaking a lot: it means
people can't rely on it as a stable dependency. That's the part of
your argument that I don't follow, I guess.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Robert Kern | 1 Nov 04:50
Picon
Gravatar

Re: Renaming fftpack to fft, removing backends

On Fri, Oct 31, 2008 at 22:15, David Cournapeau <cournape <at> gmail.com> wrote:
> On Sat, Nov 1, 2008 at 4:25 AM, Robert Kern <robert.kern <at> gmail.com> wrote:
>> On Fri, Oct 31, 2008 at 11:23, Stéfan van der Walt <stefan <at> sun.ac.za> wrote:
>>> 2008/10/28 Robert Kern <robert.kern <at> gmail.com>:
>>>>> How: For 0.7, we could rename it while keeping scipy.fftpack as an empty
>>>>> placeholder (like scipy.linsolve), and deprecating scipy.fftpack.
>>>>
>>>> This needs to be handled carefully. scipy.fft() already exists. It
>>>
>>> scipy.fft() just contributes to SciPy root pollution.  Unlike with
>>> NumPy, we still have the opportunity to organise SciPy well, and I
>>> don't think fft() belongs at the top level.
>>
>> I agree that it doesn't belong there. Personally, I would like to
>> remove everything from the top-level. However, I don't particularly
>> agree that we have no constraints on reorganizing scipy. With numpy we
>> made a clear statement that the API was going to change up until 1.0,
>> at which point we made some promises of stability. Consequently, we
>> felt comfortable changing the API before 1.0 without concern for
>> breaking people's code. With scipy, that's not the case. 1.0 is not
>> and has never been the arbitrary dividing line between instability and
>> stability for this project. scipy is installed, people are using it,
>> and we have an obligation not to break their code for minor
>> tidying-up.
>
> If we have this policy, it only makes sense to follow it strictly. API
> compatibility is mostly a binary thing: either we allow breakage, or
> we don't. To break "a bit" is the same as breaking a lot: it means
> people can't rely on it as a stable dependency. That's the part of
> your argument that I don't follow, I guess.
(Continue reading)

Permalink | Reply | 2 comments |
headers
josef.pktd | 1 Nov 05:49
Picon

Re: Reminder: SciPy Sprint is TOMORROW (Saturday) and Sunday

I went bug hunting today and updated http://scipy.org/scipy/scipy/ticket/745

Josef
Permalink | Reply | 1 comment |
headers
David Cournapeau | 1 Nov 06:05
Picon

Re: Renaming fftpack to fft, removing backends

On Sat, Nov 1, 2008 at 12:50 PM, Robert Kern <robert.kern <at> gmail.com> wrote:
>
> For example, Python itself is a pretty good project for maintaining
> backwards compatibility. But behavior changes do happen, and
> deeply-diving codebases like Twisted do break on just about every new
> 2.x release. Because the changes are usually beneficial to a wide
> audience while the breakage is limited to small parts of libraries
> that are depending on mostly unspecified behavior, these changes are
> usually considered acceptable

Yes, but there is a difference: in python, it is clear how the
decision is made, and the decisions are motivated through a relatively
strong direction on where the project is going. Also, twisted is not
meant to be used interactively, I guess.

Scipy and numpy are two things: a library, and an interactive tool (or
at least a strong foundation for an interactive tool). For a library,
a renaming has low, if any value. Both arguments can be made, and
given than I consider you know more than I on numpy/scipy, I won't
proceed with the renaming in this precise case. But this puzzles me a
bit about what the scipy objectives are; maybe I am overstating it,
though.

>
> I don't see how it follows that taking my "middle ground" stance means
> that people won't discuss possibly-code-breaking changes they are
> making.

Sorry, that's was not clearly stated, let me rephrase it: I meant that
I feel like some changes as trivial as rename already happened before
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stéfan van der Walt | 1 Nov 14:23
Picon
Picon
Favicon

Re: Reminder: SciPy Sprint is TOMORROW (Saturday) and Sunday

Hi Josef,

2008/11/1  <josef.pktd <at> gmail.com>:
> I went bug hunting today and updated http://scipy.org/scipy/scipy/ticket/745

I'd like to merge your work on the stats module.  Will you be online
sometime so we can discuss the changes?

Cheers
Stéfan
Permalink | Reply | 0 comments |
headers
Pauli Virtanen | 1 Nov 17:09
Picon
Picon
Favicon

Trac wiki edit permissions

Hi,

Could I get permissions to edit Scipy Trac wiki pages? (Right now, it 
would be useful for the Scipy sprint.) My account there is "pv".

Thanks,

--

-- 
Pauli Virtanen
Permalink | Reply | 1 comment |
headers
G-J van Rooyen | 1 Nov 17:54
Picon

Definition of gammaln(x) for negative x

Hey everyone

Ticket #737 refers:

-----

Gamma in negative for negative x whose floor value is odd. As such,
gammaln does not make sense for those values (while staying in the
real domain, at least). scipy.special.gammaln returns bogus values:

import numpy as np
from scipy.special import gamma, gammaln
print np.log(gamma(-0.5))
print gammaln(-0.5)

Returns nan in the first case (expected) and 1.26551212348 in the
second (totally meaningless value).

-----

The info line for gammaln reads:
*  gammaln      -- Log of the absolute value of the gamma function.

With this definition of gammaln, the function actually works fine,
since np.log(abs(gamma(-0.5))) is in fact 1.2655. However, this seems
to be an unusual definition for gammaln. What is the best way to fix
it? Options:

1) Keep it as it is, with gammaln(x) = ln|gamma(x)|
2) Change it so that it returns NaN for negative values of gamma(x)
(Continue reading)

Permalink | Reply | 10 comments |
headers
Jarrod Millman | 1 Nov 18:12
Picon
Favicon
Gravatar

Re: Trac wiki edit permissions

On Sat, Nov 1, 2008 at 9:09 AM, Pauli Virtanen <pav <at> iki.fi> wrote:
> Could I get permissions to edit Scipy Trac wiki pages? (Right now, it
> would be useful for the Scipy sprint.) My account there is "pv".

You should be all set now.  Thanks for helping out and please let me
know if you need anything else.

--

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/
Permalink | Reply | 0 comments |
headers
David Cournapeau | 1 Nov 18:05
Picon
Picon

Re: Definition of gammaln(x) for negative x

G-J van Rooyen wrote:
> Hey everyone
>
> Ticket #737 refers:
>
> -----
>
> Gamma in negative for negative x whose floor value is odd. As such,
> gammaln does not make sense for those values (while staying in the
> real domain, at least). scipy.special.gammaln returns bogus values:
>
> import numpy as np
> from scipy.special import gamma, gammaln
> print np.log(gamma(-0.5))
> print gammaln(-0.5)
>
> Returns nan in the first case (expected) and 1.26551212348 in the
> second (totally meaningless value).
>
> -----
>
> The info line for gammaln reads:
> *  gammaln      -- Log of the absolute value of the gamma function.
>
> With this definition of gammaln, the function actually works fine,
> since np.log(abs(gamma(-0.5))) is in fact 1.2655.

I have just checked with R, R does define log gamma as the
log(abs(gamma(x))) (I guess that's where the definition comes from). I
find this definition a bit strange, that's not the one I have seen where
(Continue reading)

Permalink | Reply | 9 comments |
headers
G-J van Rooyen | 1 Nov 20:53
Picon

Re: Definition of gammaln(x) for negative x

I think it probably makes sense to keep it the way it is. AFAIK
gammaln is typically used to calculate products and divisions with the
gamma function, where it makes more sense to transform the entire
calculation into the log-domain, in order to prevent numerical
inaccuracies.

e.g. gamma(A)*gamma(B)/gamma(C)*gamma(D)
= exp(gammaln(A)+gammaln(B)-gammaln(C)+gammaln(D))

which works fine if all the arguments produce positive gamma-values.

If negative gamma-values are produced (as described in ticket #737),
the same calculation can be done by calculating gammaln on the
absolute value of the arguments, and doing a sign correction at the
end. For this, only the signs of gamma(A), etc. are needed. The
original scipy/special/cephes/gamma.c writes the sign to a global
variable named sgngam; this never gets imported to python.

It might make sense to keep gammaln as it is, but to optionally return
the sign information of gamma(A) in some way.

Your thoughts?

G-J

2008/11/1 David Cournapeau <david <at> ar.media.kyoto-u.ac.jp>:
> G-J van Rooyen wrote:
>> Hey everyone
>>
>> Ticket #737 refers:
(Continue reading)

Permalink | Reply | 8 comments |

Gmane