Re: [Numpy-discussion] Floating Point Difference between numpy and numarray
> I now have a distinct dislike of float values (it'll probably wear off over > time), how can the sum of 100,000 numbers be anything other than the sum of > those numbers. I know the reasoning, as highlighted by the couple of other > e-mails we have had, but I feel the default should probably lean towards > accuracy than speed. 2.0+2.0=4.0 and 2.0+2.0.=200,000.0 not 2array.sum() > != 200,000... In that case, we should not use doubles, but long double or even better, the real numbers themselves. Which would mean that computations would be very very very slow. Numpy leans somehow towards accuracy. If you want more accuracy (because even with double, you can hit the limit very fast), use another type. You said : how can the sum of 100,000 numbers be anything other than the sum of > those numbers This will always be a problem. With doubles, try to sum 1/n (1...10), you'll be surprized. And then do sum 1/n (10...1) with float values, and here the result should be better than when using doubles. Numerical issues in scientific computing are tricky. There is no single answer, it depends on your problem. Matthieu -- French PhD student Information System Engineer Website: http://matthieu-brucher.developpez.com/ Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn: http://www.linkedin.com/in/matthieubrucher ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Floating Point Difference between numpy and numarray
On Tue, 2008-09-09 at 07:53 +0100, Hanni Ali wrote: > Hi David, > > Forgot to answer last week, I was under a fair bit of pressure time > wise, but thanks for your input. I sorted it all in the end and just > in time, but the main issue here was the change from numarray to > numpy. Previously where a typecode of 'f' was used in numarray, the > calculation was performed in double precision whereas in numpy it was > calculated in single precision. Hence when migrating the code, the > differences popped up, which were fairly big when considering the size > and number of mean calcs we perform. Hi Hanni, glad it worked ok for you. > > I now have a distinct dislike of float values (it'll probably wear off > over time), how can the sum of 100,000 numbers be anything other than > the sum of those numbers. I know the reasoning, as highlighted by the > couple of other e-mails we have had, but I feel the default should > probably lean towards accuracy than speed. 2.0+2.0=4.0 and 2.0 > +2.0.=200,000.0 not 2array.sum() != 200,000... I think it is a fallacy to say you prefer accuracy over speed: the fallacy is in thinking it is binary choice. You care about speed, because otherwise, you would not use a computer at all, you would do everything by hand [1]. Floating point is by itself an approximation: it can not even represent rational number accurately, let alone algebraic numbers or transcendent ones ! There are packages to do exact computation (look at sage for example for something based on python), but numpy/scipy are first numerical computation, meaning approximation along the way. It is true that it can give some unexpected results, and you should be aware of floating point limitations [2]. That being said, for a lot of computations, when you have unexpected difference between float and double, you have a problem in your implementation. For example, IIRC, you computed average of a big number numbers, at once: you can get better results if you first normalize your numbers. Another example which bites me all the time in statistic is when computing exponential of small numbers: log(exp(-1000)) will be -Inf done naively, but you and me know the solution is of course -1000; again, you should think more about your computation. IOW, floating point are a useful approximation/abstraction (I don't know if you are familiar with fixed point computation, as done in some DSP, but it is not pretty), but it breaks in some cases. cheers, David [1] I know some people do this for some kind of computation; in a different context from numerical computation, I found the following interview from Alain Connes (one of the most famous French Mathematician currently alive), to be extemely enlightening: http://www.ipm.ac.ir/IPM/news/connes-interview.pdf (see page 2-3 for the discussion about computer and computation) [2] "What every computer scientist should know about floating-point arithmetic", in ACM Computer Survey, 1991, By David Goldberg. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] planning for numpy 1.3.0 release
2008/9/9 Christopher Barker <[EMAIL PROTECTED]>: > Jarrod Millman wrote: >> So if there is something that you would like to work on during this >> release cycle, please bring it up now. > > Anyone want to help with improvements to fromfile() for text files? This is low hanging fruit for anyone with some experience in C. We can definitely get it done for 1.3. Chris, would you file a ticket and add the detail from your mailing list posts, if that hasn't already been done? Thanks Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Floating Point Difference between numpy and numarray
Hi Matthieu, Interesting example thanks. I can't however seem to get anything other than zero for the 100,000 to 1 sum. Cheers, Hanni 2008/9/9 Matthieu Brucher <[EMAIL PROTECTED]> > > I now have a distinct dislike of float values (it'll probably wear off > over > > time), how can the sum of 100,000 numbers be anything other than the sum > of > > those numbers. I know the reasoning, as highlighted by the couple of > other > > e-mails we have had, but I feel the default should probably lean towards > > accuracy than speed. 2.0+2.0=4.0 and 2.0+2.0.=200,000.0 not > 2array.sum() > > != 200,000... > > In that case, we should not use doubles, but long double or even > better, the real numbers themselves. Which would mean that > computations would be very very very slow. > Numpy leans somehow towards accuracy. If you want more accuracy > (because even with double, you can hit the limit very fast), use > another type. > > You said : > how can the sum of 100,000 numbers be anything other than the sum of > > those numbers > > This will always be a problem. With doubles, try to sum 1/n > (1...10), you'll be surprized. And then do sum 1/n (10...1) > with float values, and here the result should be better than when > using doubles. Numerical issues in scientific computing are tricky. > There is no single answer, it depends on your problem. > > Matthieu > -- > French PhD student > Information System Engineer > Website: http://matthieu-brucher.developpez.com/ > Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 > LinkedIn: http://www.linkedin.com/in/matthieubrucher > ___ > Numpy-discussion mailing list > Numpy-discussion@scipy.org > http://projects.scipy.org/mailman/listinfo/numpy-discussion > ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Floating Point Difference between numpy and numarray
> > > I think it is a fallacy to say you prefer accuracy over speed: the > fallacy is in thinking it is binary choice. You care about speed, > because otherwise, you would not use a computer at all, you would do > everything by hand [1]. Floating point is by itself an approximation: it > can not even represent rational number accurately, let alone algebraic > numbers or transcendent ones ! There are packages to do exact > computation (look at sage for example for something based on python), > but numpy/scipy are first numerical computation, meaning approximation > along the way. > True perhaps I should have said consistency, rather than accuracy. Cheers ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] planning for numpy 1.3.0 release
Tue, 09 Sep 2008 09:49:32 +0200, Stéfan van der Walt wrote:
> 2008/9/9 Christopher Barker <[EMAIL PROTECTED]>:
>> Jarrod Millman wrote:
>>> So if there is something that you would like to work on during this
>>> release cycle, please bring it up now.
>>
>> Anyone want to help with improvements to fromfile() for text files?
>
> This is low hanging fruit for anyone with some experience in C. We can
> definitely get it done for 1.3. Chris, would you file a ticket and add
> the detail from your mailing list posts, if that hasn't already been
> done?
I'd like to address the C locale dependency of fromfile and fromstring.
(setlocale() affects fromfile, but does not affect fromstring; locale can
make eg. "," become the decimal separator instead of ".").
I'd assume we want to follow Fortran and Python here, and *not* format or
parse floating point numbers according the C locale. Use of fscanf might
need to be reconsidered, or the calls need to be wrapped in setlocale
("C"); setlocale(old_locale); pairs...
Locale-related tickets: #884, #902, #695
Running numpy tests under different locales and calling
setlocale(LC_ALL, "") may reveal some additional points to address.
--
Pauli Virtanen
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] planning for numpy 1.3.0 release
On Mon, Sep 8, 2008 at 11:54 PM, David Cournapeau < [EMAIL PROTECTED]> wrote: > On Mon, 2008-09-08 at 17:12 -0700, Jarrod Millman wrote: > > Now that 1.2.0 is almost finalized, I wanted to ask everyone to start > > thinking about what they plan to work on for the next minor release: > > http://scipy.org/scipy/numpy/milestone/1.3.0 > > > > We have been gradually moving toward a more time-based release > > schedule over the last several months. In this vein, I would like to > > move feature and code discussion and planning to the beginning of the > > release cycle, rather than waiting until the end of the release cycle. > > So if there is something that you would like to work on during this > > release cycle, please bring it up now. > > > > Also it is important for us to keep the trunk as stable as possible; > > if you wish to work on a major new feature or an significant > > refactoring of the codebase, please work in a branch. > > Hi Jarrod, hi everyone, > >Here are some things I would like to work/seen fixed on for 1.3: >- fix VS 2003 compilation for mtrand.c (numpy is not > buildable with VS > 2003.2005.2008 ATM because of a compiler limitation) >- clean umathmodule (work almost done in the clean_math > branch, still > need some testing on windows and solaris before merging). > I also have a big rearrangement/cleanup of the inner loops in the umathmodule that has been sitting around for half a year. I think it is almost orthogonal to your work because it deals with a different part of the code. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Floating Point Difference between numpy and numarray
Use 1./n instead of 1/n. If n is an integer, 1/n equals 0. Matthieu 2008/9/9 Hanni Ali <[EMAIL PROTECTED]>: > Hi Matthieu, > > Interesting example thanks. I can't however seem to get anything other than > zero for the 100,000 to 1 sum. > > Cheers, > > Hanni > > 2008/9/9 Matthieu Brucher <[EMAIL PROTECTED]> >> >> > I now have a distinct dislike of float values (it'll probably wear off >> > over >> > time), how can the sum of 100,000 numbers be anything other than the sum >> > of >> > those numbers. I know the reasoning, as highlighted by the couple of >> > other >> > e-mails we have had, but I feel the default should probably lean towards >> > accuracy than speed. 2.0+2.0=4.0 and 2.0+2.0.=200,000.0 not >> > 2array.sum() >> > != 200,000... >> >> In that case, we should not use doubles, but long double or even >> better, the real numbers themselves. Which would mean that >> computations would be very very very slow. >> Numpy leans somehow towards accuracy. If you want more accuracy >> (because even with double, you can hit the limit very fast), use >> another type. >> >> You said : >> how can the sum of 100,000 numbers be anything other than the sum of >> > those numbers >> >> This will always be a problem. With doubles, try to sum 1/n >> (1...10), you'll be surprized. And then do sum 1/n (10...1) >> with float values, and here the result should be better than when >> using doubles. Numerical issues in scientific computing are tricky. >> There is no single answer, it depends on your problem. >> >> Matthieu >> -- >> French PhD student >> Information System Engineer >> Website: http://matthieu-brucher.developpez.com/ >> Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 >> LinkedIn: http://www.linkedin.com/in/matthieubrucher >> ___ >> Numpy-discussion mailing list >> Numpy-discussion@scipy.org >> http://projects.scipy.org/mailman/listinfo/numpy-discussion > > > ___ > Numpy-discussion mailing list > Numpy-discussion@scipy.org > http://projects.scipy.org/mailman/listinfo/numpy-discussion > > -- French PhD student Information System Engineer Website: http://matthieu-brucher.developpez.com/ Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn: http://www.linkedin.com/in/matthieubrucher ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Floating Point Difference between numpy and numarray
I already was... 2008/9/9 Matthieu Brucher <[EMAIL PROTECTED]> > Use 1./n instead of 1/n. If n is an integer, 1/n equals 0. > > Matthieu > > 2008/9/9 Hanni Ali <[EMAIL PROTECTED]>: > > Hi Matthieu, > > > > Interesting example thanks. I can't however seem to get anything other > than > > zero for the 100,000 to 1 sum. > > > > Cheers, > > > > Hanni > > > > 2008/9/9 Matthieu Brucher <[EMAIL PROTECTED]> > >> > >> > I now have a distinct dislike of float values (it'll probably wear off > >> > over > >> > time), how can the sum of 100,000 numbers be anything other than the > sum > >> > of > >> > those numbers. I know the reasoning, as highlighted by the couple of > >> > other > >> > e-mails we have had, but I feel the default should probably lean > towards > >> > accuracy than speed. 2.0+2.0=4.0 and 2.0+2.0.=200,000.0 not > >> > 2array.sum() > >> > != 200,000... > >> > >> In that case, we should not use doubles, but long double or even > >> better, the real numbers themselves. Which would mean that > >> computations would be very very very slow. > >> Numpy leans somehow towards accuracy. If you want more accuracy > >> (because even with double, you can hit the limit very fast), use > >> another type. > >> > >> You said : > >> how can the sum of 100,000 numbers be anything other than the sum of > >> > those numbers > >> > >> This will always be a problem. With doubles, try to sum 1/n > >> (1...10), you'll be surprized. And then do sum 1/n (10...1) > >> with float values, and here the result should be better than when > >> using doubles. Numerical issues in scientific computing are tricky. > >> There is no single answer, it depends on your problem. > >> > >> Matthieu > >> -- > >> French PhD student > >> Information System Engineer > >> Website: http://matthieu-brucher.developpez.com/ > >> Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 > >> LinkedIn: http://www.linkedin.com/in/matthieubrucher > >> ___ > >> Numpy-discussion mailing list > >> Numpy-discussion@scipy.org > >> http://projects.scipy.org/mailman/listinfo/numpy-discussion > > > > > > ___ > > Numpy-discussion mailing list > > Numpy-discussion@scipy.org > > http://projects.scipy.org/mailman/listinfo/numpy-discussion > > > > > > > > -- > French PhD student > Information System Engineer > Website: http://matthieu-brucher.developpez.com/ > Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 > LinkedIn: http://www.linkedin.com/in/matthieubrucher > ___ > Numpy-discussion mailing list > Numpy-discussion@scipy.org > http://projects.scipy.org/mailman/listinfo/numpy-discussion > ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] [Fwd: Fwd: [ML-news] Call for Submissions: Workshop on Machine Learning Open Source Software (MLOSS), NIPS*08]
Maybe of interest. E. Original Message -- Forwarded message -- From: mikiobraun <[EMAIL PROTECTED]> Date: 2008/9/8 Subject: [ML-news] Call for Submissions: Workshop on Machine Learning Open Source Software (MLOSS), NIPS*08 To: Machine Learning News <[EMAIL PROTECTED]> ** Call for Submissions Workshop on Machine Learning Open Source Software 2008 http://mloss.org/workshop/nips08 held at NIPS*08, Whistler, Canada, December 12th, 2008 ** The NIPS workshop on Workshop on Machine Learning Open Source Software (MLOSS) will held in Whistler (B.C.) on the 12th of December, 2008. Important Dates === * Submission Date: October 1st, 2008 * Notification of Acceptance: October 14th, 2008 * Workshop date: December 12 or 13th, 2008 Call for Contributions == The organizing committee is currently seeking abstracts for talks at MLOSS 2008. MLOSS is a great opportunity for you to tell the community about your use, development, or philosophy of open source software in machine learning. This includes (but is not limited to) numeric packages (as e.g. R,octave,numpy), machine learning toolboxes and implementations of ML-algorithms. The committee will select several submitted abstracts for 20-minute talks. The submission process is very simple: * Tag your mloss.org project with the tag nips2008 * Ensure that you have a good description (limited to 500 words) * Any bells and whistles can be put on your own project page, and of course provide this link on mloss.org On 1 October 2008, we will collect all projects tagged with nips2008 for review. Note: Projects must adhere to a recognized Open Source License (cf. http://www.opensource.org/licenses/ ) and the source code must have been released at the time of submission. Submissions will be reviewed based on the status of the project at the time of the submission deadline. Description === We believe that the wide-spread adoption of open source software policies will have a tremendous impact on the field of machine learning. The goal of this workshop is to further support the current developments in this area and give new impulses to it. Following the success of the inaugural NIPS-MLOSS workshop held at NIPS 2006, the Journal of Machine Learning Research (JMLR) has started a new track for machine learning open source software initiated by the workshop's organizers. Many prominent machine learning researchers have co-authored a position paper advocating the need for open source software in machine learning. Furthermore, the workshop's organizers have set up a community website mloss.org where people can register their software projects, rate existing projects and initiate discussions about projects and related topics. This website currently lists 123 such projects including many prominent projects in the area of machine learning. The main goal of this workshop is to bring the main practitioners in the area of machine learning open source software together in order to initiate processes which will help to further improve the development of this area. In particular, we have to move beyond a mere collection of more or less unrelated software projects and provide a common foundation to stimulate cooperation and interoperability between different projects. An important step in this direction will be a common data exchange format such that different methods can exchange their results more easily. This year's workshop sessions will consist of three parts. * We have two invited speakers: John Eaton, the lead developer of Octave and John Hunter, the lead developer of matplotlib. * Researchers are invited to submit their open source project to present it at the workshop. * In discussion sessions, important questions regarding the future development of this area will be discussed. In particular, we will discuss what makes a good machine learning software project and how to improve interoperability between programs. In addition, the question of how to deal with data sets and reproducibility will also be addressed. Taking advantage of the large number of key research groups which attend NIPS, decisions and agreements taken at the workshop will have the potential to significantly impact the future of machine learning software. Invited Speakers * John D. Hunter - Main author of matplotlib. * John W. Eaton - Main author of Octave. Tentative Program = The 1 day workshop will be a mixture of talks (including a mandatory demo of the software) and panel/open/hands-on discussions. Morning session: 7:30am - 10:30am * Introduction and overview * Octave (Jo
Re: [Numpy-discussion] planning for numpy 1.3.0 release
On Tue, Sep 9, 2008 at 7:45 PM, Charles R Harris <[EMAIL PROTECTED]> wrote: > > I also have a big rearrangement/cleanup of the inner loops in the > umathmodule that has been sitting around for half a year. I think it is > almost orthogonal to your work because it deals with a different part of the > code. Maybe you could commit your changes to my branch, then ? For now, most of my changes are under git, but I can commit them to svn. cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] planning for numpy 1.3.0 release
On Tue, Sep 9, 2008 at 9:12 AM, Jarrod Millman <[EMAIL PROTECTED]> wrote: > Now that 1.2.0 is almost finalized, I wanted to ask everyone to start > thinking about what they plan to work on for the next minor release: > http://scipy.org/scipy/numpy/milestone/1.3.0 > > We have been gradually moving toward a more time-based release > schedule over the last several months. In this vein, I would like to > move feature and code discussion and planning to the beginning of the > release cycle, rather than waiting until the end of the release cycle. > Something else which could be nice - but arguably difficult depending on what is needed - is making sure numpy does work with python 2.6. I am saying this because I just saw Barry Warsaw mentioning splitting python 2.6/3.0 releases date such as python 2.6 will be integrated in next version of Mac OS X. cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Floating Point Difference between numpy and numarray
On Tue, 9 Sep 2008, David Cournapeau wrote: > We don't use SSE and co in numpy, and I doubt the compilers (even > Intel one) are able to generate effective SSE for numpy ATM. Actually, > double and float are about the same speed for x86 (using the x87 FPU > and not the SSE units), because internally, the register is 80 bits > wide when doing computation. The real difference is the memory > pressure induced by double (8 bytes per items) compared to float when > doing computation with double, and for certain operations, for a > reason I don't understand (log, sin and co are as fast for float and > double using the FPU, but sqrt and divide are twice faster for float, > for example). Some of the transcendental functions are implemented with polynomials, so should take constant time. Others may use iterative algorithms, which would require fewer iterations to reach single accuracy than double. w ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Floating Point Difference between numpy and numarray
Hanni Ali wrote: > > Interesting example thanks. I can't however seem to get anything > other than > > zero for the 100,000 to 1 sum. what is the "100,000 to 1 sum." this is my interpretation: a = np.linspace(10, 1, 10) >>> a array([ 1.e+05, 9.e+04, 9.9998e+04, ..., 3.e+00, 2.e+00, 1.e+00]) >>> a.sum() 55.0 which is exact, but it won't be if you use single precision: >>> a = a.astype(np.float32) >>> a.sum() 5.865e+09 You'd have to use tricks like compensated summation and the like to improve the answers, if you want. Actually, it would be kind of neat to have that in numpy or scipy... What are you trying to do? Show us the code, and I'm sure someone can explain why you are getting what you are getting. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] small bug in numpy.ma.minimum.outer
a=numpy.ones((2,2)) >>> numpy.minimum.outer(a,a) array( 1., 1.], [ 1., 1.]], [[ 1., 1.], [ 1., 1.]]], [[[ 1., 1.], [ 1., 1.]], [[ 1., 1.], [ 1., 1.) >>> numpy.ma.minimum.outer(a,a) Traceback (most recent call last): File "", line 1, in File "/lgm/cdat/latest/lib/python2.5/site-packages/numpy/ma/core.py", line 3317, in outer result._mask = m AttributeError: 'numpy.ndarray' object has no attribute '_mask' ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] compressed and sqrt in numpy.ma
The following is causing our code to crash, shouldn't .data be just ones ? >>> a = numpy.ma.ones((2,2)) >>> b = numpy.ma.sqrt(a) >>> b.compressed().data ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] compressed and sqrt in numpy.ma
On Tuesday 09 September 2008 14:14:48 Charles Doutriaux wrote: > The following is causing our code to crash, shouldn't .data be just ones ? > > >>> a = numpy.ma.ones((2,2)) > >>> b = numpy.ma.sqrt(a) > >>> b.compressed().data Nope. When you use compressed(), you get a ndarray (or a subclass, depending on the _baseclass attribute), but no longer a MaskedArray. Therefore, the '.data' attribute is the corresponding ndarray.data. In your example, just use b.compressed() ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] small bug in numpy.ma.minimum.outer
On Tuesday 09 September 2008 14:03:04 Charles Doutriaux wrote: > a=numpy.ones((2,2)) > > >>> numpy.minimum.outer(a,a) > >>> numpy.ma.minimum.outer(a,a) Fixed in SVN r5800. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] small bug in numpy.ma.minimum.outer
Thx Pierre Pierre GM wrote: > On Tuesday 09 September 2008 14:03:04 Charles Doutriaux wrote: > >> a=numpy.ones((2,2)) >> >> >>> numpy.minimum.outer(a,a) >> >>> numpy.ma.minimum.outer(a,a) >> > > Fixed in SVN r5800. > ___ > Numpy-discussion mailing list > Numpy-discussion@scipy.org > http:// projects.scipy.org/mailman/listinfo/numpy-discussion > > > ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] upcoming 1.2.0rc2 (1.2.0 final soon to follow)!
I will be branching for 1.2.0rc2 shortly. Please don't commit anything to the branch without running it by the list: http://projects.scipy.org/scipy/numpy/browser/branches/1.2.x Once the binaries have been made, I will send out an announcement. Thanks, Jarrod On Mon, Sep 8, 2008 at 4:45 PM, Jarrod Millman <[EMAIL PROTECTED]> wrote: > Hello, > > There have been a few updates to the 1.2.x branch that resolve some > issues with the last release candidate: > - a loadtxt regression: http://projects.scipy.org/scipy/numpy/changeset/5790 > - a knownfailureif decorator was added: > http://projects.scipy.org/scipy/numpy/changeset/5792 > - and used for a known Window's issue: > http://projects.scipy.org/scipy/numpy/changeset/5795 > - a numscons build directory issue: > http://projects.scipy.org/scipy/numpy/changeset/5794 > > There are no other issues that I am aware of that would block a final > release. If you know of a major regression or bug that would > constitute a release blocker, please let me know ASAP. Otherwise I > will tag a 1.2.0rc2 later tonight and announce it tomorrow. Assuming > there are no new issues with the new release candidate, I plan to tag > the final 1.2.0 release on Sunday. > > Also, please take a look at the release notes and let me know if > anything needs to be changed or added: > http://projects.scipy.org/scipy/numpy/milestone/1.2.0 > > Thanks, > > -- > Jarrod Millman > Computational Infrastructure for Research Labs > 10 Giannini Hall, UC Berkeley > phone: 510.643.4014 > http://cirl.berkeley.edu/ > -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Still having issues
Mark,
I have taken the advice that you had given to me the other day.
However, I am still having issues with actually executing the f2py.py
script.
> If numpy is installed, then f2py will be too. > On the windows
environment,
> there is a file called f2py.py that you can >>> > call from the
command line. It
> should be in the 'scripts' directory of your > > Python
installation.
>
> Try something like this:
>
> python c:\python25\scripts\f2py.py
> (of course change to reflect your own python > > installation
directory)
It appears that once I run the f2py.py script from the IDLE environment,
I will then obtain the following error:
You will have to read at the end of the listed output. It looks as
though there was a premature system exit once f2py.py was executed.
>>>
Usage:
1) To construct extension module sources:
f2py [] [[[only:]||[skip:]] \
] \
[: ...]
2) To compile fortran files and build extension modules:
f2py -c [, , ]
3) To generate signature files:
f2py -h ...< same options as in (1) >
Description: This program generates a Python C/API file
(module.c)
that contains wrappers for given fortran functions so that
they
can be called from Python. With the -c option the
corresponding
extension modules are built.
Options:
--g3-numpy Use numpy.f2py.lib tool, the 3rd generation of F2PY,
with NumPy support.
--2d-numpy Use numpy.f2py tool with NumPy support. [DEFAULT]
--2d-numeric Use f2py2e tool with Numeric support.
--2d-numarrayUse f2py2e tool with Numarray support.
-h Write signatures of the fortran routines to file
and exit. You can then edit and use it
instead
of . If ==stdout then the
signatures are printed to stdout.
Names of fortran routines for which Python C/API
functions will be generated. Default is all that are
found
in .
Paths to fortran/signature files that will be scanned
for
in order to determine their
signatures.
skip:Ignore fortran functions that follow until `:'.
only:Use only fortran functions that follow until `:'.
:Get back to mode.
-m Name of the module; f2py generates a Python/C API
file module.c or extension module
.
Default is 'untitled'.
--[no-]lower Do [not] lower the cases in . By
default,
--lower is assumed with -h key, and --no-lower
without -h key.
--build-dir All f2py generated files are created in
.
Default is tempfile.mktemp().
--overwrite-signature Overwrite existing signature file.
--[no-]latex-doc Create (or not) module.tex.
Default is --no-latex-doc.
--short-latexCreate 'incomplete' LaTeX document (without commands
\documentclass, \tableofcontents, and
\begin{document},
\end{document}).
--[no-]rest-doc Create (or not) module.rst.
Default is --no-rest-doc.
--debug-capi Create C/API code that reports the state of the
wrappers
during runtime. Useful for debugging.
--[no-]wrap-functionsCreate Fortran subroutine wrappers to Fortran
77
functions. --wrap-functions is default because it
ensures
maximum portability/compiler independence.
--include_paths ::... Search include files from the
given
directories.
--help-link [..] List system resources found by system_info.py. See
also
--link- switch below. [..] is optional list
of resources names. E.g. try 'f2py --help-link
lapack_opt'.
--quiet Run quietly.
--verboseRun with extra verbosity.
-v Print f2py version ID and exit.
numpy.distutils options (only effective with -c):
--fcompiler= Specify Fortran compiler type by vendor
--compiler= Specify C compiler type (as defined by distutils)
--help-fcompiler List available Fortran compilers and exit
--f77exec= Specify the path to F77 compiler
--f90exec= Specify the path to F90 compiler
--f77flags= Specify F77 compiler flags
--f90flags= Specify F90 compiler flags
--opt= Specify optimization flags
--arch= Specify architecture specific optimization flags
--noopt Compile without optimization
--noarch Compile without arch-dependent optimization
--debug Compile with debugging information
Extra options (only effective with -c):
--link-Link extension module with as defined
by numpy.distutils/system_info.py. E.g. to link
with o
Re: [Numpy-discussion] Still having issues
On Tue, Sep 9, 2008 at 17:53, Blubaugh, David A. <[EMAIL PROTECTED]> wrote: > It appears that once I run the f2py.py script from the IDLE environment, That's your problem. It is a script to run from the command line, not a module for you to import. Please reply to messages with the reply button in your mail reader instead of creating a new thread every time. Thanks. -- 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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] norm_gen
Hi, can anyone point me in the direction of some example code to use the norm_gen function in scipy.stats? I know this is the wrong board but I seem to be at the wrong end of the moderation queue on the scipy board and have been for a couple of weeks, so my posts over there don't show up. I'm hoping that someone here might be able to point me in the right direction Thanks in advance Simon ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] NumPy arrays that use memory allocated from other libraries or tools
I wanted to point anybody interested to a blog post that describes a useful pattern for having a NumPy array that points to the memory created by a different memory manager than the standard one used by NumPy. The pattern shows how to create a NumPy array that points to previously allocated memory and then shows how to construct an object that allows the correct deallocator to be called when the NumPy array is freed. This may be useful if you are wrapping code that has it's own memory management scheme. Comments and feedback is welcome. The post is http://blog.enthought.com/?p=62 Best regards, -Travis Oliphant ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] fromfile() improvements (was: planning for numpy 1.3.0 release)
Stéfan van der Walt wrote: > 2008/9/9 Christopher Barker <[EMAIL PROTECTED]>: >> Anyone want to help with improvements to fromfile() for text files? > > This is low hanging fruit for anyone with some experience in C. We > can definitely get it done for 1.3. Chris, would you file a ticket > and add the detail from your mailing list posts, if that hasn't > already been done? Done: http://scipy.org/scipy/numpy/ticket/909 ( By the way, is there a way to fix the typo in the ticket title? --oops!) There are a few fromfile() related tickets that I referenced as well. It's not totally straightforward what should be done, so I've included the text of the ticket here to start a discussion: Proposed Enhancements and bug fixes for fromfile() and fromstring() text handling: Motivation: The goal of the fromfile() text file handling capability is to enable users to write code that can read a lot of numbers from a text file into an array. Python provides a lot of nifty text processing capabilities, and there are a number of higher level facilities for reading blocks of data (including numpy.loadtxt). These are very capable, but there really is a significant performance hit, at least when loading 10s of thousands of numbers into a file. We don't want to write all of loadtxt() and friends in C. Rather, the goal is to allow the simple cases to be done very efficiently, and hopefully fancier text reading packages can build on it to add more features. Unfortunately, the current (numpy version 1.2) version has a few bugs and limitations that keep of from being nearly as useful as it could be. Possible features: * Create fromtextfile() and fromtextstring functions, distinct from fromfile() and fromstring(). It really is a different functionality. fromfile() could still call fromtextfile() for backward compatibility. * Allow more than one separator? for example, a comma or whitespace? In the general case, the user could perhaps specify any number of separators, though I doubt that would be useful in practice. At the very least, however, fromtextfile() should support reading files that look like: 43.5, 345.6, 123.456, 234.33 34.5, 22.57, 2345, 2345, 252 ... That is, comma separated, but being able to read multiple lines in one shot. The easiest way to support that would probably be to always allow whitespace as a separator, and add the one passed in. I can't think of a reason not to do this, but maybe I'm not very imaginative. * Allow the user to specify a shape for the output array. There may be little point, as all this does is save a calls to reshape(), but it may be another way to support the above. i.e. you could read that data with: a = np.fromtextfile(infile, dtype=np.float, sep=',', shape=(-1, 4)) Then it would know to skip the newlines every 4 elements. * Allow the user to specify a comment string. The reader would then skip everything in the file between the comment string and a newline. Maybe Universal newline -- any of \r, \n or \r\n. Or simply expect that the user has opened the file with mode 'U' if they want that. This could also be extended to support C-style comments with an opening and closing character sequence, but that's a lot less common. * Allow the user to specify a Locale. It may be best to be able to specify a locale, rather than relying on the system on (whether '.' or ',' is the decimal separator, for instance. (ticket #884) * parsing of "Inf" and the like that doesn't depend on system (ticket #510). This would be nice, but maybe too difficult -- would we need to write our own scanf? Bugs to be fixed: ¶ * fromfile() and fromstring handling malformed data poorly: ticket #883 * Any others? NOTE: my C is pretty lame, or I'd do some of this. I could help out with writing tests, etc. though. Thanks all, -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
