Mailman 3 October 2005 - NumPy-Discussion

Re: [Numpy-discussion] Re: Purchasing Documentation
by Tim Churches 04 Oct '05

04 Oct '05

John Hunter wrote: >>>>>>"Tim" == Tim Churches <tchur(a)optusnet.com.au> writes: > > > Tim> Yes, I agree entirely. Travis, you are at perfect liberty to > Tim> create commercial documentation for SciPy Core, but please > Tim> don't object if others try to organise to create free open > Tim> source documentation as well. > > Object? I'll bet dollars to doughnuts that Travis would be delighted > to see this, just as he would have been at any time over the last > several years. And be careful: Perry still owes me a doughnut. Travis did indeed object, which surprised me. Verbatim: Tim C: >> I think there needs to be some community debate about this. Is there >> sufficient interest for people other than Travis to start with the >> Numeric documentation and update it as necessary to become a free >> SciPy Core documentation? The NumPy documentation is available in >> HTML format as the basis of this - perhaps the original source >> (LaTeX?) for the Numeric docs is also available? Travis: > I don't know why you would want to undermine my efforts in this way > by duplicating effort. Perhaps, instead you could have people donate > $$ instead of time to releasing the documentation. I give away > copies of the documentation to people who participate in the > development process all the time (and that comes off the total price > --- though I haven't advertised this as of yet). So, why don't you > encourage people who don't have the money to contribute to the project > instead. So, Travis seems to be proposing that he write his documentation book, which will be available only on a commercial basis (or by barter for development work) and which cannot be shared as a lab bench manual, and that any effort to create freely available documentation for scipy.core undermines his efforts. Now, we are **extremely** grateful to Travis for rescuing NumPy from a slow death by decay, and for saving us the pain of having to convert all our code to numarray (whereas the conversion to scipy.core should be much less painful). But the foregoing sets off alarm bells ringing in my head... I really think it would be useful if Travis makes a clear and unambiguous statement about where he stands on the free, open source nature of both the scipy.core code AND on documentation for it, just so we all know where we respectively stand. I have stated my position (not that it really matters), but I will re-iterate: a) scipy.core deserves a basic set of documentation (similar to the current NumPy documentation) which is available to everyone on exactly the same basis as the scipy.core code itself - that is, freely available at no cost. b) It is not Travis's duty to create such freely-available documentation. c) Others at at liberty to create such freely-available documentation for scipy.core if they so chose. d) The documentation which Travis is proposing to write will not be made freely available until targets of $300k in sales or 7 years have been reached, and this effectively renders such documentation proprietary. e) I think that the creation of proprietary supplementary documentation for scipy.core, as Travis is doing, is a good idea and I will personally buy several copies provided that the work is licensed in a reasonable manner (eg sharing of single physical copies as a bench manual is permitted). Tim C

1 0

Re: [Numpy-discussion] how to use lu decomposition in lapack library?
by Piotr Luszczek 04 Oct '05

04 Oct '05

