headers
Travis Oliphant | 2 Dec 00:25
Picon

Re: "fancy index" assignment

Johannes Loehnert wrote:
> Hi,
>
> I have a problem with fancy assignment. Even though left and right side
> of the assignment have the same shape, an exception occurs. numpy is freshly 
> built 10 minutes ago.
>   
This is a bug in NumPy.     I've tracked it down and am trying to come 
up with a fix.

Basically, I need to figure out the transpose tuple to use to invert a 
permutation that I'm using.

If I do.

b = a.transpose(perm)
c = b.transpose(what)

so that c and a have the same shape.   I have a general formula for perm 
but I'm not quite sure how to translate that into a general formula for 
what.   I may have to just calculate the inverse permutation in the code.

-Travis.
Permalink | Reply | 0 comments |
headers
Nils Wagner | 2 Dec 10:38
Picon
Favicon

Scipy Tickets 320-322

Please can someone close Scipy Tickets 320-322.
I cannot reproduce them with the latest svn version.

Nils
Permalink | Reply | 0 comments |
headers
David Cournapeau | 4 Dec 13:39
Picon
Picon

"branching" a package inside scipy ?

Hi,

    It is a bit OT, but I would like to know if it is possible to 
"branch" a package under scipy hierarchy. Specifically, I am about to 
change heavily some internal of my toolbox pyem in the sandbox, which 
may involve some changes of scipy.clusters (I would wait for approval 
for committing the changes once done of course), but I would like to 
continue fixing some bugs and so on in the trunk.

    Is this possible for someone with write access to scipy SVN ?

    cheers,

    David
Permalink | Reply | 3 comments |
headers
Robert Kern | 4 Dec 18:04
Picon
Gravatar

Re: "branching" a package inside scipy ?

David Cournapeau wrote:
> Hi,
> 
>     It is a bit OT, but I would like to know if it is possible to 
> "branch" a package under scipy hierarchy. Specifically, I am about to 
> change heavily some internal of my toolbox pyem in the sandbox, which 
> may involve some changes of scipy.clusters (I would wait for approval 
> for committing the changes once done of course), but I would like to 
> continue fixing some bugs and so on in the trunk.
> 
>     Is this possible for someone with write access to scipy SVN ?

Certainly. Here is a brief outline on how to do it. I recommend ignoring most of
the first half, which describes the manual procedure, and using the svnmerge.py
tool that I describe in the latter half. It simplifies the process immensely.

  http://projects.scipy.org/scipy/numpy/wiki/MakingBranches

All of the examples there branch the whole trunk. The only change you have to
make is to use the URL directly to the cluster/ directory:

  http://svn.scipy.org/svn/scipy/trunk
    -->
  http://svn.scipy.org/svn/scipy/trunk/Lib/cluster

--

-- 
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
(Continue reading)

Permalink | Reply | 2 comments |
headers
Darren Dale | 4 Dec 20:39
Picon
Favicon

scipy-0.5.2

On October 25, a message was posted to scipy-dev suggesting Oct 30 as a target 
release date for scipy-0.5.2. I'm sure there are good reasons for the delay, 
but several people have asked on the lists about the availability of a scipy 
release that is compatible with numpy-1.0, and to my knowledge these 
inquiries have not been answered. Would someone knowledgeable post a status 
report concerning scipy-0.5.2 to the lists? I think the need for a compatible 
scipy release is causing problems for packagers who are trying to support a 
working numpy/scipy/matplotlib environment for scientific computing.

Respectfully,
Darren

--

-- 
Darren S. Dale, Ph.D.
Staff Scientist
Cornell High Energy Synchrotron Source
Cornell University
275 Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853

dd55 <at> cornell.edu
office: (607) 255-3819
fax: (607) 255-9001
http://www.chess.cornell.edu
Permalink | Reply | 4 comments |
headers
Travis Oliphant | 4 Dec 21:26
Favicon

Re: scipy-0.5.2

Darren Dale wrote:

>On October 25, a message was posted to scipy-dev suggesting Oct 30 as a target 
>release date for scipy-0.5.2. I'm sure there are good reasons for the delay, 
>but several people have asked on the lists about the availability of a scipy 
>release that is compatible with numpy-1.0, and to my knowledge these 
>inquiries have not been answered. Would someone knowledgeable post a status 
>report concerning scipy-0.5.2 to the lists? I think the need for a compatible 
>scipy release is causing problems for packagers who are trying to support a 
>working numpy/scipy/matplotlib environment for scientific computing.
>
>  
>
The problem is lack of help.  It would appear that I and Ed Schofield 
are being relied on to release SciPy and neither of us has found the 
time to do it in the past month.  There has been a large influx in the 
number of bug-reports and feature requests and I don't think anybody has 
been able to keep up.

