headers
Stéfan van der Walt | 2 Apr 01:19
Picon
Picon
Favicon

GSoC Proposals Due on the 3rd

Hi all

Students interested in working on NumPy or SciPy for GSoC2009, please
note that the deadline for proposals is the 3rd of April.

http://socghop.appspot.com/document/show/program/google/gsoc2009/userguide#depth_studentapply

Let's keep those applications coming!

Cheers
Stéfan
Permalink | Reply | 0 comments |
headers
David Cournapeau | 2 Apr 06:49
Picon

Re: Numpy/Scipy GSOC project(s)

Hi Ross,

2009/4/1 ross smith <rjsm <at> umich.edu>:
> At first I'd be more interested in bug cleaning.  I think it's the best way
> to get comfortable with a new codebase.   Toward the second half of the
> summer, I'd be more interested in new features.

I am sorry I did not answer earlier - I unfortunately don't have the
time to give you a complete reply ATM, but you should submit your
proposal right now, as the deadline is very soon (I believe you can
improve the proposal after the deadline, after it has been submitted),

cheers,

David
_______________________________________________
Scipy-dev mailing list
Scipy-dev <at> scipy.org
http://mail.scipy.org/mailman/listinfo/scipy-dev
Permalink | Reply | 2 comments |
headers
josef.pktd | 2 Apr 16:11
Picon

python pow versus np.power

In stats distribution, I don't want exceptions to be raised for corner
cases. In many places python builtin pow is used which cannot handle
several cases.
Until now I switched to the use of np.power for each individual case
when there where problems.

Is there any strong reason not to change all occurrences of pow to np.power?
It would provide a more robust implementation, even if there is a
small performance hit.

Josef

examples:
>>> np.power(0.0,-2)
inf
>>> pow(0.,-2)
Traceback (most recent call last):
  File "<pyshell#12>", line 1, in <module>
    pow(0.,-2)
ZeroDivisionError: 0.0 cannot be raised to a negative power

>>> pow(np.inf,2)
Traceback (most recent call last):
  File "<pyshell#14>", line 1, in <module>
    pow(np.inf,2)
OverflowError: (34, 'Result too large')
>>> np.power(np.inf,2)
inf

>>> np.power(np.nan,2)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Robert Kern | 2 Apr 19:29
Picon
Gravatar

Re: python pow versus np.power

On Thu, Apr 2, 2009 at 09:11,  <josef.pktd <at> gmail.com> wrote:
> In stats distribution, I don't want exceptions to be raised for corner
> cases. In many places python builtin pow is used which cannot handle
> several cases.
> Until now I switched to the use of np.power for each individual case
> when there where problems.
>
> Is there any strong reason not to change all occurrences of pow to np.power?
> It would provide a more robust implementation, even if there is a
> small performance hit.

In scipy? Probably not. Go for it.

--

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco
Permalink | Reply | 1 comment |
headers
josef.pktd | 2 Apr 20:35
Picon

Re: python pow versus np.power

On Thu, Apr 2, 2009 at 1:29 PM, Robert Kern <robert.kern <at> gmail.com> wrote:
> On Thu, Apr 2, 2009 at 09:11,  <josef.pktd <at> gmail.com> wrote:
>> In stats distribution, I don't want exceptions to be raised for corner
>> cases. In many places python builtin pow is used which cannot handle
>> several cases.
>> Until now I switched to the use of np.power for each individual case
>> when there where problems.
>>
>> Is there any strong reason not to change all occurrences of pow to np.power?
>> It would provide a more robust implementation, even if there is a
>> small performance hit.
>
> In scipy? Probably not. Go for it.
>

Thanks, it will be only for stats.distributions

Josef
Permalink | Reply | 0 comments |
headers
Christopher Hanley | 3 Apr 01:39

New Scipy build issue

Hi,

Recently when trying to build scipy from svn I get the following build 
error:

creating build/temp.macosx-10.3-i386-2.5
creating build/temp.macosx-10.3-i386-2.5/scipy
creating build/temp.macosx-10.3-i386-2.5/scipy/fftpack
creating build/temp.macosx-10.3-i386-2.5/scipy/fftpack/src
creating build/temp.macosx-10.3-i386-2.5/scipy/fftpack/src/dfftpack
compile options: 
'-I/Users/chanley/dev/site-packages/lib/python/numpy/core/include -c'
gfortran:f77: scipy/fftpack/src/dfftpack/dcosqb.f
f951: error: unrecognized command line option "-arch"
f951: error: unrecognized command line option "-arch"
error: Command "gfortran -Wall -ffixed-form -fno-second-underscore -arch 
i686 -fPIC -O3 -funroll-loops 
-I/Users/chanley/dev/site-packages/lib/python/numpy/core/include -c -c 
scipy/fftpack/src/dfftpack/dcosqb.f -o 
build/temp.macosx-10.3-i386-2.5/scipy/fftpack/src/dfftpack/dcosqb.o" 
failed with exit status 1

I'm using gfortran for the build on my Mac OS X 10.5.6 system.  Here is 
the gfortran info:

[redcedar:~/dev/scipy] chanley% gfortran -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: ../gcc-4.2.2/configure --prefix=/sw 
--prefix=/sw/lib/gcc4.2 --mandir=/sw/share/man --infodir=/sw/share/info
(Continue reading)

Permalink | Reply | 3 comments |
headers
Robert Kern | 3 Apr 01:44
Picon
Gravatar

Re: New Scipy build issue