Then you have to dig in deeper: import numarray import numarray.linear_algebra import numarray.linear_algebra.lapack_lite2 as lapack_lite piv = numarray.zeros((n,), "l") outcome = lapack_lite.dgesv(n, nrhs, a, lda, piv, b, ldb, 0) outcome['info'] is the 'info' parameter set by LAPACK. You have to make sure that 'a' and 'b' are in Fortran order because you're calling Fortran code. Here is a sample code: >>> a=numarray.array([[1,2,3],[4,5,6]], 'd') >>> a.is_fortran_contiguous() 0 >>> a.is_c_array() True >>> a.is_f_array() 0 >>> a.transpose() >>> a.is_fortran_contiguous() 1 >>> a.is_c_array() False >>> a.is_f_array() True Call to 'transpose()' made it a Fortran array but it transposed the array too. Piotr meng(a)are.berkeley.edu wrote: > Thanks, Piotr! > > What I actually want is the lower (L) and upper triangular matrix (U) > from matrix 'a'. How to get it? > > Xiangyi > > At 15:14 2005-10-4 -0400, you wrote: > >> You would have to be more specific. If you just want to >> solve a system of linear equations with matrix 'a' and >> right-hand-side 'b': >> >> import numarray.linear_algebra as LA >> >> x = LA.solve_linear_equations(a, b) >> >> Unlike LAPACK, the above will leave your 'a' untouched. >> So, if you have another right hand side 'b1' and the >> same matrix 'a' you'll have to pay the cost of factorization >> all over again. >> >> There is a way around it but I don't know what you really need. >> >> Piotr >> >> meng(a)are.berkeley.edu wrote: >> >>> Hi there- >>> Can someone help me on this? Thanks! >>> Best, >>> Xiangyi >>> Xiangyi Meng >>> Department of Agricultural and Resource Economics >>> Room 303, Giannini Hall #3310 >>> University of California, Berkeley >>> Berkeley, CA 94720-3310 >>> Tel: (510) 643-4124 >>> Fax: (510) 643-8911 >>> Email: meng(a)are.berkeley.edu >>> >>> >>> ------------------------------------------------------- >>> This SF.Net email is sponsored by: >>> Power Architecture Resource Center: Free content, downloads, >>> discussions, >>> and more. http://solutions.newsforge.com/ibmarch.tmpl >>> _______________________________________________ >>> Numpy-discussion mailing list >>> Numpy-discussion(a)lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/numpy-discussion > > > Best, > Xiangyi > > Xiangyi Meng > Department of Agricultural and Resource Economics > Room 303, Giannini Hall #3310 > University of California, Berkeley > Berkeley, CA 94720-3310 > Tel: (510) 643-4124 > Fax: (510) 643-8911 > Email: meng(a)are.berkeley.edu >

1 0

how to use lu decomposition in lapack library?
by meng＠are.berkeley.edu 04 Oct '05

04 Oct '05

Hi there- Can someone help me on this? Thanks! Best, Xiangyi Xiangyi Meng Department of Agricultural and Resource Economics Room 303, Giannini Hall #3310 University of California, Berkeley Berkeley, CA 94720-3310 Tel: (510) 643-4124 Fax: (510) 643-8911 Email: meng(a)are.berkeley.edu

2 1

Re: Purchasing Documentation
by RayS 04 Oct '05

04 Oct '05

As a lurker and neophyte user of Numeric/numarray, I inject my perspective... >the existing documentation for >NumPy is not fantastic - some aspects of it are positively >obscure - but overall it is better than good-enough I disagree here - I have found the docs to be a real stumbling block to learning and putting new (to me) methods to use. There is often a very high level of C and/or specific math familiarity assumed; I spend a large amount of time in those instances Googling for example code (usually not much Numpy code is just sitting, posted online) and Usenet examples and discussion. I then spent time at the prompt testing up my own examples. The printed Python books are usually very good resources, unfortunately, there is too much competition for general, intro Python and not enough depth into specific areas. This is the classic Publishers Dilemma. I am buying the new wx book, myself. A similar, in-depth book on Numpy does interest me at $29-$39, and Ch2 seems to be nicely done. Hopefully the new scipy_core will have the low overhead of Numeric for small arrays. Does it have easy access to the pointer to the array memory, as in numarray? (for use with ctypes.memmove()) That said, I still like more examples. People learn in different ways. I still maintain some PHP web sites, and the best (some say only ;-) ) thing is their style of online docs with user comments, ex.: array-rand: http://www.php.net/manual/en/function.array-rand.php I you need to do a particular Thing, it is very likely to already be _in_ the docs. I think this is a better approach than Wikis, and is easier and more likely for users to contribute, like this: http://www.php.net/manual/add-note.php?sect=index&redirect=http://www.php.n… (Notice also: "Please note that periodically, the developers may go through the notes and incorporate the information in them into the documentation. This means that any note submitted here becomes the property of the PHP Documentation Group.") Ray Schumacher hobby: http://rjs.org/astro/1004x/Python/

1 0

Re: Purchasing Documentation
by Tim Churches 04 Oct '05

04 Oct '05