My feeling is we should just release 0.5.2 now and deal with bug-reports 
later.  But, usually that means at least getting the tests to pass. 

In short, we need a release manager for SciPy.  Anybody willing to take 
up the task?

-Travis
Permalink | Reply | 3 comments |
headers
Stefan van der Walt | 4 Dec 22:28
Picon
Picon
Favicon

Re: scipy-0.5.2

On Mon, Dec 04, 2006 at 01:26:06PM -0700, Travis Oliphant wrote:
> My feeling is we should just release 0.5.2 now and deal with bug-reports 
> later.  But, usually that means at least getting the tests to pass. 
> 
> In short, we need a release manager for SciPy.  Anybody willing to take 
> up the task?

What does this entail?  Building on Windows, Linux and MacOS
platforms?  Making sure the unit tests run?  Building with the
different ATLAS-versions for the different platforms?

Does this need to be one person, or can we have three, each
responsible for a different architecture?

Regards
Stéfan
Permalink | Reply | 1 comment |
headers
Travis Oliphant | 4 Dec 23:42
Favicon

Re: scipy-0.5.2

Stefan van der Walt wrote:

>On Mon, Dec 04, 2006 at 01:26:06PM -0700, Travis Oliphant wrote:
>  
>
>>My feeling is we should just release 0.5.2 now and deal with bug-reports 
>>later.  But, usually that means at least getting the tests to pass. 
>>
>>In short, we need a release manager for SciPy.  Anybody willing to take 
>>up the task?
>>    
>>
>
>What does this entail?  Building on Windows, Linux and MacOS
>platforms?  Making sure the unit tests run?  Building with the
>different ATLAS-versions for the different platforms?
>  
>
Yes, and also deciding when to make a release.

>Does this need to be one person, or can we have three, each
>responsible for a different architecture?
>  
>
One person needs to decide when to make a release.  There should be 
several people who help with making binaries and fixing up tests.

-Travis
Permalink | Reply | 0 comments |
headers
David Cournapeau | 5 Dec 04:13
Picon
Picon

Re: "branching" a package inside scipy ?

Robert Kern wrote:
>
> Certainly. Here is a brief outline on how to do it. I recommend ignoring most of
> the first half, which describes the manual procedure, and using the svnmerge.py
> tool that I describe in the latter half. It simplifies the process immensely.
>
>   http://projects.scipy.org/scipy/numpy/wiki/MakingBranches
>
> All of the examples there branch the whole trunk. The only change you have to
> make is to use the URL directly to the cluster/ directory:
>
>   http://svn.scipy.org/svn/scipy/trunk
>     -->
>   http://svn.scipy.org/svn/scipy/trunk/Lib/cluster
>
Thanks, I am surprised I didn't find the link in the wiki (maybe the 
search does not take trac into account ?).

Anyway, can I use anything I want for a branch name ?

cheers,

David
Permalink | Reply | 1 comment |
headers
Nils Wagner | 5 Dec 09:31
Picon
Favicon

Trouble with UMFPACK 5.0

Hi all,

I have some trouble with UMFPACK 5.0.

My site.cfg reads

[DEFAULT]
library_dirs = /usr/lib:/usr/local/lib:/usr/lib64
include_dirs = /usr/include:/usr/local/include

[amd]
library_dirs = /usr/local/src/AMD/Lib
include_dirs = /usr/local/src/AMD/Include, /usr/local/src/UFconfig
amd_libs = amd

[umfpack]
library_dirs = /usr/local/src/UMFPACK/Lib
include_dirs = /usr/local/src/UMFPACK/Include, /usr/local/src/UFconfig
umfpack_libs = umfpack

python setup.py results in

building extension "scipy.linsolve.umfpack.__umfpack" sources
creating build/src.linux-x86_64-2.4/scipy/linsolve
creating build/src.linux-x86_64-2.4/scipy/linsolve/umfpack
  adding 'Lib/linsolve/umfpack/umfpack.i' to sources.
creating build/src.linux-x86_64-2.4/Lib/linsolve
creating build/src.linux-x86_64-2.4/Lib/linsolve/umfpack
swig: Lib/linsolve/umfpack/umfpack.i
swig -python -o
(Continue reading)

Permalink | Reply | 19 comments |

Gmane