Re: [Numpy-discussion] ANN: Numpy 1.6.0 release candidate 2
On Sat, May 7, 2011 at 12:00 AM, DJ Luscher wrote: > Pearu Peterson gmail.com> writes: > > > > On Fri, May 6, 2011 at 10:18 PM, DJ Luscher lanl.gov> wrote: > > > > I have encountered another minor hangup. For assumed-shape array-valued > > functions defined within a fortran module there seems to be some trouble > in > > the autogenerated subroutine wrapper interface. I think it has to do > with > > the order in which variables are declared in the interface specification. > > > > in the subroutine interface specification the size(a) and size(b) are > used to > > dimension outer above (before) the declaration of a and b themselves. > This > > halts my compiler. The wrapper seems to compile OK if a and b are > declared > > above outer in the interface. > > thanks again for your help, > > > > DJ > > > > Your example works fine here:$ f2py -m foo foo_out.f90 -c$ python -c > 'import > > foo; print foo.foo.outer([1,2],[3,4])'[[ 3. 4.] [ 6. 8.]]with outer > defined > > before a and b. I would presume that compiler would > > give a warning, at least, when this would be a problem. Anyway, try to > apply > > the following patch: > > to see if changing the order will fix the hang.Pearu > > > > > indeed - it works fine as is when I compile with gfortran, but not ifort. > I > suppose there may be some compiler option for ifort to overcome that, but I > couldn't tell from a brief scan of the doc. > > the patch works when I add in two separate loops over args: (~line 138 in > func2subr.py): > >for a in args: >if a in dumped_args: continue > if isscalar(vars[a]): > add(var2fixfortran(vars,a,f90mode=f90mode)) >dumped_args.append(a) >for a in args: >if a in dumped_args: continue >if isintent_in(vars[a]): >add(var2fixfortran(vars,a,f90mode=f90mode)) >dumped_args.append(a) > > not sure if that was your intention, yes, that is what the patch was generated from. > but when I tried to use just "isintent_in" > or to include both conditions in same loop, that would not work as you noticed.. > the input arrays (a and b) were > declared ahead of the derived shape-array (outer), but also ahead of the > integers used to define a and b (e.g. f2py_a_d0). > > I have committed the patch: https://github.com/numpy/numpy/commit/6df2ac21 Pearu ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: Numpy 1.6.0 release candidate 2
Pearu Peterson gmail.com> writes: > > On Fri, May 6, 2011 at 10:18 PM, DJ Luscher lanl.gov> wrote: > > I have encountered another minor hangup. For assumed-shape array-valued > functions defined within a fortran module there seems to be some trouble in > the autogenerated subroutine wrapper interface. I think it has to do with > the order in which variables are declared in the interface specification. > > in the subroutine interface specification the size(a) and size(b) are used to > dimension outer above (before) the declaration of a and b themselves. This > halts my compiler. The wrapper seems to compile OK if a and b are declared > above outer in the interface. > thanks again for your help, > > DJ > > Your example works fine here:$ f2py -m foo foo_out.f90 -c$ python -c 'import > foo; print foo.foo.outer([1,2],[3,4])'[[ 3. 4.] [ 6. 8.]]with outer defined > before a and b. I would presume that compiler would > give a warning, at least, when this would be a problem. Anyway, try to apply > the following patch: > to see if changing the order will fix the hang.Pearu > > indeed - it works fine as is when I compile with gfortran, but not ifort. I suppose there may be some compiler option for ifort to overcome that, but I couldn't tell from a brief scan of the doc. the patch works when I add in two separate loops over args: (~line 138 in func2subr.py): for a in args: if a in dumped_args: continue if isscalar(vars[a]): add(var2fixfortran(vars,a,f90mode=f90mode)) dumped_args.append(a) for a in args: if a in dumped_args: continue if isintent_in(vars[a]): add(var2fixfortran(vars,a,f90mode=f90mode)) dumped_args.append(a) not sure if that was your intention, but when I tried to use just "isintent_in" or to include both conditions in same loop, the input arrays (a and b) were declared ahead of the derived shape-array (outer), but also ahead of the integers used to define a and b (e.g. f2py_a_d0). this works. many thanks, DJ ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: Numpy 1.6.0 release candidate 2
On Fri, May 6, 2011 at 10:18 PM, DJ Luscher wrote: > > I have encountered another minor hangup. For assumed-shape array-valued > functions defined within a fortran module there seems to be some trouble in > the > autogenerated subroutine wrapper interface. I think it has to do with the > order > in which variables are declared in the interface specification. > > for example: > > ! -*- fix -*- > module foo > contains > function outer(a,b) >implicit none >real, dimension(:), intent(in) :: a, b >real, dimension(size(a),size(b)) :: outer > >outer = spread(a,dim=2,ncopies=size(b) ) * > & spread(b,dim=1,ncopies=size(a) ) > > end function outer > end module > > when compiled by f2py creates the file: > > ! -*- f90 -*- > ! This file is autogenerated with f2py (version:2) > ! It contains Fortran 90 wrappers to fortran functions. > > subroutine f2pywrap_foo_outer (outerf2pywrap, a, b, f2py_a_d0, f2p& > &y_b_d0) > use foo, only : outer > integer f2py_a_d0 > integer f2py_b_d0 > real a(f2py_a_d0) > real b(f2py_b_d0) > real outerf2pywrap(size(a),size(b)) > outerf2pywrap = outer(a, b) > end subroutine f2pywrap_foo_outer > > subroutine f2pyinitfoo(f2pysetupfunc) > interface > subroutine f2pywrap_foo_outer (outerf2pywrap, outer, a, b, f2py_a_& > &d0, f2py_b_d0) > integer f2py_a_d0 > integer f2py_b_d0 > real outer(size(a),size(b)) > real a(f2py_a_d0) > real b(f2py_b_d0) > real outerf2pywrap(size(a),size(b)) > end subroutine f2pywrap_foo_outer > end interface > external f2pysetupfunc > call f2pysetupfunc(f2pywrap_foo_outer) > end subroutine f2pyinitfoo > > in the subroutine interface specification the size(a) and size(b) are used > to > dimension outer above (before) the declaration of a and b themselves. This > halts my compiler. The wrapper seems to compile OK if a and b are declared > above outer in the interface. > thanks again for your help, > DJ > > Your example works fine here: $ f2py -m foo foo_out.f90 -c $ python -c 'import foo; print foo.foo.outer([1,2],[3,4])' [[ 3. 4.] [ 6. 8.]] with outer defined before a and b. I would presume that compiler would give a warning, at least, when this would be a problem. Anyway, try to apply the following patch: diff --git a/numpy/f2py/func2subr.py b/numpy/f2py/func2subr.py index 0f76920..f746108 100644 --- a/numpy/f2py/func2subr.py +++ b/numpy/f2py/func2subr.py @@ -90,7 +90,6 @@ def createfuncwrapper(rout,signature=0): v['dimension'][i] = dn rout['args'].extend(extra_args) need_interface = bool(extra_args) - ret = [''] def add(line,ret=ret): @@ -143,8 +142,13 @@ def createfuncwrapper(rout,signature=0): dumped_args.append(a) for a in args: if a in dumped_args: continue +if isintent_in(vars[a]): +add(var2fixfortran(vars,a,f90mode=f90mode)) +dumped_args.append(a) +for a in args: +if a in dumped_args: continue add(var2fixfortran(vars,a,f90mode=f90mode)) - + add(l) if need_interface: to see if changing the order will fix the hang. Pearu ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: Numpy 1.6.0 release candidate 2
Pearu Peterson gmail.com> writes: > > On Fri, May 6, 2011 at 5:55 PM, DJ Luscher lanl.gov> wrote: > Pearu Peterson gmail.com> writes: > > > > > > Thanks for the bug report!These issues are now fixed in: https://github.com/numpy/numpy/commit/f393b604 Ralf, feel free to apply this > changeset to 1.6.x branch if appropriate.Regards,Pearu > > > Excellent! Thank you. > I'll cautiously add another concern because I believe it is related. Using > f2py to compile subroutines where dimensions for result variable are derived > from two argument usage of size of an assumed shape input variable does not > compile for me. > > This issue is now fixed in https://github.com/numpy/numpy/commit/a859492cI had to implement size function in C that can be called both as size(var) and size(var, dim). > The size-to-shape mapping feature is now removed. I have updated the correspondingrelease notes inhttps://github.com/numpy/numpy/commit/1f2e751bThanks for testing these new f2py features,Pearu > Pearu, I greatly appreciate how promptly you provide support for f2py. Thank you. I have encountered another minor hangup. For assumed-shape array-valued functions defined within a fortran module there seems to be some trouble in the autogenerated subroutine wrapper interface. I think it has to do with the order in which variables are declared in the interface specification. for example: ! -*- fix -*- module foo contains function outer(a,b) implicit none real, dimension(:), intent(in) :: a, b real, dimension(size(a),size(b)) :: outer outer = spread(a,dim=2,ncopies=size(b) ) * & spread(b,dim=1,ncopies=size(a) ) end function outer end module when compiled by f2py creates the file: ! -*- f90 -*- ! This file is autogenerated with f2py (version:2) ! It contains Fortran 90 wrappers to fortran functions. subroutine f2pywrap_foo_outer (outerf2pywrap, a, b, f2py_a_d0, f2p& &y_b_d0) use foo, only : outer integer f2py_a_d0 integer f2py_b_d0 real a(f2py_a_d0) real b(f2py_b_d0) real outerf2pywrap(size(a),size(b)) outerf2pywrap = outer(a, b) end subroutine f2pywrap_foo_outer subroutine f2pyinitfoo(f2pysetupfunc) interface subroutine f2pywrap_foo_outer (outerf2pywrap, outer, a, b, f2py_a_& &d0, f2py_b_d0) integer f2py_a_d0 integer f2py_b_d0 real outer(size(a),size(b)) real a(f2py_a_d0) real b(f2py_b_d0) real outerf2pywrap(size(a),size(b)) end subroutine f2pywrap_foo_outer end interface external f2pysetupfunc call f2pysetupfunc(f2pywrap_foo_outer) end subroutine f2pyinitfoo in the subroutine interface specification the size(a) and size(b) are used to dimension outer above (before) the declaration of a and b themselves. This halts my compiler. The wrapper seems to compile OK if a and b are declared above outer in the interface. thanks again for your help, DJ ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] FYI -- numpy.linalg.lstsq as distributed by Ubuntu is crashing on some inputs
On Fri, 06 May 2011 10:06:20 -0700, Nathaniel Smith wrote: > On Fri, May 6, 2011 at 3:04 AM, Pauli Virtanen wrote: >> It's terminating with SIGILL, which means that Ubuntu no longer ships a >> precompiled version of Atlas usable on machines without SSE3. > > Yes, that's right. > > BTW, where'd you get that neat detect_cpu_extensions program? Here: http://projects.scipy.org/scipy/attachment/ticket/1170/detect_cpu_extensions ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: Numpy 1.6.0 release candidate 2
On Fri, May 6, 2011 at 5:55 PM, DJ Luscher wrote: > Pearu Peterson gmail.com> writes: > > > > > > Thanks for the bug report!These issues are now fixed in: > https://github.com/numpy/numpy/commit/f393b604 Ralf, feel free to apply > this > changeset to 1.6.x branch if appropriate.Regards,Pearu > > > > Excellent! Thank you. > > I'll cautiously add another concern because I believe it is related. Using > f2py to compile subroutines where dimensions for result variable are > derived > from two argument usage of size of an assumed shape input variable does not > compile for me. > > example: > > >subroutine trans(x,y) > > implicit none > > real, intent(in), dimension(:,:) :: x > real, intent(out), dimension( size(x,2), size(x,1) ) :: y > > integer :: N, M, i, j > > N = size(x,1) > M = size(x,2) > > DO i=1,N >do j=1,M > y(j,i) = x(i,j) >END DO > END DO > >end subroutine trans > > For this example the autogenerated fortran wrapper is: > > subroutine f2pywraptrans (x, y, f2py_x_d0, f2py_x_d1) > integer f2py_x_d0 > integer f2py_x_d1 > real x(f2py_x_d0,f2py_x_d1) > real y(shape(x,-1+2),shape(x,-1+1)) > interface > subroutine trans(x,y) > real, intent(in),dimension(:,:) :: x > real, intent(out),dimension( size(x,2), size(x,1) ) :: y > end subroutine trans > end interface > call trans(x, y) > end > > which (inappropriately?) translates the fortran SIZE(var,dim) into fortran > SHAPE(var, kind). Please let me know if it is poor form for me to follow > on > with this secondary issue, but it seems like it is related and a > straight-forward fix. > This issue is now fixed in https://github.com/numpy/numpy/commit/a859492c I had to implement size function in C that can be called both as size(var) and size(var, dim). The size-to-shape mapping feature is now removed. I have updated the corresponding release notes in https://github.com/numpy/numpy/commit/1f2e751b Thanks for testing these new f2py features, Pearu ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] FYI -- numpy.linalg.lstsq as distributed by Ubuntu is crashing on some inputs
On Fri, May 6, 2011 at 3:04 AM, Pauli Virtanen wrote: > It's terminating with SIGILL, which means that Ubuntu no longer ships > a precompiled version of Atlas usable on machines without SSE3. Yes, that's right. BTW, where'd you get that neat detect_cpu_extensions program? -- Nathaniel ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Bug: np.linalg.qr crash the python interpreter if getting a shape (0, x) array.
Hi, discovered another small bug. Windows 7 32 bit, Python 2.6. In [1]: np.__version__ Out[1]: '1.5.1' In [2]: a=np.zeros((0,2)) In [3]: np.linalg.qr(a) ** On entry to DGEQRF parameter number 4 had an illegal value --Here python is crashed. While np.linalg.lstsq doesn't crashs, the error message is not very helpfull. greetings Till ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: Numpy 1.6.0 release candidate 2
Pearu Peterson gmail.com> writes: > > > Thanks for the bug report!These issues are now fixed in: https://github.com/numpy/numpy/commit/f393b604 Ralf, feel free to apply this changeset to 1.6.x branch if appropriate.Regards,Pearu > Excellent! Thank you. I'll cautiously add another concern because I believe it is related. Using f2py to compile subroutines where dimensions for result variable are derived from two argument usage of size of an assumed shape input variable does not compile for me. example: subroutine trans(x,y) implicit none real, intent(in), dimension(:,:) :: x real, intent(out), dimension( size(x,2), size(x,1) ) :: y integer :: N, M, i, j N = size(x,1) M = size(x,2) DO i=1,N do j=1,M y(j,i) = x(i,j) END DO END DO end subroutine trans For this example the autogenerated fortran wrapper is: subroutine f2pywraptrans (x, y, f2py_x_d0, f2py_x_d1) integer f2py_x_d0 integer f2py_x_d1 real x(f2py_x_d0,f2py_x_d1) real y(shape(x,-1+2),shape(x,-1+1)) interface subroutine trans(x,y) real, intent(in),dimension(:,:) :: x real, intent(out),dimension( size(x,2), size(x,1) ) :: y end subroutine trans end interface call trans(x, y) end which (inappropriately?) translates the fortran SIZE(var,dim) into fortran SHAPE(var, kind). Please let me know if it is poor form for me to follow on with this secondary issue, but it seems like it is related and a straight-forward fix. Thanks again for your previous fix. DJ ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] loadtxt ndmin option
On 6 May 2011, at 07:53, Ralf Gommers wrote: > > >> Looks okay, and I agree that it's better to fix it now. The timing > >> is a bit unfortunate though, just after RC2. I'll have closer look > >> tomorrow and if it can go in, probably tag RC3. > >> > >> If in the meantime a few more people could test this, that would be > >> helpful. > >> > >> Ralf > > > > I agree, wish I had time to push this before rc2. I could add the > > explanatory comments > > mentioned above and switch to use the atleast_[12]d() solution, test > > that and push it > > in a couple of minutes, or should I better leave it as is now for > > testing? > > Quick follow-up: I just applied the above changes, added some tests to > cover Ben's test cases and tested this with 1.6.0rc2 on OS X 10.5 > i386+ppc > + 10.6 x86_64 (Python2.7+3.2). So I'd be ready to push it to my repo > and do > my (first) pull request... > > Go ahead, I'll have a look at it tonight. Thanks for testing on > several Pythons, that definitely helps. Done, the request only appears on my repo https://github.com/dhomeier/numpy/ is that correct? If someone could test it on Linux and Windows as well... Cheers, Derek ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] FYI -- numpy.linalg.lstsq as distributed by Ubuntu is crashing on some inputs
Thu, 05 May 2011 17:41:35 -0700, Nathaniel Smith wrote: > Probably just another standard "your BLAS is compiled wrong!" bug, but > in this case I'm seeing it with the stock versions of ATLAS, numpy, etc. > included in the latest Ubuntu release (11.04 Natty Narwhal): > https://bugs.launchpad.net/ubuntu/+source/atlas/+bug/778217 > > So I thought people might like a heads up in case they run into it as > well. It's terminating with SIGILL, which means that Ubuntu no longer ships a precompiled version of Atlas usable on machines without SSE3. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