Travis Oliphant wrote: > Tim Churches wrote: > >> Travis Oliphant wrote: >> >> >>> Tim Churches wrote: >>> >>> >> >> Travis, are you saying that this agreement only allows a single person >> to read the single printed copy? If so, I think you need a formally >> worded legal license to make that stick - certainly Australian copyright >> law (nor copyright law in other countries, I suspect) does not provide >> any support for such severe restrictions in the use of a printed >> document. Under copyright law, you may not make unauthorised copies of a >> printed document, but you can certainly lend that copy to others, or >> sell or give it to them, or share it as a bench manual. >> >> > I'm just stating what I think is fair. I'm not going to try and use the > power of the Australian state or any other to try and enforce it. My point was that you won't get any help from the State if what you think is fair extends to restricting who can read a single printed copy of your documentation. You will need to resort to tort law to enforce such restrictions, and thus you really need a formal documentation license, if that is your aim. >> Many of those downloads are for "t[y|i]re-kicking" - potential users >> determining whether it meets their needs. If those potential users have >> to pay for documentation up-front, then a large proportion will go >> elsewhere. The rest are probably existing NumPy users upgrading (or >> testing the upgrade waters). The latter group may well pay for >> documentation, but how large is that group? For example, how many people >> are subscribed to the numpy-discussion mailing list? >> >> > Don't know. But, there is enough free documentation to get started, I > think. Lack of documentation has hampered more people than cost of > existing documentation, I think. I have to disagree on this point. Granted the existing documentation for NumPy is not fantastic - some aspects of it are positively obscure - but overall it is better than good-enough, we have found, and was not a barrier to our decision to use NumPy. Having to cough up $50 to even peek at the documentation would be a far, far greater barrier to uptake than the occasional obscure wording of some of the function descriptions, IMHO. >> Travis, although many of us are grateful for your efforts on SciPy Core, >> no-one made you do it. If you wanted to earn (more) money by doing other >> things, you should have done them. >> > I'm really thinking about the future here. If I can succesfully raise > money to support work on this using a simple time-delay documentation > encouragement, then perhaps others will do the same, and we can all have > more. Waiting for people to "donate" their time to develop scientific > python is rather slow.... I've been freely donating time for a long > time, and there are few who help. So, we'll try a slightly different > route and see where that goes. Yes, fair enough. My point was that 7 years is far too long a time delay. Given that SciPy Core will probably take another year to become rock-solid, I would happily buy several copies of your documentation at $50 per copy if I knew that in a year the documentation could be freely distributed to all God's children. But in 7 years? Nope, too long to wait, not interested in supporting that. >> I think there needs to be some community debate about this. Is there >> sufficient interest for people other than Travis to start with the >> Numeric documentation and update it as necessary to become a free SciPy >> Core documentation? The NumPy documentation is available in HTML format >> as the basis of this - perhaps the original source (LaTeX?) for the >> Numeric docs is also available? > > I don't know why you would want to undermine my efforts in this way by > duplicating effort. Travis, I don't want to undermine your efforts, but you must understand that one of the attractions of NumPy and thus Scipy Core is that they are free, open source software, which implies that there exists adequate free, open source documentation for them, or if such free, open source documentation does not exist, then taht users are collectively at liberty to create it. That's a basic FOSS tenet. What you are are proposing is the creation of proprietary documentation for SciPy Core. No-one objects to this, but only if it is supplementary to free, open source "core" documentation, not instead of it. > Perhaps, instead you could have people donate $$ > instead of time to releasing the documentation. I give away copies of > the documentation to people who participate in the development process > all the time (and that comes off the total price --- though I haven't > advertised this as of yet). So, why don't you encourage people who > don't have the money to contribute to the project instead. I understand that open source software and its documentation don't just appear out of thin air, and I fully support the idea of funded or collectively-commissioned open source development. But only if the results of that funded or commissioned development is, in fact, free and open sourced. By preventing free distribution of the documentation you are creating for 7 years, the end product cannot even remotely be described as open source, thus personally I am disinterested in funding it. If the delay until open sourcing was just one year, then that's a different matter, but you do not seem to be proposing that. Hence I think the NumPy/SciPy Core user community should establish a SciPy Core documentation project, with the aim of updating and enhancing the existing NumPy documentation so that it covers the new and changed features of SciPy Core, and making that documentation available on teh same free, open source basis as NumPy/SciPy Core itself. To that end, are the original LaTeX or whatever sources for the currenet NumPy documenattion available somewhere (apart from the HTML and PDF versions, that is). Tim C

