Re: [Numpy-discussion] numPy not imported into Python
Mark, Numpy is not numarray. Numarray is an older package that has long since been replaced by numpy. You should only use numpy in any development from now on. Chris On Wednesday, May 1, 2013, Mark Micklich wrote: Hello -- After installing numPy, I'm getting the following error message when attempting to import numarray: ImportError: No module named numarray I do have numPy installed. I'm running under Lubuntu 12.10 and the Spyder 2.1.10 IDE. I'm fairly new to developing Python on Linux. I assume there is some path issue, but I'm not clear where to start. If numPy is installed, how to I point Spyder to the numPy modules so I can get numarray to work? Thanks, Mark ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] numpy.scipy.org page 404s
Dear Numpy Webmasters, Would it be possible to either redirect numpy.scipy.org to www.numpy.org or to the main numpy github landing page? Currently numpy.scipy.org hits a Github 404 page. As the numpy.scipy.org site still shows up in searches it would be useful to have that address resolve to something more helpful. Thank you for your time and help, Chris ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.scipy.org page 404s
Thank you! On Fri, Apr 26, 2013 at 12:06 PM, Ognen Duzlevski og...@enthought.comwrote: Should be fixed now. Ognen On Fri, Apr 26, 2013 at 10:51 AM, Robert Kern robert.k...@gmail.comwrote: On Fri, Apr 26, 2013 at 4:44 PM, Andreas Hilboll li...@hilboll.de wrote: Unfortunately, Github can only deal with one CNAME, www.numpy.org. The documentation recommends that one redirect the other domains, but it's not clear exactly what it is referring to. Having an HTTP server with an A record for numpy.scipy.org that just issues HTTP 301 redirects for everything? I can look into getting that set up. https://help.github.com/articles/my-custom-domain-isn-t-working#multiple-domains-in-cname-file If I understand that correctly, you'll need to point the numpy.scipy.org CNAME to a non-github IP, and install a HTTP redirect **or** a HTTPD rewrite on that IP. So we need to find a server to do that. Probably easiest to ask numfocus, right? There's no need. We'll just use the existing www.scipy.org Apache server to host the redirects. Good. I have no clue about who operates which servers, and just assumed numfocus is doing that. Enthought hosts and administers the scipy.org domain. BTW, is there help needed in server administration (for numpy, scipy, or whatever)? I could happily volunteer to help out. Right now, the recurring cost is kicking the www.scipy.org wiki every once in a while under the deluge of spam. The best way to stop that is to help finish the migration of content to the new static site: https://github.com/scipy/scipy.org-new I think the major TODO items there are the conversion of the Topical Software and Cookbook pages. I can give dumps of the current wiki pages to anyone who wants to help with that. -- Robert Kern ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Remove support for numeric and numarray in 1.8
I'm all for a big scary warning on import. Fair warning is good for everyone, not just our developers. As for testing, our software that uses the API is tested nightly. So if our software stops working, and the compatibility layer is the cause, we would definitely be looking into what happened. :-) In any case, fair warning of dropped support in 1.8 and removal in 1.9 is fine with us. Thanks, Chris On Wed, Jan 9, 2013 at 6:38 PM, Nathaniel Smith n...@pobox.com wrote: On Wed, Jan 9, 2013 at 11:21 PM, Christopher Hanley chan...@gmail.com wrote: After poking around our code base and talking to a few folks I predict that we at STScI can remove our dependence on the numpy-numarray compatibility layer by the end of this calendar year. I'm unsure of what the timeline for numpy 1.8 is so I don't know if this schedule supports removal of the compatibility layer from 1.8 or not. It'd be nice if 1.8 were out before that, but that doesn't really matter -- let us know when you get it sorted? Also, would it help if we added a big scary warning at import time to annoy your more recalcitrant developers with? :-) The basic issue is that none of us actually use this stuff, it has no tests, the rest of numpy is changing around it, and we have no idea if it works, so at some point it makes more sense for us to just stop shipping the compat layer and let anyone who still needs it maintain their own copy of the code. -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Remove support for numeric and numarray in 1.8
After poking around our code base and talking to a few folks I predict that we at STScI can remove our dependence on the numpy-numarray compatibility layer by the end of this calendar year. I'm unsure of what the timeline for numpy 1.8 is so I don't know if this schedule supports removal of the compatibility layer from 1.8 or not. Thanks, Chris On Sat, Jan 5, 2013 at 9:38 PM, Charles R Harris charlesr.har...@gmail.comwrote: Thoughts? Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Support for python 2.4 dropped. Should we drop 2.5 also?
We (STScI) are ending support for Python 2.5 in our stsci_python project and told our users as much last July. I have no objections to ending support for Python 2.5. Chris On Thu, Dec 13, 2012 at 12:38 PM, Charles R Harris charlesr.har...@gmail.com wrote: The previous proposal to drop python 2.4 support garnered no opposition. How about dropping support for python 2.5 also? Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] bug in numpy.where?
On Fri, Jul 27, 2012 at 2:01 PM, Benjamin Root ben.r...@ou.edu wrote: On Thu, Jul 26, 2012 at 2:33 PM, Phil Hodge ho...@stsci.edu wrote: On a Linux machine: uname -srvop Linux 2.6.18-308.8.2.el5 #1 SMP Tue May 29 11:54:17 EDT 2012 x86_64 GNU/Linux this example shows an apparent problem with the where function: Python 2.7.1 (r271:86832, Dec 21 2010, 11:19:43) [GCC 4.1.2 20080704 (Red Hat 4.1.2-48)] on linux2 Type help, copyright, credits or license for more information. import numpy as np print np.__version__ 1.5.1 net = np.zeros(3, dtype='f4') net[1] = 0.00458849 net[2] = 0.605202 max_net = net.max() test = np.where(net = 0., max_net, net) print test [ -2.23910537e-35 4.58848989e-03 6.05202019e-01] When I specified the dtype for net as 'f8', test[0] was 3.46244974e+68. It worked as expected (i.e. test[0] should be 0.605202) when I specified float(max_net) as the second argument to np.where. Phil Confirmed with version 1.7.0.dev-470c857 on a CentOS6 64-bit machine. Strange indeed. Breaking it down further: res = (net = 0.) print res [ True False False] np.where(res, max_net, net) array([ -2.23910537e-35, 4.58848989e-03, 6.05202019e-01], dtype=float32) Very Strange... Ben Root What if find really interesting is that -2.23910537e-35 is the byte swapped version of 6.05202019e-01. Chris ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] bug in numpy.where?
On Fri, Jul 27, 2012 at 4:10 PM, Benjamin Root ben.r...@ou.edu wrote: On Fri, Jul 27, 2012 at 3:58 PM, Andreas Mueller amuel...@ais.uni-bonn.de wrote: Hi Everybody. The bug is that no error is raised, right? The docs say where(condition, [x, y]) x, y : array_like, optional Values from which to choose. `x` and `y` need to have the same shape as `condition` In the example you gave, x was a scalar. Cheers, Andy Hmm, that is incorrect, I believe. I have used a scalar before. Maybe it works because a scalar is broadcastable to the same shape as any other N-dim array? If so, then the wording of that docstring needs to be fixed. No, I think Christopher hit it on the head. For whatever reason, the endian-ness somewhere is not being respected and causes a byte-swapped version to show up. How that happens, though, is beyond me. Ben Root It may have something to do with the dtype size as well. The problem seen with, net = np.zeros(3, dtype='f4') Disappears for net = np.zeros(3, dtype='f8') and above. Chris ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposed Roadmap Overview
On Fri, Feb 17, 2012 at 3:38 PM, Ralf Gommers ralf.gomm...@googlemail.comwrote: On Fri, Feb 17, 2012 at 8:31 PM, Mark Wiebe mwwi...@gmail.com wrote: On Fri, Feb 17, 2012 at 11:00 AM, Christopher Jordan-Squire cjord...@uw.edu wrote: On Fri, Feb 17, 2012 at 10:21 AM, Mark Wiebe mwwi...@gmail.com wrote: On Fri, Feb 17, 2012 at 11:52 AM, Eric Firing efir...@hawaii.edu wrote: On 02/17/2012 05:39 AM, Charles R Harris wrote: On Fri, Feb 17, 2012 at 8:01 AM, David Cournapeau courn...@gmail.com mailto:courn...@gmail.com wrote: Hi Travis, On Thu, Feb 16, 2012 at 10:39 PM, Travis Oliphant tra...@continuum.io mailto:tra...@continuum.io wrote: Mark Wiebe and I have been discussing off and on (as well as talking with Charles) a good way forward to balance two competing desires: * addition of new features that are needed in NumPy * improving the code-base generally and moving towards a more maintainable NumPy I know there are load voices for just focusing on the second of these and avoiding the first until we have finished that. I recognize the need to improve the code base, but I will also be pushing for improvements to the feature-set and user experience in the process. As a result, I am proposing a rough outline for releases over the next year: * NumPy 1.7 to come out as soon as the serious bugs can be eliminated. Bryan, Francesc, Mark, and I are able to help triage some of those. * NumPy 1.8 to come out in July which will have as many ABI-compatible feature enhancements as we can add while improving test coverage and code cleanup. I will post to this list more details of what we plan to address with it later.Included for possible inclusion are: * resolving the NA/missing-data issues * finishing group-by * incorporating the start of label arrays * incorporating a meta-object * a few new dtypes (variable-length string, varialbe-length unicode and an enum type) * adding ufunc support for flexible dtypes and possibly structured arrays * allowing generalized ufuncs to work on more kinds of arrays besides just contiguous * improving the ability for NumPy to receive JIT-generated function pointers for ufuncs and other calculation opportunities * adding filters to Input and Output * simple computed fields for dtypes * accepting a Data-Type specification as a class or JSON file * work towards improving the dtype-addition mechanism * re-factoring of code so that it can compile with a C++ compiler and be minimally dependent on Python data-structures. This is a pretty exciting list of features. What is the rationale for code being compiled as C++ ? IMO, it will be difficult to do so without preventing useful C constructs, and without removing some of the existing features (like our use of C99 complex). The subset that is both C and C++ compatible is quite constraining. I'm in favor of this myself, C++ would allow a lot code cleanup and make it easier to provide an extensible base, I think it would be a natural fit with numpy. Of course, some C++ projects become tangled messes of inheritance, but I'd be very interested in seeing what a good C++ designer like Mark, intimately familiar with the numpy code base, could do. This opportunity might not come by again anytime soon and I think we should grab onto it. The initial step would be a release whose code that would compile in both C/C++, which mostly comes down to removing C++ keywords like 'new'. I did suggest running it by you for build issues, so please raise any you can think of. Note that MatPlotLib is in C++, so I don't think the problems are insurmountable. And choosing a set of compilers to support is something that will need to be done. It's true that matplotlib relies heavily on C++, both via the Agg library and in its own extension code. Personally, I don't like this; I think it raises the barrier to contributing. C++ is an order of magnitude more complicated than C--harder to read, and much harder to write, unless one is a true expert. In mpl it brings reliance on the CXX library, which Mike D. has had to help maintain. And if it does increase compiler specificity, that's bad. This gets to the recruitment issue, which is one of the most important problems I see numpy facing. I personally have contributed a lot of code to NumPy *in spite of* the fact it's in C. NumPy being in C instead of
Re: [Numpy-discussion] Developer NumPy list versus User NumPy list
On Thu, Jan 27, 2011 at 6:23 PM, Robert Kern robert.k...@gmail.com wrote: On Thu, Jan 27, 2011 at 17:17, Travis Oliphant teoliph...@gmail.com wrote: Hey all, What is the thought about having two separate NumPy lists (one for development discussions and one for user discussions)? We've resisted it for years. I don't think the split has done scipy much good. But that may just be my perspective because I'm subscribed to both and filter them both to the same folder. I do the same as Robert. I don't see much value in creating separate lists. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] numpy and the Google App Engine
Greetings, Google provides a product called App Engine. The description from their site follows, Google App Engine enables you to build and host web apps on the same systems that power Google applications. App Engine offers fast development and deployment; simple administration, with no need to worry about hardware, patches or backups; and effortless scalability. You can deploy applications written in either Python or JAVA. There are free and paid versions of the service. The Google App Engine would appear to be a powerful source of CPU cycles for scientific computing. Unfortunately this is currently not the case because numpy is not one of the supported libraries. The Python App Engine allows only the installation of user supplied pure Python code. I have recently returned from attending the Google I/O conference in San Francisco. While there I inquired into the possibility of getting numpy added. The basic response was that there doesn't appear to be much interest from the community given the amount of work it would take to vet and add numpy. I would like to ask your help in changing this perception. The quickest and easiest thing you can do would be to add your me too to this feature request (item #190) on the support site: http://code.google.com/p/googleappengine/issues/detail?id=190 If this issue is important to you could also consider raising this issue in the related Google Group: http://groups.google.com/group/google-appengine Letting Google know how you will use numpy would be helpful. If you or your institution would be willing to pay for service if you could deploy cloud applications that required numpy would be helpful to let them know as well. Finally, if you run into any App Engine developers (Guido included) let them know that you would like to see numpy added. Thank you for your time and consideration. Chris -- Christopher Hanley Senior Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [SciPy-Dev] numpy and the Google App Engine
On Wed, May 26, 2010 at 12:54 PM, Robert Kern robert.k...@gmail.com wrote: On Wed, May 26, 2010 at 12:19, Christopher Hanley chan...@stsci.edu wrote: Greetings, Google provides a product called App Engine. The description from their site follows, Google App Engine enables you to build and host web apps on the same systems that power Google applications. App Engine offers fast development and deployment; simple administration, with no need to worry about hardware, patches or backups; and effortless scalability. You can deploy applications written in either Python or JAVA. There are free and paid versions of the service. The Google App Engine would appear to be a powerful source of CPU cycles for scientific computing. Not really. It is not intended for such purposes. It is intended for the easy deployment and horizontal scaling of web applications. Each individual request is very short; it is limited to 10 seconds of CPU time. While numpy would be useful for scientific web applications (not least because it would help you keep to that 10 second limit when doing things like simple image processing or summary statistics or whatever), it is not a source of CPU cycles. Services like Amazon EC2 or Rackspace Cloud are much closer to what you want. PiCloud provides an even nicer interface for you: http://www.picloud.com/ In my conversations with the developers they indicated that it could be used for both. However, either use case would be useful for scientific computing. Disclosure: Enthought partners with PiCloud to provide most EPD libraries. I can't say I'm disinterested in promoting it, but it *is* a really powerful product that *does* provide CPU cycles for scientific computing with an interface much more suited to it than GAE. Unfortunately this is currently not the case because numpy is not one of the supported libraries. The Python App Engine allows only the installation of user supplied pure Python code. I have recently returned from attending the Google I/O conference in San Francisco. While there I inquired into the possibility of getting numpy added. The basic response was that there doesn't appear to be much interest from the community given the amount of work it would take to vet and add numpy. I would like to ask your help in changing this perception. The quickest and easiest thing you can do would be to add your me too to this feature request (item #190) on the support site: http://code.google.com/p/googleappengine/issues/detail?id=190 My understanding is that they hate me too comments. They ask that you star the issue instead. I would be happy to see any support either starring or me too comments. Their comments to me was that they saw no interest. In my opinion any indication of interest would be a positive. -- 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://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy and the Google App Engine
On Wed, May 26, 2010 at 12:49 PM, Dag Sverre Seljebotn da...@student.matnat.uio.no wrote: Christopher Hanley wrote: Greetings, Google provides a product called App Engine. The description from their site follows, Google App Engine enables you to build and host web apps on the same systems that power Google applications. App Engine offers fast development and deployment; simple administration, with no need to worry about hardware, patches or backups; and effortless scalability. You can deploy applications written in either Python or JAVA. There are free and paid versions of the service. The Google App Engine would appear to be a powerful source of CPU cycles for scientific computing. Unfortunately this is currently not the case because numpy is not one of the supported libraries. The Python App Engine allows only the installation of user supplied pure Python code. I have recently returned from attending the Google I/O conference in San Francisco. While there I inquired into the possibility of getting numpy added. The basic response was that there doesn't appear to be much interest from the community given the amount of work it would take to vet and add numpy. Something to keep in mind: It's rather trivial to write code to intentionally crash the Python interpreter using pure Python code and NumPy (or overwrite data in it, run custom assembly code...in short, NumPy is a big gaping security hole in this context). This obviously can't go on in the AppEngine. So this probably involves a considerable amount of work in the NumPy source code base as well, it's not simply about verifying. Agreed. Perhaps the recently discussed rework of the C internals will better allow a security audit of numpy. At that point perhaps the numpy community could more easily work with Google to fix security problems. -- Dag Sverre ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion -- Christopher Hanley Senior Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] chararray stripping trailing whitespace a bug?
On Mon, May 10, 2010 at 11:23 AM, Neil Crighton neilcrigh...@gmail.com wrote: I've been working with pyfits, which uses numpy chararrays. I've discovered the hard way that chararrays silently remove trailing whitespace: a = np.array(['a ']) b = a.view(np.chararray) a[0] 'a ' b[0] 'a' Note the string values stored in memory are unchanged. This behaviour caused a bug in a program I've been writing, and seems like a bad idea in general. Is it intentional? Neil This is an intentional feature, not a bug. Chris -- Christopher Hanley Senior Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Unit Tests failing daily for 2 months
Hi, I've been informed by our build/installation person that 3 unit tests have been failing in the daily numpy svn installation for the last 2 months. The most recent output from the tests is as follows: == FAIL: Test generic loops. -- Traceback (most recent call last): File /usr/stsci/pyssgdev/2.5.4/numpy/core/tests/test_ufunc.py, line 86, in test_generic_loops assert_almost_equal(fone(x), fone_val, err_msg=msg) File /usr/stsci/pyssgdev/2.5.4/numpy/testing/utils.py, line 435, in assert_almost_equal raise AssertionError(msg) AssertionError: Arrays are not almost equal PyUFunc_F_F ACTUAL: array([ 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j], dtype=complex64) DESIRED: 1 == FAIL: test_umath.TestComplexFunctions.test_loss_of_precision(type 'numpy.complex64',) -- Traceback (most recent call last): File /usr/stsci/pyssgdev/2.5.4/nose/case.py, line 183, in runTest self.test(*self.arg) File /usr/stsci/pyssgdev/2.5.4/numpy/core/tests/test_umath.py, line 721, in check_loss_of_precision check(x_basic, 2*eps/1e-3) File /usr/stsci/pyssgdev/2.5.4/numpy/core/tests/test_umath.py, line 691, in check 'arcsinh') AssertionError: (0, 0.0010023052, 0.9987238, 'arcsinh') == FAIL: test_umath.TestComplexFunctions.test_precisions_consistent -- Traceback (most recent call last): File /usr/stsci/pyssgdev/2.5.4/nose/case.py, line 183, in runTest self.test(*self.arg) File /usr/stsci/pyssgdev/2.5.4/numpy/core/tests/test_umath.py, line 602, in test_precisions_consistent assert_almost_equal(fcf, fcd, decimal=6, err_msg='fch-fcd %s'%f) File /usr/stsci/pyssgdev/2.5.4/numpy/testing/utils.py, line 435, in assert_almost_equal raise AssertionError(msg) AssertionError: Arrays are not almost equal fch-fcd ufunc 'arcsin' ACTUAL: 2.3561945j DESIRED: (0.66623943249251527+1.0612750619050355j) -- Ran 2512 tests in 18.753s FAILED (KNOWNFAIL=4, failures=3) Running unit tests for numpy NumPy version 2.0.0.dev8116 NumPy is installed in /usr/stsci/pyssgdev/2.5.4/numpy Python version 2.5.4 (r254:67916, Oct 26 2009, 14:36:20) [GCC 3.4.6 20060404 (Red Hat 3.4.6-11)] nose version 0.11.1 errors: failures: (Test(test_ufunc.TestUfunc testMethod=test_generic_loops), 'Traceback (most recent call last):\n File /usr/stsci/pyssgdev/2.5.4/numpy/core/tests/test_ufunc.py, line 86, in test_generic_loops\nassert_almost_equal(fone(x), fone_val, err_msg=msg)\n File /usr/stsci/pyssgdev/2.5.4/numpy/testing/utils.py, line 435, in assert_almost_equal\nraise AssertionError(msg)\nAssertionError: \nArrays are not almost equal PyUFunc_F_F\n ACTUAL: array([ 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j], dtype=complex64)\n DESIRED: 1\n') (Test(test_umath.TestComplexFunctions.test_loss_of_precision(type 'numpy.complex64',)), 'Traceback (most recent call last):\n File /usr/stsci/pyssgdev/2.5.4/nose/case.py, line 183, in runTest\n self.test(*self.arg)\n File /usr/stsci/pyssgdev/2.5.4/numpy/core/tests/test_umath.py, line 721, in check_loss_of_precision\ncheck(x_basic, 2*eps/1e-3)\n File /usr/stsci/pyssgdev/2.5.4/numpy/core/tests/test_umath.py, line 691, in check\n\'arcsinh\')\nAssertionError: (0, 0.0010023052, 0.9987238, \'arcsinh\')\n') (Test(test_umath.TestComplexFunctions.test_precisions_consistent), 'Traceback (most recent call last):\n File /usr/stsci/pyssgdev/2.5.4/nose/case.py, line 183, in runTest\n self.test(*self.arg)\n File /usr/stsci/pyssgdev/2.5.4/numpy/core/tests/test_umath.py, line 602, in test_precisions_consistent\nassert_almost_equal(fcf, fcd, decimal=6, err_msg=\'fch-fcd %s\'%f)\n File /usr/stsci/pyssgdev/2.5.4/numpy/testing/utils.py, line 435, in assert_almost_equal\nraise AssertionError(msg)\nAssertionError: \nArrays are not almost equal fch-fcd ufunc \'arcsin\'\n ACTUAL: 2.3561945j\n DESIRED: (0.66623943249251527+1.0612750619050355j)\n') -- These failing tests are logged in Trac ticket numbers 1323, 1324, and 1325 respectively. Is anyone else seeing these failures? Any idea what the problem may be? It appears this problem is limited to 64-bit RHE 4 systems. Thank you for your time and help, Chris -- Christopher Hanley Senior Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Unit Tests failing daily for 2 months
I don't see these here. What architecture/compiler/os ? The system architecture is 2 * Intel Xeon with hyperthreading. The OS is Red Hat Enterprise (RHE) 4 64-bit running Python 2.5.4. The C compiler being used is GCC 3.4.6. No Fortran compiler is being used. That's new to me. Darn. I was hoping this was old news. These two also fail on the buildbot Mac and have for some time. If you are able to reproduce them on an available machine that will be helpful in tracking them down. We can reproduce these problems on our RHE machine. A quick check of our logs from last night doesn't seem to indicate a problem on our Intel Mac 10.5 systems. However if there is something you want me to try just let me know what you need. Thanks, Chris -- Christopher Hanley Senior Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Moved matrix class into separate module
Hi, When I try running the tests on a fresh build from the trunk I receive 28 errors. Most of the errors are of the form: NameError: global name 'matrix' is not defined It looks like there was some change to the numpy namespace. I can provide a full listing of the unit test errors if desired. This is on my MacBook Pro running Python 2.5 on OS X 10.5. Chris -- Christopher Hanley Senior Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 On Sep 16, 2009, at 2:56 AM, David Cournapeau wrote: Hi, I just wanted to mention I integrated a patch from some time ago to make numpy.core independent from other numpy modules. This is really useful when working on involved changes at the C level. This meant moving some stuff around, in particular the matrix class and utilities is now into numpy.matrixclass module. The numpy namespace is of course unchanged. cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Moved matrix class into separate module
My apologizes. I had remembered to remove the previous build directory but not the target installation directory. After having removed all traces of the previous numpy installation and do a clean install I receive no new errors. Sorry for the false alarm. Chris -- Christopher Hanley Senior Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 On Sep 16, 2009, at 11:51 AM, David Cournapeau wrote: On Thu, Sep 17, 2009 at 12:32 AM, Christopher Hanley chan...@stsci.edu wrote: Hi, When I try running the tests on a fresh build from the trunk I receive 28 errors. Most of the errors are of the form: NameError: global name 'matrix' is not defined It looks like there was some change to the numpy namespace. I can provide a full listing of the unit test errors if desired. Yes please - I do not see those errors on both mac os x and linux. You should also make sure that your svn checkout, build and install directories are not polluted by old cruft. David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] numpy on OSX 10.6 issues
Hi, I'm looking for some help getting the svn trunk numpy working on Max OS X 10.6. I've installed my own version of Python 2.6 from python.org. I've got the following flags set: setenv MACOSX_DEPLOYMENT_TARGET 10.6 setenv CFLAGS -arch i386 -arch x86_64 setenv FFLAGS -arch i386 -arch x86_64 setenv LDFLAGS -Wall -undefined dynamic_lookup -bundle -arch i386 -arch x86_64 The build seems to complete with no errors. However when I attempt to import numpy I get the following error: Python 2.6.2 (r262:71600, Apr 16 2009, 09:17:39) [GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin Type help, copyright, credits or license for more information. import numpy Traceback (most recent call last): File stdin, line 1, in module File /Users/chanley/dev/site-packages/lib/python/numpy/__init__.py, line 130 , in module import add_newdocs File /Users/chanley/dev/site-packages/lib/python/numpy/add_newdocs.py, line 9, in module from lib import add_newdoc File /Users/chanley/dev/site-packages/lib/python/numpy/lib/__init__.py, line 4, in module from type_check import * File /Users/chanley/dev/site-packages/lib/python/numpy/lib/type_check.py, li ne 8, in module import numpy.core.numeric as _nx File /Users/chanley/dev/site-packages/lib/python/numpy/core/__init__.py, lin e 8, in module import numerictypes as nt File /Users/chanley/dev/site-packages/lib/python/numpy/core/numerictypes.py, line 600, in module _typestr[key] = empty((1,),key).dtype.str[1:] ValueError: array is too big. Any suggestions? Thank you for your time and help, Chris -- Christopher Hanley Senior Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] numpy rev7353 w/ OS X 10.6
self.run_command('build')
File
/usr/stsci/pyssgdev/Python-2.5.1/lib/python2.5/distutils/cmd.py, line
333, in run_command
self.distribution.run_command(command)
File
/usr/stsci/pyssgdev/Python-2.5.1/lib/python2.5/distutils/dist.py, line
994, in run_command
cmd_obj.run()
File /Users/chanley/dev/numpy/numpy/distutils/command/build.py, line
37, in run
old_build.run(self)
File
/usr/stsci/pyssgdev/Python-2.5.1/lib/python2.5/distutils/command/build.py,
line 112, in run
self.run_command(cmd_name)
File
/usr/stsci/pyssgdev/Python-2.5.1/lib/python2.5/distutils/cmd.py, line
333, in run_command
self.distribution.run_command(command)
File
/usr/stsci/pyssgdev/Python-2.5.1/lib/python2.5/distutils/dist.py, line
994, in run_command
cmd_obj.run()
File /Users/chanley/dev/numpy/numpy/distutils/command/build_src.py,
line 151, in run
self.build_sources()
File /Users/chanley/dev/numpy/numpy/distutils/command/build_src.py,
line 162, in build_sources
self.build_library_sources(*libname_info)
File /Users/chanley/dev/numpy/numpy/distutils/command/build_src.py,
line 297, in build_library_sources
sources = self.generate_sources(sources, (lib_name, build_info))
File /Users/chanley/dev/numpy/numpy/distutils/command/build_src.py,
line 384, in generate_sources
source = func(extension, build_dir)
File numpy/core/setup.py, line 590, in get_mathlib_info
mlibs = check_mathlib(config_cmd)
File numpy/core/setup.py, line 283, in check_mathlib
raise EnvironmentError(math library missing; rerun
EnvironmentError: math library missing; rerun setup.py after setting the
MATHLIB env variable
Does Python need to be rebuild? I was using 2.5 I downloaded from
python.org.
Thanks,
Chris
--
Christopher Hanley
Senior Systems Software Engineer
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21218
(410) 338-4338
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy rev7353 w/ OS X 10.6
Robert Kern wrote: On Tue, Sep 1, 2009 at 21:35, Christopher Hanleychan...@stsci.edu wrote: Hi, Upgraded to Snow Leopard, left setup.py and all environment variables the same, tried latest numpy from source. This is the build error I receive: C compiler: cc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -O3 -Wall -Wstrict-prototypes compile options: '-Inumpy/core/src -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/usr/stsci/pyssgdev/Python-2.5.1/include/python2.5 -c' cc: _configtest.c sh: cc: command not found Do you have a CC environment variable set incorrectly to cc? Yes. But that appears to only be a symptom. It appears that my entire XCode installation has disappeared. Perhaps that is how all that space was freed on my system. ;-) Grr. OK. Ignore my message. I am going to have to reset and start again. Thanks, Chris -- Christopher Hanley Senior Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Deprecate chararray [was [SciPy-dev] Plea for help]
Here is what I know about the chararray usage at STScI since first looking into it this morning. It is used in PyFITS and within the COS instrument calibration code. I have not heard back from the other projects yet given most of our developers are away at this time. It appears that the COS code can be changed easily. I am waiting to hear back from PyFITs. Also, I do not know how many people use this particular feature. However I would point out that many people who use numpy are not also on the mailing lists. Most of the STScI do not follow the numpy list. I serve as our point of contact to the numpy community. I'm trying to gather a list of projects that use this feature and specific use cases for you. As I do not use this module myself I cannot counter your arguments at this time. If we decide to deprecate this module would we reverse this decision if we then find out that the assumptions that went into the decision were in error? Another concern is that we told people coming from numarray to use this module. It is my opinion that at this point in the numpy release cycle that an API change needs a very strong justification. Anecdotes about the number of users, a change or die philosophy, and an un- articulated notion of the spirit of numpy do not in my consideration meet that high bar. If you would like us to provide additional documentation and tests that would be possible. I'll do it myself if that is the only think keeping the module from remaining in numpy. This also raises the question of what else is going to go? Will recarray be removed? What about the numarray c-api compatibility layer? Like I said earlier, I'm not opposed to change. I am just of the opinion that this isn't a simple, cut and dry decision. For those at SciPy 2009 feel free to come yell at me and beat me with sticks. I'm the fat guy in jeans and a blue shirt sitting towards the back middle on the left. Cheers, Chris -- Christopher Hanley Senior Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 On Aug 20, 2009, at 12:27 PM, David Goldsmith wrote: --- On Thu, 8/20/09, Christopher Hanley chan...@stsci.edu wrote: I'd like to respectfully request that we move any discussion of what to do with the numpy.char module to the numpy list. NP, done. I'm a little concerned about some of the assumptions that are being made about the number of users of the module. I would also like to better understand the reasons for wanting to dump it. I think Ralf did a pretty good job of synopsizing the reasons for deprecation, but since we're moving the thread, I'll reprint them here: 0) it gets very little use (an assumption you presumably dispute); 1) is pretty much undocumented (less true than a week ago, but still true for several of the attributes, with another handful or so falling into the category of poorly documented); 2) probably more buggy than most other parts of NumPy (probably being a euphemism, IMO); 3) there is not a really good use-case for it (a conjecture, but one that has yet to be challenged by counter-example); 4) it's not the first time its presence in NumPy has been questioned (as Stefan pointed out when asking this same question last year) 5) NumPy already has a (perhaps superior) alternative (object arrays would do nicely if one needs this functionality); to which I'll add: 6) it is, on its face, counter to the spirit of NumPy. So far, IIRC, the only reason in favor of its continued inclusion is inertia. Let me be clear. I'm not opposed to change. However breaking other people's code just for the sake of change seems like a poor reason So, I don't think we're proposing this just for the sake of change and a mean thing to do to our customers. Apologies, but it is not proposed maliciously. The only other things I would add by way of review from the scipy- dev thread: a compromise proposal (made by Ralf): Put clearly in the docs that this module exists for backwards compatibility reasons, and is not recommended for new development and a clarification of deprecation process (provided by Robert): [asked by the present author] How has deprecation in Numpy worked in the past - by dictum, vote, or consensus? [Robert's answer] Consensus or dictum without major objection. Voting is pointless except to inform one of those. Thanks for your time and consideration. David Goldsmith Thank you for your time and help, Chris -- Christopher Hanley Senior Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 On Aug 20, 2009, at 1:35 AM, Robert Kern wrote: On Wed, Aug 19, 2009 at 20:03, David Goldsmithd_l_goldsm...@yahoo.com wrote: I'm going to take it a step further: breakage is always the deterrent to change, and yet
[Numpy-discussion] Removing scipy.stsci was [Re: [SciPy-dev] Deprecate chararray [was Plea for help]]
I agree with David's comments. In that theme I have removed scipy.stsci from scipy. Users get it directly from us at STScI via STSCI_PYTHON. It doesn't have any documentation in the doc system. It isn't by default in the scipy namespace. And as a recent bug report indicates they can't import it anyway. That should clean some code up. If someday a generic image processing library is added to scipy we can consider incorporating our modules back into scipy. Until that time I would rather remove the redundancy. It also help scipy's maintainability and frees me from having to worry about a fork in the code developing. Cheers, Chris -- Christopher Hanley Senior Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 On Aug 20, 2009, at 3:04 PM, David Cournapeau wrote: On Thu, Aug 20, 2009 at 10:32 AM, Christopher Hanleychan...@stsci.edu wrote: I agree those are not strong reasons without more backing. What worries me the most, in both numpy and scipy, is code that nobody knows about, without any test or documentation. When it breaks, we can't fix it. That's unsustainable in the long term, because it takes a lot of time that people could spend somewhere else more useful. Especially when you have C code which does not work on some platforms, with new version of python (python 3k port, for example). I much prefer removing code to having code that barely works and cannot be maintained. Old code that people are ready to maintain, I have nothing against. cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Removing scipy.stsci was [Re: [SciPy-dev] Deprecate chararray [was Plea for help]]
On Aug 20, 2009, at 7:48 PM, Stéfan van der Walt wrote: Hi Stefan, We'll be spriting on an Image Processing Scikit this weekend. If you have any functions you'd like to include, let me know. Regards Stéfan Will the Image Processing Scikit be dedicated to working with a single image or stacks of images? Cheers, Chris ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Removing scipy.stsci was [Re: [SciPy-dev] Deprecate chararray [was Plea for help]]
Hi Stefan, Never mind. I just found the Sprint website and read the description. I'm sorry I hadn't found this sooner. I would have made plans to stay and help. My apologizes. Sorry, Chris -- Christopher Hanley Senior Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 On Aug 20, 2009, at 7:51 PM, Christopher Hanley wrote: On Aug 20, 2009, at 7:48 PM, Stéfan van der Walt wrote: Hi Stefan, We'll be spriting on an Image Processing Scikit this weekend. If you have any functions you'd like to include, let me know. Regards Stéfan Will the Image Processing Scikit be dedicated to working with a single image or stacks of images? Cheers, Chris ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Test failures for rev7299
Hi, I receive the following test errors after building numpy rev7229 from svn: == FAIL: test_simple_circular (test_multiarray.TestStackedNeighborhoodIter) -- Traceback (most recent call last): File /Users/chanley/dev/site-packages/lib/python/numpy/core/tests/test_multia rray.py, line 1344, in test_simple_circular assert_array_equal(l, r) File /Users/chanley/dev/site-packages/lib/python/numpy/testing/utils.py, lin e 639, in assert_array_equal verbose=verbose, header='Arrays are not equal') File /Users/chanley/dev/site-packages/lib/python/numpy/testing/utils.py, lin e 571, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not equal (mismatch 6.667%) x: array([[ 0., 1., 2.], [ 1., 2., 3.], [ 2., 3., 0.],... y: array([[ 0., 1., 2.], [ 1., 2., 3.], [ 2., 3., 0.],... == FAIL: test_simple_mirror (test_multiarray.TestStackedNeighborhoodIter) -- Traceback (most recent call last): File /Users/chanley/dev/site-packages/lib/python/numpy/core/tests/test_multia rray.py, line 1296, in test_simple_mirror assert_array_equal(l, r) File /Users/chanley/dev/site-packages/lib/python/numpy/testing/utils.py, lin e 639, in assert_array_equal verbose=verbose, header='Arrays are not equal') File /Users/chanley/dev/site-packages/lib/python/numpy/testing/utils.py, lin e 571, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not equal (mismatch 6.667%) x: array([[ 0., 1., 2.], [ 1., 2., 3.], [ 2., 3., 0.],... y: array([[ 0., 1., 2.], [ 1., 2., 3.], [ 2., 3., 0.],... -- Ran 2186 tests in 10.671s FAILED (KNOWNFAIL=1, SKIP=3, failures=2) nose.result.TextTestResult run=2186 errors=0 failures=2 I'm running on an Intel MacBook Pro running OS X 10.5.8. I am using Python 2.5.1. Chris -- Christopher Hanley Senior Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Tabs in numpy-1.3
Hi, Our nightly build system has been detecting tabs in the recent versions of numpy. The following files appear to have issues: Checked out revision 6870. svn checkout ok PYTHON FILES INDENTED WITH TABS: ./numpy/numpy/distutils/fcompiler/compaq.py ./numpy/numpy/distutils/command/build_ext.py ./numpy/numpy/distutils/misc_util.py ./numpy/numpy/core/tests/test_scalarmath.py ./numpy/numpy/core/setup.py ./numpy/pavement.py tab check failed Chris -- Christopher Hanley Senior Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] new numpy error in 1.3.0.dev6618
== ERROR: test_float_repr (test_scalarmath.TestRepr) -- Traceback (most recent call last): File /Users/chanley/dev/site-packages/lib/python/numpy/core/tests/test_scalarmath.py, line 101, in test_float_repr val2 = t(eval(val_repr)) File string, line 1, in module NameError: name 'nan' is not defined -- Ran 2018 tests in 10.311s FAILED (KNOWNFAIL=1, SKIP=1, errors=1) nose.result.TextTestResult run=2018 errors=1 failures=0 numpy.__version__ '1.3.0.dev6618' This was run on a Intel Mac running OS X 10.5.6. Chris -- Christopher Hanley Senior Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposed schedule for numpy 1.3.0
Pierre GM wrote: David, I also started to update the release notes: http://projects.scipy.org/scipy/numpy/browser/trunk/doc/release/1.3.0-notes.rst I get a 404. Anyhow, on the ma side: * structured arrays should now be fully supported by MaskedArray (r6463, r6324, r6305, r6300, r6294...) * Minor bug fixes (r6356, r6352, r6335, r6299, r6298) * Improved support for __iter__ (r6326) * made baseclass, sharedmask and hardmask accesible to the user (but read-only) + doc update I also received a 404. However it is available in svn (numpy/doc/release). Chris -- Christopher Hanley Senior Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Solaris 8, 32 bit python issue
This problem is on a 32bit Solaris 8 system. == FAIL: Test find_duplicates -- Traceback (most recent call last): File /usr/ra/pyssg/2.5.1/numpy/lib/tests/test_recfunctions.py, line 150, in test_find_duplicates assert_equal(test[-1], control) File /usr/stsci/pyssgdev/2.5.1/numpy/ma/testutils.py, line 121, in assert_equal return assert_array_equal(actual, desired, err_msg) File /usr/stsci/pyssgdev/2.5.1/numpy/ma/testutils.py, line 193, in assert_array_equal header='Arrays are not equal') File /usr/stsci/pyssgdev/2.5.1/numpy/ma/testutils.py, line 186, in assert_array_compare verbose=verbose, header=header) File /usr/stsci/pyssgdev/2.5.1/numpy/testing/utils.py, line 295, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not equal (mismatch 100.0%) x: array([2, 0]) y: array([0, 2]) -- Ran 1899 tests in 99.598s -- Christopher Hanley Senior Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] change made to test_print.py
David Cournapeau wrote: On Fri, Jan 9, 2009 at 5:11 AM, Christopher Hanley chan...@stsci.edu wrote: David Cournapeau wrote: On Fri, Jan 9, 2009 at 4:29 AM, Christopher Hanley chan...@stsci.edu wrote: David Cournapeau wrote: On Fri, Jan 9, 2009 at 1:37 AM, Christopher Hanley chan...@stsci.edu wrote: Hi, I've committed the following change to test_print.py to fix one of the tests. Hi Christopher, Please do not modify those tests - they are supposed to fail, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion Hi David, Sorry. Should these tests be generating a known failures then? No. The problem are known, and are being fixed (in a branch). Since the problem is only in the development trunk, I don't see any problem with having failures for some time, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion I would disagree. If you were to attempt the following: n = numpy.test() n.wasSuccessful() You expect the result to be 'True'. If not it is necessary to find out why. Right now the following occurs: n.wasSuccessful() False I have no way of knowing that you wanted those tests to fail unless you have them marked as KNOWNFAIL. Since we use numpy in our production systems I need to determine why numpy is failing. We track the changes on the trunk because we need to know how changes will effect our code prior to our customers downloading the latest numpy release. I don't understand: you can't expect the trunk to always work. We try not to break it - but sometimes it does not work. Personally, I don't like knownfailure much anyway: I feel like it is too easy to tag one test known failure, and then nobody cares about it anymore. Those formatting problems were already problems before - the tests only show the problem, it does not cause the problem, so I don't understand why it is so important: a 100 % running test suite with a problem which is not shown or a 95 % running test suite with the problem is the same thing; the code in numpy itself is exactly the same. David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion I do not expect the trunk to always work. I even expect it to have bugs. However, I do not expect there to be test failures for known reasons that result in wasSuccessful() returning false. This is a bad programming practice. It creates work for people trying to figure out what is wrong when the answer is already know. Chris -- Christopher Hanley Senior Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] svn numpy selftests fail on Solaris
This has apparently been occurring for a few days. My apologizes but I have been away on vacation. FAILED (failures=5) Running unit tests for numpy NumPy version 1.2.0.dev5565 NumPy is installed in /usr/ra/pyssg/2.5.1/numpy Python version 2.5.1 (r251:54863, Jun 4 2008, 15:48:19) [C] nose version 0.10.0 ctypes is not available on this python: skipping the test (import error was: ctypes is not available.) No distutils available, skipping test. errors: failures: (Test(test_umath.TestC99.test_cacos(ufunc 'arccos', (1.0, NaN), (NaN, NaN), 'invalid-optional')), 'Traceback (most recent call last):\n File /usr/stsci/pyssgdev/2.5.1/nose/case.py, line 202, in runTest\n self.test(*self.arg)\n File /usr/ra/pyssg/2.5.1/numpy/core/tests/test_umath.py, line 393, in _check\nassert got == expected, (got, expected)\nAssertionError: (\'(-NaN, -NaN)\', \'(NaN, NaN)\')\n') (Test(test_umath.TestC99.test_cacos(ufunc 'arccos', (NaN, 1.0), (NaN, NaN), 'invalid-optional')), 'Traceback (most recent call last):\n File /usr/stsci/pyssgdev/2.5.1/nose/case.py, line 202, in runTest\n self.test(*self.arg)\n File /usr/ra/pyssg/2.5.1/numpy/core/tests/test_umath.py, line 393, in _check\nassert got == expected, (got, expected)\nAssertionError: (\'(-NaN, -NaN)\', \'(NaN, NaN)\')\n') (Test(test_umath.TestC99.test_cacosh(ufunc 'arccosh', (1.0, NaN), (NaN, NaN), 'invalid-optional')), 'Traceback (most recent call last):\n File /usr/stsci/pyssgdev/2.5.1/nose/case.py, line 202, in runTest\n self.test(*self.arg)\n File /usr/ra/pyssg/2.5.1/numpy/core/tests/test_umath.py, line 393, in _check\nassert got == expected, (got, expected)\nAssertionError: (\'(NaN, -NaN)\', \'(NaN, NaN)\')\n') (Test(test_umath.TestC99.test_casinh(ufunc 'arcsinh', (NaN, 1.0), (NaN, NaN), 'invalid-optional')), 'Traceback (most recent call last):\n File /usr/stsci/pyssgdev/2.5.1/nose/case.py, line 202, in runTest\n self.test(*self.arg)\n File /usr/ra/pyssg/2.5.1/numpy/core/tests/test_umath.py, line 393, in _check\nassert got == expected, (got, expected)\nAssertionError: (\'(NaN, -NaN)\', \'(NaN, NaN)\')\n') (Test(test_umath.TestC99.test_clog(ufunc 'log', (-0.0, -0.0), (-Infinity, 3.1415926535897931), 'divide')), 'Traceback (most recent call last):\n File /usr/stsci/pyssgdev/2.5.1/nose/case.py, line 202, in runTest\nself.test(*self.arg)\n File /usr/ra/pyssg/2.5.1/numpy/core/tests/test_umath.py, line 393, in _check\nassert got == expected, (got, expected)\nAssertionError: (\'(-Infinity, 0.0)\', \'(-Infinity, 3.1415926535897931)\')\n') -- Christopher Hanley Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Documenting chararrays
Stéfan van der Walt wrote: Hi all, Should we document character arrays? Does anybody still use them? I think their behaviour can largely be duplicated by object arrays. They also seem to be broken: x = np.array(['1', '2', '3', '4']).view(np.chararray) x*3 chararray(['111', '222', '333', '444'], dtype='|S4') All good, but: x = np.array(['12', '34', '56', '78']).view(np.chararray) x * 3 chararray(['1212', '3434', '5656', '7878'], dtype='|S4') Whereas with object arrays: np.array(['12', '34', '56', '78'], dtype=object) * 3 array([121212, 343434, 565656, 787878], dtype=object) Similaryly: x.rjust(3) chararray([' a', ' b', ' c', ' d'], dtype='|S3') x = np.array(['a','b','c','d']).view(np.chararray) x.rjust(3) chararray([' a', ' b', ' c', ' d'], dtype='|S3') But then x = np.array([['ab','cd'], ['ef','gh']]).view(np.chararray) x.rjust(5) # BOOM Cheers Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion I know that chararrays are used by pyfits. Chris -- Christopher Hanley Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] new chararray test fails on Mac OS X
From the svn log it looks like the tests are intended to fail? However I would prefer tests that are designed only to fail when problems occur. Otherwise we end up with problems with our automatic build and test scripts. Thanks, Chris == FAIL: test_mul (test_defchararray.TestOperations) -- Traceback (most recent call last): File /Users/chanley/dev/site-packages/lib/python/numpy/core/tests/test_defcha rarray.py, line 49, in test_mul assert all(Ar == (self.A * r)) AssertionError == FAIL: test_rmul (test_defchararray.TestOperations) -- Traceback (most recent call last): File /Users/chanley/dev/site-packages/lib/python/numpy/core/tests/test_defcha rarray.py, line 65, in test_rmul assert all(Ar == (r * self.A)) AssertionError -- Ran 1930 tests in 13.130s FAILED (failures=2) nose.result.TextTestResult run=1930 errors=0 failures=2 n.__version__ '1.2.0.dev5385' -- Christopher Hanley Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Record arrays
Perry Greenfield wrote: Hi Chris, Didn't we remove all dependence on recarray? I could have sworn we did that. Perry Perry, You are right. We no longer import the recarray module from numpy. Chris -- Christopher Hanley Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Record arrays
Stéfan van der Walt wrote: Hi all, I am documenting `recarray`, and have a question: Is its use still recommended, or has it been superseded by fancy data-types? Regards Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion I would say that it has been superseded by fancy data-types. It is necessary that recarray remain for backward compatibility with large, legacy numarray projects. However, I would encourage all new code be written with the native object arrays. Chris -- Christopher Hanley Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Record arrays
Travis E. Oliphant wrote: Stéfan van der Walt wrote: Hi all, I am documenting `recarray`, and have a question: Is its use still recommended, or has it been superseded by fancy data-types? I rarely recommend it's use (but some people do like attribute access to the fields).It is wrong, however, to say that recarray has been superseded by fancy data types because fancy data types have existed for as long as recarrays. I believe pyfits uses them quite a bit, and so they deserve to be documented. -Travis ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion Travis is correct. PyFITS uses recarrays quite extensively. It was the large, legacy numarray project I was referring too. ;-) I had forgotten about the attribute access. I know a number of people who use that feature in conjunction with matplotlib for plotting data in tables, especially during interactive use. Chris -- Christopher Hanley Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] nose test return values
Hi, I have received the following message from our system guru here at STScI regarding the recent changes to the way testing is done with nose. The automated scripts he was using to monitor the success or failure of numpy builds is now broken. Below is his message: The new numpy test interface returns None instead of unittest._TextTestResult Even if you don't want to return unittest objects, the test should return some indication of which tests failed, which could not be run due to errors (a test that failed is different from a test that couldn't even run), and whether the test suite as a whole can be considered passing. For my purposes, the wasSuccessful() method of the returned object is absolutely essential. If wasSuccessful() returns true, I am not going to look at the numpy tests; if it returns false, somebody has to find which tests failed and decide whether that is going to affect the other developers. OLD: n=numpy.test(level=10) ...lots out output... n unittest._TextTestResult run=693 errors=0 failures=0 n.errors [] n.failures [] n.wasSuccessful() True NEW: n = numpy.test(label=full, verbose=0) n print n None numpy.__version__ '1.2.0.dev5292' My application: import sys import numpy n = numpy.test(level=10) print errors: for x in n.errors: print ,x print failures: for x in n.failures: print ,x if n.wasSuccessful() : sys.exit(0) else : sys.exit(1) Of course, these same comments will apply to scipy when I next install it. -- I believe that he makes a very good point. Is there any way that some form of test report object can be returned? Thanks, Chris -- Christopher Hanley Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nose test return values
Alan McIntyre wrote: On Wed, Jun 18, 2008 at 12:21 PM, Christopher Hanley [EMAIL PROTECTED] wrote: I have received the following message from our system guru here at STScI regarding the recent changes to the way testing is done with nose. The automated scripts he was using to monitor the success or failure of numpy builds is now broken. Below is his message: The new numpy test interface returns None instead of unittest._TextTestResult snip I believe that he makes a very good point. Is there any way that some form of test report object can be returned? I'll see if I can make that work correctly. The buildbots currently depend on this behavior as well. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion Thanks! Chris -- Christopher Hanley Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] [Fwd: Re: [NumPy] #770: numpy.core.tests.test_multiarray.TestView failures on big-endian machines]
Just forwarding this to the main list since the Trac mailer still seems
to be broken.
Chris
--
Christopher Hanley
Systems Software Engineer
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21218
(410) 338-4338
---BeginMessage---
#770: numpy.core.tests.test_multiarray.TestView failures on big-endian machines
+---
Reporter: chanley |Owner: somebody
Type: defect | Status: reopened
Priority: normal |Milestone: 1.1.0
Component: numpy.core | Version: devel
Severity: normal | Resolution:
Keywords: big-endian |
+---
Changes (by chanley):
* status: closed = reopened
* resolution: fixed =
Comment:
This has not been fixed as of 1.1.0dev5211 on either our Sun running
Solaris 10 or our PPC MAC running 10.4.11. Here is the output from the
seltest:
{{{
Numpy version 1.1.0.dev5211
Python version 2.5.1 (r251:54863, Jan 21 2008, 11:03:00) [C]
Found 18/18 tests for numpy.core.defmatrix
Found 3/3 tests for numpy.core.memmap
Found 283/283 tests for numpy.core.multiarray
Found 70/70 tests for numpy.core.numeric
Found 36/36 tests for numpy.core.numerictypes
Found 12/12 tests for numpy.core.records
Found 7/7 tests for numpy.core.scalarmath
Found 16/16 tests for numpy.core.umath
Found 5/5 tests for numpy.distutils.misc_util
Found 2/2 tests for numpy.fft.fftpack
Found 3/3 tests for numpy.fft.helper
Found 24/24 tests for numpy.lib._datasource
Found 10/10 tests for numpy.lib.arraysetops
Found 1/1 tests for numpy.lib.financial
Found 0/0 tests for numpy.lib.format
Found 53/53 tests for numpy.lib.function_base
Found 6/6 tests for numpy.lib.getlimits
Found 6/6 tests for numpy.lib.index_tricks
Found 15/15 tests for numpy.lib.io
Found 1/1 tests for numpy.lib.machar
Found 4/4 tests for numpy.lib.polynomial
Found 49/49 tests for numpy.lib.shape_base
Found 15/15 tests for numpy.lib.twodim_base
Found 43/43 tests for numpy.lib.type_check
Found 1/1 tests for numpy.lib.ufunclike
Found 89/89 tests for numpy.linalg
Found 94/94 tests for numpy.ma.core
Found 15/15 tests for numpy.ma.extras
Found 7/7 tests for numpy.random
Found 16/16 tests for numpy.testing.utils
Found 0/0 tests for __main__
.FF.
==
FAIL: test_basic (numpy.core.tests.test_multiarray.TestView)
--
Traceback (most recent call last):
File /usr/ra/pyssg/2.5.1/numpy/core/tests/test_multiarray.py, line
843, in test_basic
assert_array_equal(y,z)
File /usr/stsci/pyssgdev/2.5.1/numpy/testing/utils.py, line 248, in
assert_array_equal
verbose=verbose, header='Arrays are not equal')
File /usr/stsci/pyssgdev/2.5.1/numpy/testing/utils.py, line 240, in
assert_array_compare
assert cond, msg
AssertionError:
Arrays are not equal
(mismatch 100.0%)
x: array([ 67305985, 134678021])
y: array([16909060, 84281096])
==
FAIL: test_keywords (numpy.core.tests.test_multiarray.TestView)
--
Traceback (most recent call last):
File /usr/ra/pyssg/2.5.1/numpy/core/tests/test_multiarray.py, line
857, in test_keywords
assert_equal(y.dtype,np.int16)
File /usr/stsci/pyssgdev/2.5.1/numpy/testing/utils.py, line 145, in
assert_equal
assert desired == actual, msg
AssertionError:
Items are not equal:
ACTUAL: dtype('i2')
DESIRED: type 'numpy.int16'
--
Ran 1000 tests in 21.171s
FAILED (failures=2)
errors:
failures:
(numpy.core.tests.test_multiarray.TestView
testMethod=test_basic
Re: [Numpy-discussion] Going toward time-based release ?
Jarrod Millman wrote: I can't imagine why anyone would have to upgrade. Could you explain under what circumstances you would see having to upgrade just because their is a new upstream release? I think I must be misunderstanding your concern. One circumstance in which you would need to upgrade is if you distribute software with a numpy dependency. If your user base upgrades to the latest numpy release, and that latest release breaks your code, you will have unhappy users. -- Christopher Hanley Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Release of NumPy
Sebastian Haase wrote: How about releasing 1.0.5 without the new masked array, i.e. 1. put back the old masked array and release as 1.0.5 2. then release 1.1.0 with the new masked array 3. start working on 1.2 by unifying the arguments, np.resize, and other things alike. --Sebastian We at STScI have already begun modifying our code to use the new masked array. It is a very expensive proposition for us to attempt to support two different APIs for numpy for any length of time. It is likely that we would force our customer base to 1.1 to avoid the added support costs. I also hope that there aren't any additional API breaks in the works. A stable API keeps our customers happy. API changes tend to make them cranky. Just my two cents. Chris -- Christopher Hanley Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] numpy unittest failure on Mac PPC and Solaris 10
Hi,
We are seeing the following error on both Solaris and Mac PPC when
running the numpy unittests:
.F...
==
FAIL: test_record (numpy.lib.tests.test_io.Testloadtxt)
--
Traceback (most recent call last):
File /usr/stsci/pyssgdev/2.5.1/numpy/lib/tests/test_io.py, line 42,
in test_record
assert_array_equal(x, a)
File /usr/stsci/pyssgdev/2.5.1/numpy/testing/utils.py, line 225, in
assert_array_equal
verbose=verbose, header='Arrays are not equal')
File /usr/stsci/pyssgdev/2.5.1/numpy/testing/utils.py, line 217, in
assert_array_compare
assert cond, msg
AssertionError:
Arrays are not equal
(mismatch 100.0%)
x: array([(1, 2), (3, 4)],
dtype=[('x', 'i4'), ('y', 'i4')])
y: array([(1, 2), (3, 4)],
dtype=[('x', 'i4'), ('y', 'i4')])
--
Ran 837 tests in 4.281s
FAILED (failures=1)
Given the platforms this error occurs on I am guessing this is a big vs.
little-endian problem.
Chris
--
Christopher Hanley
Systems Software Engineer
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21218
(410) 338-4338
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] server down
Hi, I cannot access the numpy, scipy, or astropy repositories at scipy.org. The servers appear to be down. [redcedar:~/dev/scipy] chanley% svn update svn: PROPFIND request failed on '/svn/scipy/trunk' svn: PROPFIND of '/svn/scipy/trunk': could not connect to server (http://svn.scipy.org) Thanks, Chris -- Christopher Hanley Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] FORTRAN compiler detection
Greetings, I was wondering if within the last 8 - 10 weeks anyone has made changes to the way FORTRAN compilers are detected. In the past I was able to specify which compiler was used by the F77 system variable. However, I am now having a f90 compiler that exists on my Solaris system detected regardless of the F77 value. Even unsetting the F77 variable leads to the use of the f90 compiler. I was going to look though the distutil change logs but I was hoping that someone might remember changing something off the top of their heads. Thank you for your time and help, Chris -- Christopher Hanley Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] build issue on Solaris System
Good morning, I've just done a fresh checkout from SVN and attempted to build numpy on a Solaris 10 system. The build actually completes normally. However, when attempting to import numpy I get the following error: Python 2.5.1 (r251:54863, Jan 21 2008, 11:03:00) [C] on sunos5 Type help, copyright, credits or license for more information. import numpy Traceback (most recent call last): File stdin, line 1, in module File /data/basil5/site-packages/lib/python/numpy/__init__.py, line 51, in module import linalg File /data/basil5/site-packages/lib/python/numpy/linalg/__init__.py, line 4, in module from linalg import * File /data/basil5/site-packages/lib/python/numpy/linalg/linalg.py, line 28, in module from numpy.linalg import lapack_lite ImportError: ld.so.1: python: fatal: relocation error: file /data/basil5/site-packages/lib/python/numpy/linalg/lapack_lite.so: symbol s_cat: referenced symbol not found I haven't had these issues with lapack in the past. Has anyone made changes to linalg dependencies lately that I must have missed? Thank you for your time and help, Chris -- Christopher Hanley Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How do I change endianess?
[EMAIL PROTECTED] wrote: I would like to change the Endianess of a large of data written on PC so I can process it on a Solaris box. I see that the dtype.str attribute is read-only. TIA David Lees You can use the byteswap method to change the byte order of your array. obj = obj.byteswap() -- Christopher Hanley Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Bus Error with object arrays on big endian system
Hi,
The following will cause a bus error on a big endian machine (Solaris 10
Sun in this case):
Python 2.5.1 (r251:54863, Jun 29 2007, 15:29:55) [C] on sunos5
Type help, copyright, credits or license for more information.
import numpy
o = numpy.ndarray(shape=3,dtype=[('SEGMENT', '|S4'), ('SPEC_FOUND',
'|i1')])
o1 = o.getfield(numpy.dtype('|S4'),0)
print o1[0]
UXÐ
print o1[1]
4
print o1[2]
NT
print o1
Bus error (core dumped)
There are no issues on Linux or Mac OS X Intel based systems.
This example was done on the latest svn version of numpy (r1.0.5.dev47360).
Does anyone have an idea of what may have broken?
Thank you for your time and help,
Chris
--
Christopher Hanley
Systems Software Engineer
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21218
(410) 338-4338
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] howto convert float array to array of integers
I usually use the astype method.
import numpy as n
a = n.array([1.,0.,2.,-10.])
a.dtype
dtype('float64')
print a
[ 1. 0. 2. -10.]
b = a.astype(n.integer)
b.dtype
dtype('int32')
print b
[ 1 0 2 -10]
dmitrey wrote:
hi all,
I have an array like
array([ 1., 0., 2., -10.])
what is most efficient (i.e. fastest) way to convert the one to array of
integers?
array([ 1, 0, 2, -10])
Thx in advance, D.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
--
Christopher Hanley
Systems Software Engineer
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21218
(410) 338-4338
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] [Fwd: Re: numpy revision 2680 causes segfault on Solaris]
Hi Travis, The test failure was caused by a new test being added to the test suite to catch an existing problem. It was not a new code change that caused the problem. Chris -- Christopher Hanley Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 ---BeginMessage--- Hi Chris On Mon, Jun 26, 2006 at 08:53:59AM -0400, Christopher Hanley wrote: Numpy revision 2680 causes a segfault in the unit tests on the Solaris 8 OS. The unit tests fail with the at the following test: check_vecobject (numpy.core.tests.test_numeric.test_dot)Segmentation Fault (core dumped) The bug has been there for a while -- I just added the test to catch it. See http://projects.scipy.org/scipy/numpy/ticket/158 Cheers Stéfan ---End Message--- ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [Fwd: Re: numpy revision 2680 causes segfault on Solaris]
Cool! Thank you Stefan and mostly Eric. Cheers, Chris ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] latest svn version fails on Solaris
Hi, The latest version of numpy has a unit test failure on big endian machines. == FAIL: test_record_array (numpy.core.tests.test_multiarray.test_putmask) -- Traceback (most recent call last): File /data/basil5/site-packages/lib/python/numpy/core/tests/test_multiarray.py, line 450, in test_record_array assert_array_equal(rec['x'],[10,5]) File /data/basil5/site-packages/lib/python/numpy/testing/utils.py, line 223, in assert_array_equal verbose=verbose, header='Arrays are not equal') File /data/basil5/site-packages/lib/python/numpy/testing/utils.py, line 215, in assert_array_compare assert cond, msg AssertionError: Arrays are not equal (mismatch 50.0%) x: array([ 4.58492919e-320, 5.e+000]) y: array([10, 5]) -- Ran 670 tests in 47.182s Chris ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] how do I configure with gfortran
I have found that setting my F77 environment variable to gfortran is also sufficient. setenv F77 gfortran python setup.py install Chris ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Problem with numpy-1.0.3.tar.gz file
Hi, Could someone please re-create the numpy-1.0.3.tar.gz file that is currently being distributed from sourceforge? That tar file includes the following: /data/sparty1/dev/tmp/numpy-1.0.3 sparty ls -al total 44 drwxr-sr-x3 chanley science 4096 May 23 18:30 ./ drwxr-sr-x4 chanley science 4096 May 30 11:06 ../ -rw-r--r--1 chanley science 541 Feb 7 23:12 DEV_README.txt -rw-r--r--1 chanley science 1537 Jul 26 2006 LICENSE.txt -rw-r--r--1 chanley science 246 Jul 26 2006 MANIFEST.in drwxr-sr-x 14 chanley science 4096 May 23 18:30 numpy/ -rw-r--r--1 chanley science 1511 May 23 18:30 PKG-INFO -rw-r--r--1 chanley science 546 Apr 5 20:56 README.txt -rwxr-xr-x1 chanley science 3042 Jul 26 2006 setup.py* -rw-r--r--1 chanley science71 Aug 22 2006 site.cfg -rw-r--r--1 chanley science 2072 Mar 31 03:41 THANKS.txt However, if you look at the 1.0.3 tag in subversion the following files are included: /data/sparty1/dev/tmp/numpy_1.0.3_svn_tag sparty ll total 56 drwxr-sr-x3 chanley science 4096 May 30 11:07 benchmarks/ -rw-r--r--1 chanley science 1620 May 30 11:07 COMPATIBILITY -rw-r--r--1 chanley science 541 May 30 11:07 DEV_README.txt -rw-r--r--1 chanley science 1537 May 30 10:59 LICENSE.txt -rw-r--r--1 chanley science 246 May 30 11:07 MANIFEST.in drwxr-sr-x 15 chanley science 4096 May 30 11:07 numpy/ -rw-r--r--1 chanley science 546 May 30 11:07 README.txt -rw-r--r--1 chanley science 123 May 30 10:59 scipy_compatibility -rwxr-xr-x1 chanley science 149 May 30 11:07 setupegg.py* -rwxr-xr-x1 chanley science 3042 May 30 10:59 setup.py* -rw-r--r--1 chanley science 4613 May 30 11:07 site.cfg.example -rw-r--r--1 chanley science 185 May 30 10:59 TEST_COMMIT -rw-r--r--1 chanley science 2072 May 30 10:59 THANKS.txt We are have a problem with the inclusion of the site.cfg file in the current tar file. It's inclusion causes our installations to fail. However, if the site.cfg file is left as the site.cfg.example the default installation works perfectly. This was also the case with previous versions. Would it be possible to have this change made? Thank you for your time and help, Chris ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Do we still need support for Python 2.3?
I would have to say that I agree with Robert. We (STScI) are about to force all of our users to install numpy. For some of them that can be a lot to ask. I don't also want to add the extra complication of upgrading their Python version as well. My feeling is that not everyone has made the jump to numpy yet. I think we should keep it as painless a process as possible. Just my two cents. Chris Robert Kern wrote: Nadav Horesh wrote: The question should be: Are there members who rely on python 2.3 Numeric and numpy's user base has always been much more extensive than the list membership. I don't think that the question can be reformulated that way. I think we still do need to support Python 2.3. Being able to use the builtin set() rather than set.Set() is not a compelling use case. Libraries that are as fundamental as numpy is trying to be should try to maintain compatibility with the oldest versions of Python that are feasible. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] interrupted svn updates
I had that problem this morning as well. It appears to be a problem on the server side. Chris George Nurser wrote: I'm trying to update numpy from svn. My first try was very slow, but eventially produced 72 updated files; gave message at end: svn: REPORT request failed on '/svn/numpy/!svn/vcc/default' svn: REPORT of '/svn/numpy/!svn/vcc/default': Could not read response body: connection was closed by server. (http://svn.scipy.org) 2nd try produced 4 more then died with above error 3rd 4th just dies with above error. Any ideas -- is thw problem here or there? Many thanks, George Nurser. ___ 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] test_multiarray.test_clip fails on Solaris 8 system
Sun hardware is big endian. To be specific, this test was done on a Sun Ultra 10. I don't have access to a PPC right now. I can check tomorrow once I am in the office. Chris Hmm, Sun hardware is big endian, no? I wonder what happens on PPC? I don't see any problems here on Athlon64. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] test_multiarray.test_clip fails on Solaris 8 system
Hi Stefan,
This is what I get:
import sys
print sys.byteorder
big
import numpy as N
print
N.array([1,2,3],N.dtype(N.int16).newbyteorder('')).dtype.byteorder
print
N.array([1,2,3],N.dtype(N.int16).newbyteorder('')).dtype.byteorder
print
N.array([1,2,3],N.dtype(N.int16).newbyteorder('=')).dtype.byteorder
=
Stefan van der Walt wrote:
Hi Chris
Would you please run the following commands and show their output?
import sys
print sys.byteorder
import numpy as N
print N.array([1,2,3],N.dtype(N.int16).newbyteorder('')).dtype.byteorder
print N.array([1,2,3],N.dtype(N.int16).newbyteorder('')).dtype.byteorder
print N.array([1,2,3],N.dtype(N.int16).newbyteorder('=')).dtype.byteorder
Output on my little-endian system is
little
=
and I'd be curious to see if the output on a big-endian system follows
the same pattern.
I'd expect
big
=
Cheers
Stéfan
___
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] test_multiarray.test_clip fails on Solaris 8 system
The following test fails on a Solaris 8 system:
==
FAIL: check_basic (numpy.core.tests.test_multiarray.test_clip)
--
Traceback (most recent call last):
File
/data/basil5/site-packages/lib/python/numpy/core/tests/test_multiarray.py,
line 388, in check_basic
self._clip_type('float',1024,-12.8,100.2, inplace=inplace)
File
/data/basil5/site-packages/lib/python/numpy/core/tests/test_multiarray.py,
line 382, in _clip_type
assert_equal(byteorder,x.dtype.byteorder)
File /data/basil5/site-packages/lib/python/numpy/testing/utils.py, line
143, in assert_equal
assert desired == actual, msg
AssertionError:
Items are not equal:
ACTUAL: ''
DESIRED: '='
--
Ran 562 tests in 19.376s
FAILED (failures=1)
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Should 0-d arrays with fields defined return a 0-d array or a scalar
Hi Travis, We will need a little time to inspect our code to see if this is going to be a problem for us. We can't think of any major problems with this change off the top of our heads. Chris Travis Oliphant wrote: Hi all, Ticket #474 discusses the problem that getting a field from a 0-d array automatically produces a scalar (which then cannot be set). This produces the problem that recarrays code must often special-case the 0-d possibility. Thus, rarr.x[...] = blah doesn't work for 0-d arrays because rarr.x is a scalar. It makes some sense to make field selection for 0-d arrays return 0-d arrays as consistent with the changes that were made prior to the 1.0 release to allow persistence of 0-d arrays. However, changing field selection to return 0-d arrays does change behavior. A 0-d array is not a scalar (the 0-d array is not hashable for example, and the 0-d string array does not inherit from the Python string). Thus, just making the change, may not be advised. It is easy to account for and fix any errors that might arise. But, we are in a major release, I need some advice as to whether or not this is a bug-fix or a feature enhancement that must wait for 1.1? Any stake holders in the current behavior of arrays with records? -Travis ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion -- Christopher Hanley Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] subversion site down
Hi, It appears that the subversion server is down for numpy. Chris ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Scalar coercion
Hello Everyone, Another behavior we might consider changing for 1.0.2 that I believe is somewhat related in theme is the default type used in computations like the mean() method. This is best illustrated with the following example: sparty python Python 2.5 (r25:51908, Sep 21 2006, 13:33:15) [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-56)] on linux2 Type help, copyright, credits or license for more information. import numpy as n n.__version__ '1.0.2.dev3568' a = n.ones((1000,1000),dtype=n.float32)*132.5 print a [[ 132.4578 132.4578 132.4578 ..., 132.4578 132.4578 132.4578] [ 132.4578 132.4578 132.4578 ..., 132.4578 132.4578 132.4578] [ 132.4578 132.4578 132.4578 ..., 132.4578 132.4578 132.4578] ..., [ 132.4578 132.4578 132.4578 ..., 132.4578 132.4578 132.4578] [ 132.4578 132.4578 132.4578 ..., 132.4578 132.4578 132.4578] [ 132.4578 132.4578 132.4578 ..., 132.4578 132.4578 132.4578]] a.min() 132.45776 a.max() 132.45776 a.mean() 133.966399 Having the mean be greater than the max is a tad odd. The calculation of the mean is occurring with a single precision accumulator. I do understand that I can force a double precision calculation with the following command: a.mean(dtype=n.float64) 132.4577636719 I realize that one reason for not doing all calculations as double precision is performance. However, my users would rather have the correct answer by default than quickly arriving at the wrong one. In my opinion we should swap the default behavior. All calculations should be done in double precision. If you need the performance you can then go back and start setting data types. Not having to worry about overflow would also be consistent with numarray's behavior. Thank you for considering my opinion, Chris ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] average() or mean() errors
I filed a similar bug report the other day. I believe that it has to do with the default size of the accumulator variable in the algorithms being used. Please see the following example, Python 2.4.3 (#2, Dec 7 2006, 11:01:45) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type help, copyright, credits or license for more information. import numpy as n a = n.array([132.4,132.6,132.5],dtype=n.float32) a.mean() 132.6103515625 a = n.array([132.4,132.6,132.5],dtype=n.float64) a.mean() 132.49 In the first case, the calculation is done in single precision since that is the type of the input arrays. The second case the calculation is double precision. I think this is the effect that is being seen. The workaround would be to say numpy.average(obj,dtype=numpy.float64). Chris Stefan van der Walt wrote: On Tue, Jan 23, 2007 at 08:29:47PM -0500, Daniel Smith wrote: When calling the average() or mean() functions on a small array (3 numbers), I am seeing significant numerical errors (on the order of 1% with data to 8 significant digits). The code I am using is essentially: A = zeros(3) A[i] = X B = average(A) I'm not sure I understand: In [7]: A = N.zeros(3) In [8]: A[1] = 3. In [9]: N.average(A) Out[9]: 1.0 In [11]: A[0] = 2. In [12]: N.average(A) Out[12]: 1.667 In [13]: (2+3+0)/3. Out[13]: 1.6667 In [14]: for i in range(1000): : A = N.random.rand(3) : assert N.average(A) == N.sum(A)/3. Maybe you can give a specific code snippet? Cheers Stéfan ___ 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
