headers
Charles R Harris | 1 Dec 03:16
Picon

Re: scipy.optimize.nonlin rewrite



On Sun, Nov 30, 2008 at 4:08 PM, Gideon Simpson <simpson <at> math.toronto.edu> wrote:
Still no args input for inputting arguments to the function F?

Sorry to complain, but the absence of this has put me off using these
routines as it would require a rewrite of much of my code.

The method used for the 1d zero finders might be useful here.

Chuck 


_______________________________________________
Scipy-dev mailing list
Scipy-dev <at> scipy.org
http://projects.scipy.org/mailman/listinfo/scipy-dev
Permalink | Reply | 0 comments |
headers
Anne Archibald | 1 Dec 03:59
Picon

Re: scipy.optimize.nonlin rewrite

2008/11/30 Gideon Simpson <simpson <at> math.toronto.edu>:
> Still no args input for inputting arguments to the function F?
>
> Sorry to complain, but the absence of this has put me off using these
> routines as it would require a rewrite of much of my code.

Why?

Instead of
optimize.whatever(F, args=extra)
just use
optimize.whatever(lambda x: F(x,extra))

Anne
Permalink | Reply | 5 comments |
headers
Charles R Harris | 1 Dec 04:23
Picon

Re: scipy.optimize.nonlin rewrite



On Sun, Nov 30, 2008 at 7:59 PM, Anne Archibald <aarchiba <at> physics.mcgill.ca> wrote:
2008/11/30 Gideon Simpson <simpson <at> math.toronto.edu>:
> Still no args input for inputting arguments to the function F?
>
> Sorry to complain, but the absence of this has put me off using these
> routines as it would require a rewrite of much of my code.

Why?

Instead of
optimize.whatever(F, args=extra)
just use
optimize.whatever(lambda x: F(x,extra))

Yeah, that was my thought years ago for the zeros functions. I was told no, no, no. I'm not sure there is a good reason beyond what folks are used to.

Chuck 


_______________________________________________
Scipy-dev mailing list
Scipy-dev <at> scipy.org
http://projects.scipy.org/mailman/listinfo/scipy-dev
Permalink | Reply | 0 comments |
headers
David Cournapeau | 1 Dec 04:32
Picon

Re: scipy.optimize.nonlin rewrite

On Mon, Dec 1, 2008 at 7:10 AM, Stéfan van der Walt <stefan <at> sun.ac.za> wrote:

>
> Postponing a patch often leads to the author losing interest, and to
> the patch never being applied.

The patch should have been applied before. We are already in beta
phase, a few days away from releasing scipy. I don't see the point of
taking the time to do beta if we keep adding code, specially after the
first beta. Also, rushing to add new code may lead to oversight some
limitation, some API bug, etc...

David
_______________________________________________
Scipy-dev mailing list
Scipy-dev <at> scipy.org
http://projects.scipy.org/mailman/listinfo/scipy-dev
Permalink | Reply | 6 comments |
headers
Charles R Harris | 1 Dec 04:53
Picon

Re: scipy.optimize.nonlin rewrite



On Sun, Nov 30, 2008 at 8:32 PM, David Cournapeau <cournape <at> gmail.com> wrote:
On Mon, Dec 1, 2008 at 7:10 AM, Stéfan van der Walt <stefan <at> sun.ac.za> wrote:

>
> Postponing a patch often leads to the author losing interest, and to
> the patch never being applied.

The patch should have been applied before. We are already in beta
phase, a few days away from releasing scipy. I don't see the point of
taking the time to do beta if we keep adding code, specially after the
first beta. Also, rushing to add new code may lead to oversight some
limitation, some API bug, etc...


Agree. The code seems to need extensive rework and it would be better to take the time to get it right.

Chuck 


_______________________________________________
Scipy-dev mailing list
Scipy-dev <at> scipy.org
http://projects.scipy.org/mailman/listinfo/scipy-dev
Permalink | Reply | 0 comments |
headers
David Cournapeau | 1 Dec 05:22
Picon
Picon

Re: Single precision FFT