On Thu, Apr 2, 2009 at 18:39, Christopher Hanley <chanley <at> stsci.edu> wrote:
> Hi,
>
> Recently when trying to build scipy from svn I get the following build
> error:
>
> creating build/temp.macosx-10.3-i386-2.5
> creating build/temp.macosx-10.3-i386-2.5/scipy
> creating build/temp.macosx-10.3-i386-2.5/scipy/fftpack
> creating build/temp.macosx-10.3-i386-2.5/scipy/fftpack/src
> creating build/temp.macosx-10.3-i386-2.5/scipy/fftpack/src/dfftpack
> compile options:
> '-I/Users/chanley/dev/site-packages/lib/python/numpy/core/include -c'
> gfortran:f77: scipy/fftpack/src/dfftpack/dcosqb.f
> f951: error: unrecognized command line option "-arch"
> f951: error: unrecognized command line option "-arch"
> error: Command "gfortran -Wall -ffixed-form -fno-second-underscore -arch
> i686 -fPIC -O3 -funroll-loops
> -I/Users/chanley/dev/site-packages/lib/python/numpy/core/include -c -c
> scipy/fftpack/src/dfftpack/dcosqb.f -o
> build/temp.macosx-10.3-i386-2.5/scipy/fftpack/src/dfftpack/dcosqb.o"
> failed with exit status 1
>
>
> I'm using gfortran for the build on my Mac OS X 10.5.6 system.  Here is
> the gfortran info:
>
> [redcedar:~/dev/scipy] chanley% gfortran -v
> Using built-in specs.
> Target: i686-apple-darwin9
(Continue reading)

Permalink | Reply | 2 comments |
headers
Christopher Hanley | 3 Apr 01:47

Re: New Scipy build issue

Robert Kern wrote:
> On Thu, Apr 2, 2009 at 18:39, Christopher Hanley <chanley <at> stsci.edu> wrote:
>> Hi,
>>
>> Recently when trying to build scipy from svn I get the following build
>> error:
>>
>> creating build/temp.macosx-10.3-i386-2.5
>> creating build/temp.macosx-10.3-i386-2.5/scipy
>> creating build/temp.macosx-10.3-i386-2.5/scipy/fftpack
>> creating build/temp.macosx-10.3-i386-2.5/scipy/fftpack/src
>> creating build/temp.macosx-10.3-i386-2.5/scipy/fftpack/src/dfftpack
>> compile options:
>> '-I/Users/chanley/dev/site-packages/lib/python/numpy/core/include -c'
>> gfortran:f77: scipy/fftpack/src/dfftpack/dcosqb.f
>> f951: error: unrecognized command line option "-arch"
>> f951: error: unrecognized command line option "-arch"
>> error: Command "gfortran -Wall -ffixed-form -fno-second-underscore -arch
>> i686 -fPIC -O3 -funroll-loops
>> -I/Users/chanley/dev/site-packages/lib/python/numpy/core/include -c -c
>> scipy/fftpack/src/dfftpack/dcosqb.f -o
>> build/temp.macosx-10.3-i386-2.5/scipy/fftpack/src/dfftpack/dcosqb.o"
>> failed with exit status 1
>>
>>
>> I'm using gfortran for the build on my Mac OS X 10.5.6 system.  Here is
>> the gfortran info:
>>
>> [redcedar:~/dev/scipy] chanley% gfortran -v
>> Using built-in specs.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christopher Hanley | 3 Apr 02:08

Re: New Scipy build issue

Robert Kern wrote:
> On Thu, Apr 2, 2009 at 18:39, Christopher Hanley <chanley <at> stsci.edu> wrote:
>> Hi,
>>
>> Recently when trying to build scipy from svn I get the following build
>> error:
>>
>> creating build/temp.macosx-10.3-i386-2.5
>> creating build/temp.macosx-10.3-i386-2.5/scipy
>> creating build/temp.macosx-10.3-i386-2.5/scipy/fftpack
>> creating build/temp.macosx-10.3-i386-2.5/scipy/fftpack/src
>> creating build/temp.macosx-10.3-i386-2.5/scipy/fftpack/src/dfftpack
>> compile options:
>> '-I/Users/chanley/dev/site-packages/lib/python/numpy/core/include -c'
>> gfortran:f77: scipy/fftpack/src/dfftpack/dcosqb.f
>> f951: error: unrecognized command line option "-arch"
>> f951: error: unrecognized command line option "-arch"
>> error: Command "gfortran -Wall -ffixed-form -fno-second-underscore -arch
>> i686 -fPIC -O3 -funroll-loops
>> -I/Users/chanley/dev/site-packages/lib/python/numpy/core/include -c -c
>> scipy/fftpack/src/dfftpack/dcosqb.f -o
>> build/temp.macosx-10.3-i386-2.5/scipy/fftpack/src/dfftpack/dcosqb.o"
>> failed with exit status 1
>>
>>
>> I'm using gfortran for the build on my Mac OS X 10.5.6 system.  Here is
>> the gfortran info:
>>
>> [redcedar:~/dev/scipy] chanley% gfortran -v
>> Using built-in specs.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Anton Litvinov | 3 Apr 12:28
Picon

possible GSoC proposal

Hello

While using SciPy I thought that it would be good to have the family of Runge-Kutta methods out of the box.
This problem is of my interest and I have a desire to make this idea come true.


--
Best regards,
 Anton Litvinov
 Yugra State University

_______________________________________________
Scipy-dev mailing list
Scipy-dev <at> scipy.org
http://mail.scipy.org/mailman/listinfo/scipy-dev
Permalink | Reply | 1 comment |

Gmane