headers
Ondrej Certik | 3 Jan 2009 08:18
Picon
Gravatar

Re: tagging 0.7.0rc1 this weekend? (was Numerical Recipes ...)

On Mon, Dec 29, 2008 at 2:02 AM, Jarrod Millman <millman <at> berkeley.edu> wrote:
> The NR code review is basically complete.  All the NR copyright issues
> have been resolved (the only thing left is to verify that the
> docstrings clearly explain the code's relation to NR).  A big thanks
> to everyone who helped resolve the NR issues!
>
> Since this was the only thing blocking the release candidate, I am
> planning to create a 0.7.x branch and tag 0.7.0rc1 at the end of the
> weekend.  Once I branch for 0.7.x, the trunk will be open for 0.8
> development.

That's cool. I should hurry up with fixing the debian numpy 1.2.1
package, but I was ultra busy lately. If anyone is using Debian/Ubuntu
and would like to have the numpy 1.2.1 and scipy 0.7.0 (that depends
on it) and would like to help out, let me know. I most probably cannot
work on this for at least one more week.

Ondrej
Permalink | Reply | 0 comments |
headers
jason-sage | 3 Jan 2009 23:45

Re: almost doubled the number of tests

Jarrod Millman wrote:
> In preparation for the upcoming release, I was comparing the number of
> tests in 0.6.0 to the number on the trunk:
>   0.6.0:  Ran 2266 tests in 203.503s
>   Trunk: Ran 3990 tests in 392.357s
>   

This is great.  Do you know what the function coverage is (i.e., what 
percentage of functions have direct tests)?

Thanks,

Jason

> I knew that a large number of test had been written over the last
> year, but I was very pleased to see that we nearly doubled the number.
>  Thanks to everyone who contributed new tests over the last year.
> Increasing our test coverage is extremely important.   Importantly, it
> makes it easier to refactor the code without worrying about
> regressions creeping in without being noticed.  Hopefully, this trend
> will continue and we will add nearly 2000 new tests over the next
> year.
>
> Jarrod
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev <at> scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jarrod Millman | 4 Jan 2009 12:56
Picon
Favicon
Gravatar

Re: tagging 0.7.0rc1 this weekend? (was Numerical Recipes ...)

On Mon, Dec 29, 2008 at 2:02 AM, Jarrod Millman <millman <at> berkeley.edu> wrote:
> Since this was the only thing blocking the release candidate, I am
> planning to create a 0.7.x branch and tag 0.7.0rc1 at the end of the
> weekend.  Once I branch for 0.7.x, the trunk will be open for 0.8
> development.

Just a reminder that I will be creating a 0.7.x branch on Monday.  I
will create a rc1 tag from the branch.  Once I branch, I will send an
email to the list and the trunk will be open for 0.8 development.

David and Stefan are working on a few final clean-ups before we branch
and I plan to go over the release notes.  I would appreciate it if
everyone could review the release notes and let me know if there is
anything missing:
  http://scipy.org/scipy/scipy/milestone/0.7.0
Also it would be very useful for anyone to go over the remaining open
tickets and check to see if there are any that should be closed:
  http://scipy.org/scipy/scipy/query?status=new&status=assigned&status=reopened&milestone=0.7.0
It is possible that some of these have been resolved, but no one has
closed the ticket.

Thanks,
Jarrod
Permalink | Reply | 0 comments |
headers
Pieter Cristiaan de Groot | 4 Jan 2009 16:24
Picon
Picon

sse related crash in numpy-1.2.1 and scipy-0.7.0b1

Hello all,

In addition to this post: 
http://www.nabble.com/Re:-scipy-on-old-CPU-crashes-td20787430.html

I would like to report that numpy-1.2.1 and scipy-0.7.0b1 crash on there 
corresponding .test() scripts.
It is a windows XP machine with an Athlon XP 2200 processor (does have 
SSE, doesn't have SSE2), using python 2.5.4.

I found out the hard way that at least "leastsq" from "scipy.optimize" 
crashes. The windows crashreport points towards "_minpack.dll" if I 
remember correctly.
Digging into the problem, it turned out that both numpy and scipy crash 
on there .test() scripts. Going back to numpy 1.2.0 and scipy-0.6.0-P3 
solved the problem. I think it is a reasonable guess (but not more then 
that) that is related to SSE(2) instrucions ( see link above ).

Unfortunately I didn't store any output of the test scripts, and since 
it is a critical machine I cannot experiment to much anymore with 
different versions. Still I hope that this report may help.

Pieter

p.s. I'm a relatively new user and was confused by the 'superpack' name 
in the download section. After getting familiar with the problems 
described above I think I understand what it means now. Would it be a 
good idea to put a small explanation what 'superpack' means on the 
website (just before, or in the downoad section)?
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Cournapeau | 4 Jan 2009 17:05
Picon
Gravatar

Re: sse related crash in numpy-1.2.1 and scipy-0.7.0b1

On Mon, Jan 5, 2009 at 12:24 AM, Pieter Cristiaan de Groot
<p.c.degroot <at> tudelft.nl> wrote:
> Hello all,
>
> In addition to this post:
> http://www.nabble.com/Re:-scipy-on-old-CPU-crashes-td20787430.html
>
> I would like to report that numpy-1.2.1 and scipy-0.7.0b1 crash on there
> corresponding .test() scripts.
> It is a windows XP machine with an Athlon XP 2200 processor (does have
> SSE, doesn't have SSE2), using python 2.5.4.
>

The issue is known - and you're right about the reason. The issue
should not occur for the release of scipy 0.7.

David
Permalink | Reply | 0 comments |
headers
Stéfan van der Walt | 4 Jan 2009 23:03
Picon
Picon
Favicon

Stopping F2Py from generating verbose output

Hi all,

It seems that somewhere along the line f2py inserts debugging prints
for scipy.lib.blas.fblas.  E.g.

$ python -c "from scipy.lib.blas import fblas; fblas.zaxpy([1, 2], [3, 4], n=4)"
zaxpy:n=4
Traceback (most recent call last):
  File "<string>", line 1, in <module>
fblas.error: (len(y)-offy>(n-1)*abs(incy)) failed for 1st keyword n

Does anybody know how to suppress those "zaxpy:n=4" style messages, or
even just where they are generated?

Thanks,
Stéfan
Permalink | Reply | 4 comments |
headers
Alan G Isaac | 4 Jan 2009 23:20
Picon
Favicon

Re: Numerical Recipes (was tagging 0.7rc1 this weekend?)

> On Tue, Dec 16, 2008 at 7:34 AM, Alan G Isaac <aisaac <at> american.edu> wrote:
>> Travis O. is listed as writing this orthogonal.py in 2000 
>> and doing bug fixes in 2003.  Note that the 
>> reference to Numerical Recipes is one of two 
>> references documenting an algebraic recursion 
>> relation and is not referring to an implementation. 
>> http://www.fizyka.umk.pl/nrbook/c4-5.pdf 
>>
http://www-lsp.ujf-grenoble.fr/recherche/a3t2/a3t2a2/bahram/biblio/abramowitz_and_stegun/page_774.htm 
>> I do not see any problem with the code. 

Fernando Perez wrote:
> Other than the fact that these codes both use the same 
> piece of mathematics, I see no problem here whatsoever.  
> It might be worth clarifying in the docstring

Am I correct that the documentation project does not
give access to the module-level docstrings?  I would
have been happy to make this change in orthogonal.py
but did not see how to add documentation via the project.

Anyway, here is the reST for the GW cite and
what I think the AS citation info is.
(Not sure about the address.)

fwiw,
Alan Isaac

For the mathematical background, see
[golub.welsch-1969-mathcomp]_ and [abramowitz.stegun-1965]_.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Charles سمير Doutriaux | 5 Jan 2009 23:31

scipy fails with 2.6.1 on Mac OS X

Hi,

I'm trying to build scipy on my mac 10.5
with python 2.6.1

I get the following error message:

/usr/local/bin/gfortran -Wall -Wall -undefined dynamic_lookup -bundle  
build/temp.macosx-10.3-i386-2.6/build/src.macosx-10.3-i386-2.6/build/ 
src.macosx-10.3-i386-2.6/scipy/sparse/linalg/isolve/iterative/ 
_iterativemodule.o build/temp.macosx-10.3-i386-2.6/build/ 
src.macosx-10.3-i386-2.6/fortranobject.o build/temp.macosx-10.3- 
i386-2.6/build/src.macosx-10.3-i386-2.6/scipy/sparse/linalg/isolve/ 
iterative/STOPTEST2.o build/temp.macosx-10.3-i386-2.6/build/ 
src.macosx-10.3-i386-2.6/scipy/sparse/linalg/isolve/iterative/ 
getbreak.o build/temp.macosx-10.3-i386-2.6/build/src.macosx-10.3- 
i386-2.6/scipy/sparse/linalg/isolve/iterative/BiCGREVCOM.o build/ 
temp.macosx-10.3-i386-2.6/build/src.macosx-10.3-i386-2.6/scipy/sparse/ 
linalg/isolve/iterative/BiCGSTABREVCOM.o build/temp.macosx-10.3- 
i386-2.6/build/src.macosx-10.3-i386-2.6/scipy/sparse/linalg/isolve/ 
iterative/CGREVCOM.o build/temp.macosx-10.3-i386-2.6/build/ 
src.macosx-10.3-i386-2.6/scipy/sparse/linalg/isolve/iterative/ 
CGSREVCOM.o build/temp.macosx-10.3-i386-2.6/build/src.macosx-10.3- 
i386-2.6/scipy/sparse/linalg/isolve/iterative/GMRESREVCOM.o build/ 
temp.macosx-10.3-i386-2.6/build/src.macosx-10.3-i386-2.6/scipy/sparse/ 
linalg/isolve/iterative/QMRREVCOM.o -L/usr/local/lib/gcc/i386-apple- 
darwin8.11.1/4.3.0 -Lbuild/temp.macosx-10.3-i386-2.6 -lgfortran -o  
build/lib.macosx-10.3-i386-2.6/scipy/sparse/linalg/isolve/ 
_iterative.so -Wl,-framework -Wl,Accelerate
ld warning: duplicate dylib /usr/local/lib/libgcc_s.1.dylib
(Continue reading)

Permalink | Reply | 2 comments |
headers
Nathan Bell | 5 Jan 2009 23:54
Picon
Gravatar

Re: scipy fails with 2.6.1 on Mac OS X

On Mon, Jan 5, 2009 at 5:31 PM, Charles سمير Doutriaux
<doutriaux1 <at> llnl.gov> wrote:
> Hi,
>
> I'm trying to build scipy on my mac 10.5
> with python 2.6.1
>
> I get the following error message:
>
> In file included from scipy/sparse/linalg/dsolve/_superluobject.h:8,
>                  from scipy/sparse/linalg/dsolve/_superluobject.c:5:
> scipy/sparse/linalg/dsolve/SuperLU/SRC/scomplex.h:60: error:
> conflicting types for '_Py_c_abs'

This should be fixed in SciPy 0.7

--

-- 
Nathan Bell wnbell <at> gmail.com
http://graphics.cs.uiuc.edu/~wnbell/
_______________________________________________
Scipy-dev mailing list
Scipy-dev <at> scipy.org
http://projects.scipy.org/mailman/listinfo/scipy-dev
Permalink | Reply | 1 comment |
headers
Charles سمير Doutriaux | 5 Jan 2009 23:58

Re: scipy fails with 2.6.1 on Mac OS X

Hi Nathan,

Thanks, I just realized I wasn't building against the trunk...

Tested it against trunk and it went fine
Thanks again,

C.

On Jan 5, 2009, at 2:54 PM, Nathan Bell wrote:

> On Mon, Jan 5, 2009 at 5:31 PM, Charles سمير Doutriaux
> <doutriaux1 <at> llnl.gov> wrote:
>> Hi,
>>
>> I'm trying to build scipy on my mac 10.5
>> with python 2.6.1
>>
>> I get the following error message:
>>
>> In file included from scipy/sparse/linalg/dsolve/_superluobject.h:8,
>>                 from scipy/sparse/linalg/dsolve/_superluobject.c:5:
>> scipy/sparse/linalg/dsolve/SuperLU/SRC/scomplex.h:60: error:
>> conflicting types for '_Py_c_abs'
>
> This should be fixed in SciPy 0.7
>
> -- 
> Nathan Bell wnbell <at> gmail.com
> http:// graphics.cs.uiuc.edu/~wnbell/
(Continue reading)

Permalink | Reply | 0 comments |

Gmane