2 2

Contributions to development is one way to get documentation
by Travis Oliphant 03 Oct '05

03 Oct '05

I have not made this explicitly clear, but if somebody cannot afford the documentation, I will give it to them in return for help with development (significant bug-fixes, optimizations, improved docstrings, new features etc.). Any copy I give away, counts against the total price as well... I've already given away several copies. If you feel like you should receive one, and I've forgotten about you, let me know. Best, -Travis

1 0

Release of SciPy Core 0.4 (Beta)
by Travis Oliphant 03 Oct '05

03 Oct '05

This is to announce the release of SciPy Core 0.4.X (beta) It is available at sourceforge which you can access by going to http://numeric.scipy.org Thanks to all who helped me with this release, especially Robert Kern Pearu Peterson Now, let's start getting this stable.... -Travis Oliphant

7 11

Re: [Numpy-discussion] Release of SciPy Core 0.4 (Beta)
by Chris Barker 03 Oct '05

03 Oct '05

Travis Oliphant wrote: > Chris Barker wrote: >> Which brings up the question: How does scipy_core handle NaN and the >> other IEEE special values? This was a major weakness in Numeric for me. > > They can exist in your arrays and isnan, isinf, isposinf, isneginf > detects them. Wonderful! I'm really looking forward to this being stable. thanks, Travis! -CHB -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker(a)noaa.gov

1 0

Re: Release of SciPy Core 0.4 (Beta)
by Eric Firing 02 Oct '05

02 Oct '05

Travis, > This is to announce the release of SciPy Core 0.4.X (beta) Wonderful progress--I can't thank you enough for the work you are doing on this. I initially tried to build from the tarball, but ran into missing pieces: compile options: '-Iscipy/base/include -Ibuild/src/scipy/base -Iscipy/base/src -I/usr/include/python2.4 -c' gcc: lapack_lite/blas_lite.c gcc: lapack_lite/blas_lite.c: No such file or directory gcc: no input files I then installed from the rpm (on a Mandriva 2005 LE system) with no problems, and proceeded to poke around. It looks great! > Now, let's start getting this stable.... Bug: in function_base.py, there are four places where "nx" should be "_nx"; see attached diff. Also attached is a diff for arraymethods, to fix what look to me like erroneous docstrings for the reshape and resize methods. The present docstrings indicate that reshape makes the change in place, and resize returns a new array, but in both cases the opposite is true--reshape returns a reshaped copy, and resize returns None. Eric

1 0

Re: [SciPy-user] Release of SciPy Core 0.4 (Beta)
by Brian Granger 02 Oct '05

02 Oct '05