Anand Patil wrote:
> Dang, I should have checked my email an hour ago... it doesn't need to
> be numpy, but I already did it. I just made a new module called 'sfft'
> that's a copy of fft, but with everything in single precision. Is that
> any use to anyone?

Hi Anand,

    Sorry for not having answered before. If you care about the float
support being available to many people, I think the best solution really
is adding it to scipy. Generally, I think there is a consensus that we
would like to avoid adding new features to numpy itself, specially if
the features fit quite well scipy.

To add support to float support to scipy.fftpack, you need to do the
following:
    - Enable build the fftpack library, single version
(scipy/fftpack/src/fftpack) in scipy/fftpack/setup.py
    - start writing fftpack wrappers in C (look at zfft_pack.c and
zfft.c for a simple example complex->complex fft, one dimension)
    - add support at python level.

The 2nd step is the one which will take time, although it should be
quite similar to the double prevision version.

cheers,

David
Permalink | Reply | 12 comments |
headers
Anne Archibald | 1 Dec 05:49
Picon

Re: Single precision FFT

2008/11/30 David Cournapeau <david <at> ar.media.kyoto-u.ac.jp>:
> Anand Patil wrote:
>> Dang, I should have checked my email an hour ago... it doesn't need to
>> be numpy, but I already did it. I just made a new module called 'sfft'
>> that's a copy of fft, but with everything in single precision. Is that
>> any use to anyone?

>    Sorry for not having answered before. If you care about the float
> support being available to many people, I think the best solution really
> is adding it to scipy. Generally, I think there is a consensus that we
> would like to avoid adding new features to numpy itself, specially if
> the features fit quite well scipy.
>
> To add support to float support to scipy.fftpack, you need to do the
> following:
>    - Enable build the fftpack library, single version
> (scipy/fftpack/src/fftpack) in scipy/fftpack/setup.py
>    - start writing fftpack wrappers in C (look at zfft_pack.c and
> zfft.c for a simple example complex->complex fft, one dimension)
>    - add support at python level.
>
> The 2nd step is the one which will take time, although it should be
> quite similar to the double prevision version.

I'd also like to suggest that, if possible, it would be nice if
single-precision FFTs were not a separate module, or even a separate
function, but instead the usual fft function selected them when handed
a single-precision input.

Anne
Permalink | Reply | 11 comments |
headers
David Cournapeau | 1 Dec 08:02
Picon
Picon

How to test for easy_install scipy from sources ?

Hi,

    I would like to see if I fixed the following issue:

http://scipy.org/scipy/scipy/ticket/801

Problem is, I don't know how easy_install is used for something not
released on pypi ?

thanks,

David
Permalink | Reply | 2 comments |
headers
David Cournapeau | 1 Dec 08:24
Picon

Re: 1 Failure in 0.7.0b1

On Mon, Dec 1, 2008 at 8:12 AM, Xavier Gnata <xavier.gnata <at> gmail.com> wrote:

> Ok I can reproduce this one on intrepid ibex 64bits (gfortran).
> The funny think is that I think (if I read the correct mathword pages)
> that 1.0 is the correct answer (but it is so easy to be wrong with these
> special function).

I can't reproduce on RHEL 5 (64 bits/python2.4). I opened a ticket:

http://scipy.org/scipy/scipy/ticket/803

Neal, Xavier, which version of numpy are you using ? Which version of
gcc is used in FC 9 ?

thanks,

David
Permalink | Reply | 3 comments |
headers
Gael Varoquaux | 1 Dec 09:09
Favicon
Gravatar

Re: How to test for easy_install scipy from sources ?

On Mon, Dec 01, 2008 at 04:02:04PM +0900, David Cournapeau wrote:
>     I would like to see if I fixed the following issue:

> http://scipy.org/scipy/scipy/ticket/801

> Problem is, I don't know how easy_install is used for something not
> released on pypi ?

Use the -f switch of easy_install to point to a local directory on your
box where you build an egg, an simply put a source tar.gz.

GaËl
Permalink | Reply | 1 comment |

Gmane