Which version of gccc are you using? As I understand it, g77 3.4 is not compatible with gcc 4.0 (the default on OS X). Switching to gcc 3.4 might help: gcc_select 3.3 I will soon try scipy_core on Tiger with Python 2.4.1. Brian Brian Granger, Ph.D. Assistant Professor of Physics Santa Clara University bgranger(a)scu.edu Phone: 408-551-1891 Fax: 408-554-6965 >>> managan(a)llnl.gov 09/30/05 11:21 AM >>> OK, I am giving this a go. I seem to be not setting a flag about some math functions availability. Here are the details (aorry about the length of it but I snipped a lot!): OSX 10.3.9, Python 2.4.1 Installed g77v3.4-bin.tar.gz from http://hpc.sourceforge.net/ as described into /usr/local/... Installed fftw-3.0.1-fma.tar.gz from http://www.fftw.org/download.html into ~/Documents/local/... where I have other libraries I have installed. Got scipy_core-0.4.1.tar.gz from http://sourceforge.net/project/showfiles.php?group_id=1369&package_id=6222, wanted to try out the new replacement for Numeric tar -zxvf scipy_core-0.4.1.tar.gz cd scipy_core-0.4.1 python setup.py build Assuming default configuration (scipy/distutils/command/{setup_command,setup}.py was not found) Appending scipy.distutils.command configuration to scipy.distutils Assuming default configuration (scipy/distutils/fcompiler/{setup_fcompiler,setup}.py was not found) ... Appending scipy.base configuration to scipy blas_opt_info: FOUND: extra_link_args = ['-Wl,-framework', '-Wl,Accelerate'] define_macros = [('NO_ATLAS_INFO', 3)] extra_compile_args = ['-faltivec', '-I/System/Library/Frameworks/vecLib.framework/Headers'] lapack_opt_info: FOUND: extra_link_args = ['-Wl,-framework', '-Wl,Accelerate'] define_macros = [('NO_ATLAS_INFO', 3)] extra_compile_args = ['-faltivec'] Appending scipy.lib configuration to scipy Assuming default configuration (scipy/fftpack/{setup_fftpack,setup}.py was not found) ... scipy_core version 0.4.1 running build running config_fc running build_src building extension "scipy.base.multiarray" sources creating build creating build/src creating build/src/scipy creating build/src/scipy/base Generating build/src/scipy/base/config.h customize NAGFCompiler customize AbsoftFCompiler customize IbmFCompiler Could not locate executable f77 customize GnuFCompiler customize GnuFCompiler ... compiling C sources gcc options: '-fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes' creating build/temp.darwin-7.9.0-Power_Macintosh-2.4/build creating build/temp.darwin-7.9.0-Power_Macintosh-2.4/build/src creating build/temp.darwin-7.9.0-Power_Macintosh-2.4/build/src/scipy creating build/temp.darwin-7.9.0-Power_Macintosh-2.4/build/src/scipy/base creating build/temp.darwin-7.9.0-Power_Macintosh-2.4/build/src/scipy/base/src compile options: '-Ibuild/src/scipy/base/src -Iscipy/base/include -Ibuild/src/scipy/base -Iscipy/base/src -I/Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 -c' gcc: build/src/scipy/base/src/umathmodule.c In file included from build/src/scipy/base/src/umathmodule.c:8: scipy/base/include/scipy/arrayobject.h:84: warning: redefinition of `ushort' /usr/include/sys/types.h:82: warning: `ushort' previously declared here scipy/base/include/scipy/arrayobject.h:85: warning: redefinition of `uint' /usr/include/sys/types.h:83: warning: `uint' previously declared here build/src/scipy/base/src/umathmodule.c: In function `nc_floor_quotl': build/src/scipy/base/src/umathmodule.c:1257: warning: implicit declaration of function `floorl' build/src/scipy/base/src/umathmodule.c: In function `nc_sqrtl': build/src/scipy/base/src/umathmodule.c:1269: warning: implicit declaration of function `sqrtl' ... build/src/scipy/base/__umath_generated.c:171: error: initializer element is not constant build/src/scipy/base/__umath_generated.c:171: error: (near initialization for `arccosh_data[2]') error: Command "gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dy namic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Ibuild/src/scipy/base/src -Iscipy/base/include -Ibuild/s rc/scipy/base -Iscipy/base/src -I/Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 -c b uild/src/scipy/base/src/umathmodule.c -o build/temp.darwin-7.9.0-Power_Macintosh-2.4/build/src/scipy/base /src/umathmodule.o" failed with exit status 1 At 12:59 AM -0600 9/30/05, Travis Oliphant wrote: >This is to announce the release of SciPy Core 0.4.X (beta) > >It is available at sourceforge which you can access by going to > >http://numeric.scipy.org > >Thanks to all who helped me with this release, especially > >Robert Kern >Pearu Peterson > >Now, let's start getting this stable.... > >-Travis Oliphant > > > >_______________________________________________ >SciPy-user mailing list >SciPy-user(a)scipy.net >http://www.scipy.net/mailman/listinfo/scipy-user -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Rob Managan email managan at llnl.gov LLNL phone: 925-423-0903 P.O. Box 808, L-095 FAX: 925-422-3389 Livermore, CA 94551-0808 _______________________________________________ SciPy-user mailing list SciPy-user(a)scipy.net http://www.scipy.net/mailman/listinfo/scipy-user This message scanned for viruses and SPAM by GWGuardian at SCU (MGW1)

1 0

NumPy-Discussion October 2005