From rmslobato at gmail.com Wed Jun 7 12:40:21 2017 From: rmslobato at gmail.com (Rafael Silva) Date: Wed, 7 Jun 2017 13:40:21 -0300 Subject: [SciPy-User] results of scipy.spatial.ConvexHull Message-ID: Hi! Using the code > import scipy.spatial.qhull as qhull > import scipy.spatial.qhull as qhull verts = [ > [-0.5, -0.5, -0.5], > [-0.5, -0.5, 0.5], > [-0.5, 0.5, -0.5], > [-0.5, 0.5, 0.5], > [0.5, -0.5, -0.5], > [0.5, -0.5, 0.5], > [0.5, 0.5, -0.5], > [0.5, 0.5, 0.5], > ] > qh = qhull.ConvexHull(verts) > print(qh.simplices) I obtained the results: > [[6 2 0] > [6 4 0] > [5 4 0] > [5 1 0] > [5 6 4] > [5 6 7] > [3 2 0] > [3 1 0] > [3 6 2] > [3 6 7] > [3 5 1] > [3 5 7]] I tried some options using the keyword "qull_options", but I could only get results consisting of 12 simplices. Instead, using Qhull library directly rbox c D3 | qconvex p i I got the result I wanted with just 6 simplices: 4 6 2 0 > 1 5 4 0 > 5 7 6 4 > 3 1 0 2 > 7 3 2 6 > 3 7 5 1 And using the option "Qt" I got the same result from scipy: 6 2 0 > 4 6 0 > 5 4 0 > 1 5 0 > 5 6 4 > 6 5 7 > 2 3 0 > 3 1 0 > 6 3 2 > 3 6 7 > 3 5 1 > 5 3 7 My question is: I want to get the "merged" version of the convex hull results for 3-D points. In the example, I want the 6 simplices case instead of the 12 (N x 3) format. How could I get that from scipy? Is it possible? Thank you for help! Regards, Rafael. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eulergaussriemann at gmail.com Wed Jun 7 13:24:43 2017 From: eulergaussriemann at gmail.com (David Goldsmith) Date: Wed, 07 Jun 2017 17:24:43 +0000 Subject: [SciPy-User] OT (C++): Opinions re: C++ FEM packages In-Reply-To: References: Message-ID: Sorry for the OT post, but this is where i trust the recommendations i'd get: any opinions/recommendations on what's available in C++ nowadays for Finite Element work? Thanks! DLG -------------- next part -------------- An HTML attachment was scrubbed... URL: From yw5aj at virginia.edu Wed Jun 7 14:28:14 2017 From: yw5aj at virginia.edu (Yuxiang Wang) Date: Wed, 7 Jun 2017 11:28:14 -0700 Subject: [SciPy-User] OT (C++): Opinions re: C++ FEM packages In-Reply-To: References: Message-ID: Hi David! I assume you are asking about open source options (instead of commercial software), right? I personally find the code_aster (http://www.code-aster.org/) the most powerful. I know that dealii (http://www.dealii.org/) is pretty good and active too! Shawn On Wed, Jun 7, 2017 at 10:24 AM, David Goldsmith wrote: > Sorry for the OT post, but this is where i trust the recommendations i'd > get: any opinions/recommendations on what's available in C++ nowadays for > Finite Element work? > > Thanks! > > DLG > > _______________________________________________ > SciPy-User mailing list > SciPy-User at python.org > https://mail.python.org/mailman/listinfo/scipy-user > -- Yuxiang "Shawn" Wang, PhD yw5aj at virginia.edu +1 (434) 284-0836 From eulergaussriemann at gmail.com Wed Jun 7 14:32:50 2017 From: eulergaussriemann at gmail.com (David Goldsmith) Date: Wed, 07 Jun 2017 18:32:50 +0000 Subject: [SciPy-User] OT (C++): Opinions re: C++ FEM packages In-Reply-To: References: Message-ID: Yes, open source preferred; thanks for the recs! DLG On Wed, Jun 7, 2017 at 11:29 AM Yuxiang Wang wrote: > Hi David! > > I assume you are asking about open source options (instead of > commercial software), right? > > I personally find the code_aster (http://www.code-aster.org/) the most > powerful. > > I know that dealii (http://www.dealii.org/) is pretty good and active too! > > Shawn > > On Wed, Jun 7, 2017 at 10:24 AM, David Goldsmith > wrote: > > Sorry for the OT post, but this is where i trust the recommendations i'd > > get: any opinions/recommendations on what's available in C++ nowadays for > > Finite Element work? > > > > Thanks! > > > > DLG > > > > _______________________________________________ > > SciPy-User mailing list > > SciPy-User at python.org > > https://mail.python.org/mailman/listinfo/scipy-user > > > > > > -- > Yuxiang "Shawn" Wang, PhD > yw5aj at virginia.edu > +1 (434) 284-0836 > _______________________________________________ > SciPy-User mailing list > SciPy-User at python.org > https://mail.python.org/mailman/listinfo/scipy-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Wed Jun 7 15:25:59 2017 From: charlesr.harris at gmail.com (Charles R Harris) Date: Wed, 7 Jun 2017 13:25:59 -0600 Subject: [SciPy-User] NumPy 1.13.0 release Message-ID: Hi All, On behalf of the NumPy team, I amn pleased to announce the NumPy 1.13.0 release. This release supports Python 2.7 and 3.4-3.6 and contains many new features. It is one of the most ambitious releases in the last several years. Some of the highlights and new functions are *Highlights* - Operations like ``a + b + c`` will reuse temporaries on some platforms, resulting in less memory use and faster execution. - Inplace operations check if inputs overlap outputs and create temporaries to avoid problems. - New __array_ufunc__ attribute provides improved ability for classes to override default ufunc behavior. - New np.block function for creating blocked arrays. *New functions* - New ``np.positive`` ufunc. - New ``np.divmod`` ufunc provides more efficient divmod. - New ``np.isnat`` ufunc tests for NaT special values. - New ``np.heaviside`` ufunc computes the Heaviside function. - New ``np.isin`` function, improves on ``in1d``. - New ``np.block`` function for creating blocked arrays. - New ``PyArray_MapIterArrayCopyIfOverlap`` added to NumPy C-API. Wheels for the pre-release are available on PyPI. Source tarballs, zipfiles, release notes, and the changelog are available on github . A total of 102 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - A. Jesse Jiryu Davis + - Alessandro Pietro Bardelli + - Alex Rothberg + - Alexander Shadchin - Allan Haldane - Andres Guzman-Ballen + - Antoine Pitrou - Antony Lee - B R S Recht + - Baurzhan Muftakhidinov + - Ben Rowland - Benda Xu + - Blake Griffith - Bradley Wogsland + - Brandon Carter + - CJ Carey - Charles Harris - Christoph Gohlke - Danny Hermes + - David Hagen + - David Nicholson + - Duke Vijitbenjaronk + - Egor Klenin + - Elliott Forney + - Elliott M Forney + - Endolith - Eric Wieser - Erik M. Bray - Eugene + - Evan Limanto + - Felix Berkenkamp + - Fran?ois Bissey + - Frederic Bastien - Greg Young - Gregory R. Lee - Importance of Being Ernest + - Jaime Fernandez - Jakub Wilk + - James Cowgill + - James Sanders - Jean Utke + - Jesse Thoren + - Jim Crist + - Joerg Behrmann + - John Kirkham - Jonathan Helmus - Jonathan L Long - Jonathan Tammo Siebert + - Joseph Fox-Rabinovitz - Joshua Loyal + - Juan Nunez-Iglesias + - Julian Taylor - Kirill Balunov + - Likhith Chitneni + - Lo?c Est?ve - Mads Ohm Larsen - Marein K?nings + - Marten van Kerkwijk - Martin Thoma - Martino Sorbaro + - Marvin Schmidt + - Matthew Brett - Matthias Bussonnier + - Matthias C. M. Troffaes + - Matti Picus - Michael Seifert - Mikhail Pak + - Mortada Mehyar - Nathaniel J. Smith - Nick Papior - Oscar Villellas + - Pauli Virtanen - Pavel Potocek - Pete Peeradej Tanruangporn + - Philipp A + - Ralf Gommers - Robert Kern - Roland Kaufmann + - Ronan Lamy - Sami Salonen + - Sanchez Gonzalez Alvaro - Sebastian Berg - Shota Kawabuchi - Simon Gibbons - Stefan Otte - Stefan Peterson + - Stephan Hoyer - S?ren Fuglede J?rgensen + - Takuya Akiba - Tom Boyd + - Ville Skytt? + - Warren Weckesser - Wendell Smith - Yu Feng - Zixu Zhao + - Z? Vin?cius + - aha66 + - drabach + - drlvk + - jsh9 + - solarjoe + - zengi + Cheers, Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.terrel at gmail.com Wed Jun 7 20:08:51 2017 From: andy.terrel at gmail.com (Andy Ray Terrel) Date: Wed, 7 Jun 2017 17:08:51 -0700 Subject: [SciPy-User] OT (C++): Opinions re: C++ FEM packages In-Reply-To: References: Message-ID: In addition to other recs you might checkout : - FEniCS (https://bitbucket.org/fenics-project/dolfin) - DUNE - FreeFEM++ - libmesh https://en.wikipedia.org/wiki/List_of_finite_element_software_packages On Wed, Jun 7, 2017 at 11:32 AM, David Goldsmith < eulergaussriemann at gmail.com> wrote: > Yes, open source preferred; thanks for the recs! > > DLG > > On Wed, Jun 7, 2017 at 11:29 AM Yuxiang Wang wrote: > >> Hi David! >> >> I assume you are asking about open source options (instead of >> commercial software), right? >> >> I personally find the code_aster (http://www.code-aster.org/) the most >> powerful. >> >> I know that dealii (http://www.dealii.org/) is pretty good and active >> too! >> >> Shawn >> >> On Wed, Jun 7, 2017 at 10:24 AM, David Goldsmith >> wrote: >> > Sorry for the OT post, but this is where i trust the recommendations i'd >> > get: any opinions/recommendations on what's available in C++ nowadays >> for >> > Finite Element work? >> > >> > Thanks! >> > >> > DLG >> > >> > _______________________________________________ >> > SciPy-User mailing list >> > SciPy-User at python.org >> > https://mail.python.org/mailman/listinfo/scipy-user >> > >> >> >> >> -- >> Yuxiang "Shawn" Wang, PhD >> yw5aj at virginia.edu >> +1 (434) 284-0836 <(434)%20284-0836> >> _______________________________________________ >> SciPy-User mailing list >> SciPy-User at python.org >> https://mail.python.org/mailman/listinfo/scipy-user >> > > _______________________________________________ > SciPy-User mailing list > SciPy-User at python.org > https://mail.python.org/mailman/listinfo/scipy-user > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierre.debuyl at kuleuven.be Mon Jun 12 15:30:43 2017 From: pierre.debuyl at kuleuven.be (Pierre de Buyl) Date: Mon, 12 Jun 2017 21:30:43 +0200 Subject: [SciPy-User] EuroSciPy 2017 call for contributions Message-ID: <20170612193043.GT1316@pi-x230> (Apologies if you receive multiple copies of this message) 10th European Conference on Python in Science August 28 - September 1, 2017 in Erlangen, Germany Description: The EuroSciPy meeting is a cross-disciplinary gathering focused on the use and development of the Python language in scientific research. This event strives to bring together both users and developers of scientific tools, as well as academic research and state of the art industry. Erlangen is one of Germany's major science hubs and located north of Munich (90 minutes by train). Topics of Interest Presentations of scientific tools and libraries using the Python language, including but not limited to: - Vector and array manipulation - Parallel computing - Scientific visualization - Scientific data flow and persistence - Algorithms implemented or exposed in Python - Web applications and portals for science and engineering- - Reports on the use of Python in scientific achievements or ongoing projects. - General-purpose Python tools that can be of special interest to the scientific community. Submission Details: You can send your proposal by submitting your application here: https://www.papercall.io/euroscipy-2017 The Call for Papers closes on June 25, 2017 00:00 CEST Regards, The EuroSciPy team https://www.euroscipy.org/2017/ From michelemartone at users.sourceforge.net Wed Jun 21 05:51:55 2017 From: michelemartone at users.sourceforge.net (Michele Martone) Date: Wed, 21 Jun 2017 11:51:55 +0200 Subject: [SciPy-User] PyRSB: Python interface to librsb sparse matrices library Message-ID: <20170621095155.GE19876@localhost> Hi. I'm the author of the high performance multithreaded sparse matrix library `librsb' (mostly C, LGPLv3): http://librsb.sourceforge.net/ I'm *not* a user of SciPy/NumPy/Python, but using Cython I have written a proof-of-concept interface to librsb, named `PyRSB': https://github.com/michelemartone/pyrsb PyRSB is in a prototypal state; e.g. still lacks good error handling. Its interface is trivial, as it mimicks that of SciPy's 'csr_matrix'. Advantages over csr_matrix are in fast multithreaded multiplication of huge sparse matrices. Intended application area is iterative solution of linear systems; particularly fast if with symmetric matrices and many rhs. With this email I am looking for prospective: - users/testers - developers (any interest to collaborate/adopt/include the project?) Looking forward for your feedback, Michele -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From npropadovic at gmail.com Wed Jun 21 09:41:26 2017 From: npropadovic at gmail.com (Propadovic Nenad) Date: Wed, 21 Jun 2017 15:41:26 +0200 Subject: [SciPy-User] Strange behaviour of scipy.interpolate.interp1d in with kind="zero" Message-ID: Hello everybody, please consider the following code: --- import numpy from scipy.interpolate import interp1d t = numpy.array([0.000, 0.004, 0.008, 0.012, 0.016, 0.02]) sig = numpy.array([0, 1, 2, 3, 4, 5]) t_new = numpy.array([0.0, 0.001, 0.003, 0.004, 0.008, 0.012, 0.016, 0.0196, 0.02]) f = interp1d(t, sig, kind='zero') s_resampled = f(t_new) print s_resampled --- The result I get on my machine is: >C:\Anaconda2\pythonw -u "test_zero_order_hold.py" [ 0. 0. 0. 1. 2. 3. 4. 4. 4.] >Exit code: 0 Now why is the last value 4, and not 5? I'd expect it to be 5, as the last timestamps in t and t_new are identical. Is this a bug in interp1d or am I missing something important - if so, what? Thanks a lot, in advance, Nenad -------------- next part -------------- An HTML attachment was scrubbed... URL: From guziy.sasha at gmail.com Wed Jun 21 10:19:29 2017 From: guziy.sasha at gmail.com (Oleksandr Huziy) Date: Wed, 21 Jun 2017 10:19:29 -0400 Subject: [SciPy-User] Strange behaviour of scipy.interpolate.interp1d in with kind="zero" In-Reply-To: References: Message-ID: Hi Nenad: This probably how the kind="zero" is implemented (uses a constant value from the left side of the interval) and since in your case you do not have any data to the right of the point, it is never used. Maybe it could be called bug.... (You could try to submit an issue on github) Apparently, now for it to work as you want, you would need to extend your sig a bit: import numpy from scipy.interpolate import interp1d t = numpy.array([0.000, 0.004, 0.008, 0.012, 0.016, 0.02, 0.03]) sig = numpy.array([0, 1, 2, 3, 4, 5, 6]) t_new = numpy.array([0.0, 0.001, 0.003, 0.004, 0.008, 0.012, 0.016, 0.0196, 0.02]) f = interp1d(t, sig, kind='zero') s_resampled = f(t_new) print(s_resampled) [ 0. 0. 0. 1. 2. 3. 4. 4. 5.] Cheers 2017-06-21 9:41 GMT-04:00 Propadovic Nenad : > Hello everybody, > > please consider the following code: > > --- > import numpy > from scipy.interpolate import interp1d > > t = numpy.array([0.000, 0.004, 0.008, 0.012, 0.016, 0.02]) > sig = numpy.array([0, 1, 2, 3, 4, 5]) > t_new = numpy.array([0.0, 0.001, 0.003, 0.004, 0.008, 0.012, 0.016, > 0.0196, 0.02]) > > f = interp1d(t, sig, kind='zero') > s_resampled = f(t_new) > print s_resampled > --- > > The result I get on my machine is: > >C:\Anaconda2\pythonw -u "test_zero_order_hold.py" > [ 0. 0. 0. 1. 2. 3. 4. 4. 4.] > >Exit code: 0 > > Now why is the last value 4, and not 5? I'd expect it to be 5, as the last > timestamps in t and t_new are identical. Is this a bug in interp1d or am I > missing something important - if so, what? > > Thanks a lot, in advance, > > Nenad > > _______________________________________________ > SciPy-User mailing list > SciPy-User at python.org > https://mail.python.org/mailman/listinfo/scipy-user > > -- Sasha -------------- next part -------------- An HTML attachment was scrubbed... URL: From evgeny.burovskiy at gmail.com Wed Jun 21 15:10:46 2017 From: evgeny.burovskiy at gmail.com (Evgeni Burovski) Date: Wed, 21 Jun 2017 22:10:46 +0300 Subject: [SciPy-User] Strange behaviour of scipy.interpolate.interp1d in with kind="zero" In-Reply-To: References: Message-ID: On Wed, Jun 21, 2017 at 5:19 PM, Oleksandr Huziy wrote: > Hi Nenad: > > This probably how the kind="zero" is implemented (uses a constant value from > the left side of the interval) and since in your case you do not have any > data to the right of the point, it is never used. > > Maybe it could be called bug.... (You could try to submit an issue on > github) > > Apparently, now for it to work as you want, you would need to extend your > sig a bit: > > import numpy > from scipy.interpolate import interp1d > t = numpy.array([0.000, 0.004, 0.008, 0.012, 0.016, 0.02, 0.03]) > sig = numpy.array([0, 1, 2, 3, 4, 5, 6]) > t_new = numpy.array([0.0, 0.001, 0.003, 0.004, 0.008, 0.012, 0.016, 0.0196, > 0.02]) > f = interp1d(t, sig, kind='zero') > s_resampled = f(t_new) > print(s_resampled) > [ 0. 0. 0. 1. 2. 3. 4. 4. 5.] > > > Cheers > > > > > > > 2017-06-21 9:41 GMT-04:00 Propadovic Nenad : >> >> Hello everybody, >> >> please consider the following code: >> >> --- >> import numpy >> from scipy.interpolate import interp1d >> >> t = numpy.array([0.000, 0.004, 0.008, 0.012, 0.016, 0.02]) >> sig = numpy.array([0, 1, 2, 3, 4, 5]) >> t_new = numpy.array([0.0, 0.001, 0.003, 0.004, 0.008, 0.012, 0.016, >> 0.0196, 0.02]) >> >> f = interp1d(t, sig, kind='zero') >> s_resampled = f(t_new) >> print s_resampled >> --- >> >> The result I get on my machine is: >> >C:\Anaconda2\pythonw -u "test_zero_order_hold.py" >> [ 0. 0. 0. 1. 2. 3. 4. 4. 4.] >> >Exit code: 0 >> >> Now why is the last value 4, and not 5? I'd expect it to be 5, as the last >> timestamps in t and t_new are identical. Is this a bug in interp1d or am I >> missing something important - if so, what? >> >> Thanks a lot, in advance, >> >> Nenad >> >> _______________________________________________ >> SciPy-User mailing list >> SciPy-User at python.org >> https://mail.python.org/mailman/listinfo/scipy-user >> > > > > -- > Sasha > > _______________________________________________ > SciPy-User mailing list > SciPy-User at python.org > https://mail.python.org/mailman/listinfo/scipy-user > Cannot repro -- what numpy/scipy versions, OS? In [2]: %paste import numpy from scipy.interpolate import interp1d t = numpy.array([0.000, 0.004, 0.008, 0.012, 0.016, 0.02]) sig = numpy.array([0, 1, 2, 3, 4, 5]) t_new = numpy.array([0.0, 0.001, 0.003, 0.004, 0.008, 0.012, 0.016, 0.0196, 0.02]) f = interp1d(t, sig, kind='zero') s_resampled = f(t_new) print s_resampled ## -- End pasted text -- [ 0. 0. 0. 1. 2. 3. 4. 4. 5.] In [3]: f(t) == sig Out[3]: array([ True, True, True, True, True, True], dtype=bool) In [4]: numpy.__version__ Out[4]: '1.10.4' In [5]: import scipy In [6]: scipy.__version__ Out[6]: '1.0.0.dev0+f3e4e17' Also note that exact equality in floating point is brittle anyway: In [9]: f(t_new.astype(numpy.float32)) Out[9]: array([ 0., 0., 0., 1., 2., 3., 4., 4., 4.]) In [10]: f(t_new) Out[10]: array([ 0., 0., 0., 1., 2., 3., 4., 4., 5.]) Evgeni From npropadovic at gmail.com Thu Jun 22 03:12:44 2017 From: npropadovic at gmail.com (Propadovic Nenad) Date: Thu, 22 Jun 2017 09:12:44 +0200 Subject: [SciPy-User] Strange behaviour of scipy.interpolate.interp1d in with kind="zero" Message-ID: Hello Oleksandr, thank you for the swift answer. I think we can settle for an untreated edge case and/or an inconsistency. The values at times 0.004, 0.008, 0.012, 0.016 are exactly what I expect, after all: the exact values that the original signal at the exact points in time. I will file a bug, as you proposed. Regards, Nenad > Hi Nenad: > > This probably how the kind="zero" is implemented (uses a constant value > from the left side of the interval) and since in your case you do not have > any data to the right of the point, it is never used. > > Maybe it could be called bug.... (You could try to submit an issue on > github) > > Apparently, now for it to work as you want, you would need to extend your > sig a bit: > > import numpy > from scipy.interpolate import interp1d > t = numpy.array([0.000, 0.004, 0.008, 0.012, 0.016, 0.02, 0.03]) > sig = numpy.array([0, 1, 2, 3, 4, 5, 6]) > t_new = numpy.array([0.0, 0.001, 0.003, 0.004, 0.008, 0.012, 0.016, 0.0196, > 0.02]) > f = interp1d(t, sig, kind='zero') > s_resampled = f(t_new) > print(s_resampled) > [ 0. 0. 0. 1. 2. 3. 4. 4. 5.] > > > Cheers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From npropadovic at gmail.com Thu Jun 22 04:45:54 2017 From: npropadovic at gmail.com (Propadovic Nenad) Date: Thu, 22 Jun 2017 10:45:54 +0200 Subject: [SciPy-User] Strange behaviour of scipy.interpolate.interp1d in with kind="zero" In-Reply-To: References: Message-ID: Hello Evgeni, sorry, somehow initially I had not seen your post. My OS is Windows 7 Professional N 64 bit. Python 2.7.13 |Anaconda 4.3.0 (64-bit) (yes I know Python 3.x is preferred, but that's the company choice that I can't influence... ) numpy.__version__ Out[2]: '1.11.3' scipy.__version__ Out[4]: '0.18.1' Yeah, maybe I can update Anaconda before calling out a bug. But the scipy-version is not soooo old. And, yes, I'm aware of the brittle nature of exact equality of floats... I often use code like following in my unit-tests: assert (numpy.all(abs(x-x_maybe_equal ) < 1e-12)) Cheers, Nenad > Cannot repro -- what numpy/scipy versions, OS? > > > > In [2]: %paste > import numpy > from scipy.interpolate import interp1d > > t = numpy.array([0.000, 0.004, 0.008, 0.012, 0.016, 0.02]) > sig = numpy.array([0, 1, 2, 3, 4, 5]) > t_new = numpy.array([0.0, 0.001, 0.003, 0.004, 0.008, 0.012, 0.016, > 0.0196, 0.02]) > > f = interp1d(t, sig, kind='zero') > s_resampled = f(t_new) > print s_resampled > ## -- End pasted text -- > [ 0. 0. 0. 1. 2. 3. 4. 4. 5.] > > In [3]: f(t) == sig > Out[3]: array([ True, True, True, True, True, True], dtype=bool) > > In [4]: numpy.__version__ > Out[4]: '1.10.4' > > In [5]: import scipy > > In [6]: scipy.__version__ > Out[6]: '1.0.0.dev0+f3e4e17' > > > Also note that exact equality in floating point is brittle anyway: > > In [9]: f(t_new.astype(numpy.float32)) > Out[9]: array([ 0., 0., 0., 1., 2., 3., 4., 4., 4.]) > > In [10]: f(t_new) > Out[10]: array([ 0., 0., 0., 1., 2., 3., 4., 4., 5.]) > > > Evgeni > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From npropadovic at gmail.com Thu Jun 22 05:23:30 2017 From: npropadovic at gmail.com (Propadovic Nenad) Date: Thu, 22 Jun 2017 11:23:30 +0200 Subject: [SciPy-User] Strange behaviour of scipy.interpolate.interp1d in with kind="zero" In-Reply-To: References: Message-ID: Hello again, OK, the problem went away when I upgraded scipy from 0.18.1 to 0.19.0 (Anaconda didn't offer 1.0). So I guess I have to apologize for bothering. Regards, Nenad 2017-06-22 10:45 GMT+02:00 Propadovic Nenad : > Hello Evgeni, > sorry, somehow initially I had not seen your post. > My OS is Windows 7 Professional N 64 bit. > > Python 2.7.13 |Anaconda 4.3.0 (64-bit) > (yes I know Python 3.x is preferred, but that's the company choice that I > can't influence... ) > > numpy.__version__ > Out[2]: '1.11.3' > > scipy.__version__ > Out[4]: '0.18.1' > > Yeah, maybe I can update Anaconda before calling out a bug. But the > scipy-version is not soooo old. > > And, yes, I'm aware of the brittle nature of exact equality of floats... I > often use code like following in my unit-tests: > assert (numpy.all(abs(x-x_maybe_equal ) < 1e-12)) > > Cheers, > > Nenad > >> Cannot repro -- what numpy/scipy versions, OS? >> >> >> >> In [2]: %paste >> import numpy >> from scipy.interpolate import interp1d >> >> t = numpy.array([0.000, 0.004, 0.008, 0.012, 0.016, 0.02]) >> sig = numpy.array([0, 1, 2, 3, 4, 5]) >> t_new = numpy.array([0.0, 0.001, 0.003, 0.004, 0.008, 0.012, 0.016, >> 0.0196, 0.02]) >> >> f = interp1d(t, sig, kind='zero') >> s_resampled = f(t_new) >> print s_resampled >> ## -- End pasted text -- >> [ 0. 0. 0. 1. 2. 3. 4. 4. 5.] >> >> In [3]: f(t) == sig >> Out[3]: array([ True, True, True, True, True, True], dtype=bool) >> >> In [4]: numpy.__version__ >> Out[4]: '1.10.4' >> >> In [5]: import scipy >> >> In [6]: scipy.__version__ >> Out[6]: '1.0.0.dev0+f3e4e17' >> >> >> Also note that exact equality in floating point is brittle anyway: >> >> In [9]: f(t_new.astype(numpy.float32)) >> Out[9]: array([ 0., 0., 0., 1., 2., 3., 4., 4., 4.]) >> >> In [10]: f(t_new) >> Out[10]: array([ 0., 0., 0., 1., 2., 3., 4., 4., 5.]) >> >> >> Evgeni >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michelemartone at users.sourceforge.net Wed Jun 21 05:51:55 2017 From: michelemartone at users.sourceforge.net (Michele Martone) Date: Wed, 21 Jun 2017 11:51:55 +0200 Subject: [SciPy-User] [SciPy-Dev] PyRSB: Python interface to librsb sparse matrices library Message-ID: Hi. I'm the author of the high performance multithreaded sparse matrix library `librsb' (mostly C, LGPLv3): http://librsb.sourceforge.net/ I'm *not* a user of SciPy/NumPy/Python, but using Cython I have written a proof-of-concept interface to librsb, named `PyRSB': https://github.com/michelemartone/pyrsb PyRSB is in a prototypal state; e.g. still lacks good error handling. Its interface is trivial, as it mimicks that of SciPy's 'csr_matrix'. Advantages over csr_matrix are in fast multithreaded multiplication of huge sparse matrices. Intended application area is iterative solution of linear systems; particularly fast if with symmetric matrices and many rhs. With this email I am looking for prospective: - users/testers - developers (any interest to collaborate/adopt/include the project?) Looking forward for your feedback, Michele -------------- next part -------------- A non-text attachment was scrubbed... Name: Unsupported File Types Alert.txt Type: application/octet-stream Size: 253 bytes Desc: Unsupported File Types Alert.txt URL: From guziy.sasha at gmail.com Thu Jun 22 13:23:50 2017 From: guziy.sasha at gmail.com (Oleksandr Huziy) Date: Thu, 22 Jun 2017 13:23:50 -0400 Subject: [SciPy-User] Strange behaviour of scipy.interpolate.interp1d in with kind="zero" In-Reply-To: References: Message-ID: Hi: I can confirm that the problem disappeared after upgrading scipy to 0.19.0 (numpy got updated as well) Cheers 2017-06-22 5:23 GMT-04:00 Propadovic Nenad : > Hello again, > OK, the problem went away when I upgraded scipy from 0.18.1 to 0.19.0 > (Anaconda didn't offer 1.0). > So I guess I have to apologize for bothering. > Regards, > Nenad > > 2017-06-22 10:45 GMT+02:00 Propadovic Nenad : > >> Hello Evgeni, >> sorry, somehow initially I had not seen your post. >> My OS is Windows 7 Professional N 64 bit. >> >> Python 2.7.13 |Anaconda 4.3.0 (64-bit) >> (yes I know Python 3.x is preferred, but that's the company choice that I >> can't influence... ) >> >> numpy.__version__ >> Out[2]: '1.11.3' >> >> scipy.__version__ >> Out[4]: '0.18.1' >> >> Yeah, maybe I can update Anaconda before calling out a bug. But the >> scipy-version is not soooo old. >> >> And, yes, I'm aware of the brittle nature of exact equality of floats... >> I often use code like following in my unit-tests: >> assert (numpy.all(abs(x-x_maybe_equal ) < 1e-12)) >> >> Cheers, >> >> Nenad >> >>> Cannot repro -- what numpy/scipy versions, OS? >>> >>> >>> >>> In [2]: %paste >>> import numpy >>> from scipy.interpolate import interp1d >>> >>> t = numpy.array([0.000, 0.004, 0.008, 0.012, 0.016, 0.02]) >>> sig = numpy.array([0, 1, 2, 3, 4, 5]) >>> t_new = numpy.array([0.0, 0.001, 0.003, 0.004, 0.008, 0.012, 0.016, >>> 0.0196, 0.02]) >>> >>> f = interp1d(t, sig, kind='zero') >>> s_resampled = f(t_new) >>> print s_resampled >>> ## -- End pasted text -- >>> [ 0. 0. 0. 1. 2. 3. 4. 4. 5.] >>> >>> In [3]: f(t) == sig >>> Out[3]: array([ True, True, True, True, True, True], dtype=bool) >>> >>> In [4]: numpy.__version__ >>> Out[4]: '1.10.4' >>> >>> In [5]: import scipy >>> >>> In [6]: scipy.__version__ >>> Out[6]: '1.0.0.dev0+f3e4e17' >>> >>> >>> Also note that exact equality in floating point is brittle anyway: >>> >>> In [9]: f(t_new.astype(numpy.float32)) >>> Out[9]: array([ 0., 0., 0., 1., 2., 3., 4., 4., 4.]) >>> >>> In [10]: f(t_new) >>> Out[10]: array([ 0., 0., 0., 1., 2., 3., 4., 4., 5.]) >>> >>> >>> Evgeni >>> >>> >>> >> > > _______________________________________________ > SciPy-User mailing list > SciPy-User at python.org > https://mail.python.org/mailman/listinfo/scipy-user > > -- Sasha -------------- next part -------------- An HTML attachment was scrubbed... URL: From fizis at outlook.com Fri Jun 23 03:07:30 2017 From: fizis at outlook.com (Ming Lu) Date: Fri, 23 Jun 2017 07:07:30 +0000 Subject: [SciPy-User] scipy.special.mathieu_modcem1 is not equal to the corresponding function in gsl Message-ID: Consider this code in python: import scipy.special as sp q=24 x=1.83 sp.mathieu_modcem1(0,q,x)[0] the result is: -0.094807461318619515 Translate into c++ with gsl: # include # include int main() { double q = 24; double x = 1.83; double y = gsl_sf_mathieu_Mc(1,0,q,x); std::cout << y << std::endl; return 0; } the result is: -0.118824 What's the problem? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Fri Jun 23 08:44:56 2017 From: pav at iki.fi (Pauli Virtanen) Date: Fri, 23 Jun 2017 14:44:56 +0200 Subject: [SciPy-User] scipy.special.mathieu_modcem1 is not equal to the corresponding function in gsl In-Reply-To: References: Message-ID: <204180f2-a86e-9ba4-0592-21d4cb56065a@iki.fi> GSL has prefactor of sqrt(pi/2). scipy iirc follows abramowitz&stegun. Ming Lu kirjoitti 23.06.2017 klo 09:07: > Consider this code in python: > > > import scipy.special as sp > q=24 > x=1.83 > sp.mathieu_modcem1(0,q,x)[0] > > > the result is: -0.094807461318619515 > > > Translate into c++ with gsl: > > > # include > # include > > int main() { > double q = 24; > double x = 1.83; > double y = gsl_sf_mathieu_Mc(1,0,q,x); > std::cout << y << std::endl; > return 0; > } > > > the result is: -0.118824 > > > What's the problem? > > > > _______________________________________________ > SciPy-User mailing list > SciPy-User at python.org > https://mail.python.org/mailman/listinfo/scipy-user > From ralf.gommers at gmail.com Fri Jun 23 11:27:12 2017 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sat, 24 Jun 2017 03:27:12 +1200 Subject: [SciPy-User] ANN: SciPy 0.19.1 release Message-ID: On behalf of the Scipy development team I am pleased to announce the availability of Scipy 0.19.1. This is a bugfix-only release, no new features are included. This release requires Python 2.7 or 3.4-3.6 and NumPy 1.8.2 or greater. Source tarballs and release notes can be found at https://github.com/scipy/scipy/releases/tag/v0.19.1. OS X and Linux wheels are available from PyPI: https://pypi.python.org/pypi/scipy/0.19.1 Thanks to everyone who contributed! Cheers, Ralf -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ========================== SciPy 0.19.1 Release Notes ========================== SciPy 0.19.1 is a bug-fix release with no new features compared to 0.19.0. The most important change is a fix for a severe memory leak in ``integrate.quad``. Authors ======= * Evgeni Burovski * Patrick Callier + * Yu Feng * Ralf Gommers * Ilhan Polat * Eric Quintero * Scott Sievert * Pauli Virtanen * Warren Weckesser A total of 9 people contributed to this release. People with a "+" by their names contributed a patch for the first time. This list of names is automatically generated, and may not be fully complete. Issues closed for 0.19.1 - ------------------------ - - `#7214 `__: Memory use in integrate.quad in scipy-0.19.0 - - `#7258 `__: ``linalg.matrix_balance`` gives wrong transformation matrix - - `#7262 `__: Segfault in daily testing - - `#7273 `__: ``scipy.interpolate._bspl.evaluate_spline`` gets wrong type - - `#7335 `__: scipy.signal.dlti(A,B,C,D).freqresp() fails Pull requests for 0.19.1 - ------------------------ - - `#7211 `__: BUG: convolve may yield inconsistent dtypes with method changed - - `#7216 `__: BUG: integrate: fix refcounting bug in quad() - - `#7229 `__: MAINT: special: Rewrite a test of wrightomega - - `#7261 `__: FIX: Corrected the transformation matrix permutation - - `#7265 `__: BUG: Fix broken axis handling in spectral functions - - `#7266 `__: FIX 7262: ckdtree crashes in query_knn. - - `#7279 `__: Upcast half- and single-precision floats to doubles in BSpline... - - `#7336 `__: BUG: Fix signal.dfreqresp for StateSpace systems - - `#7419 `__: Fix several issues in ``sparse.load_npz``, ``save_npz`` - - `#7420 `__: BUG: stats: allow integers as kappa4 shape parameters Checksums ========= MD5 ~~~ 72415e8da753eea97eb9820602931cb5 scipy-0.19.1-cp27-cp27m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl e0022540df2735eb0475071b266d5d71 scipy-0.19.1-cp27-cp27m-manylinux1_i686.whl f513eb4ea2086de169a502df7efb91c7 scipy-0.19.1-cp27-cp27m-manylinux1_x86_64.whl 906c3c59209d6249b5d8ce14cfa01382 scipy-0.19.1-cp27-cp27mu-manylinux1_i686.whl afbf8ffb4a4fe7c18e34cb8a313c18ee scipy-0.19.1-cp27-cp27mu-manylinux1_x86_64.whl 5ba945b3404644244ab469883a1723f0 scipy-0.19.1-cp34-cp34m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 9c02cdd79e4ffadddcce7b2212039816 scipy-0.19.1-cp34-cp34m-manylinux1_i686.whl 79c0ba3618466614744de9a2f5362bbc scipy-0.19.1-cp34-cp34m-manylinux1_x86_64.whl 602a741a54190e16698ff8b2fe9fd27c scipy-0.19.1-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl d6c2ecadd4df36eb61870227fae42d3a scipy-0.19.1-cp35-cp35m-manylinux1_i686.whl e7167c0a9cf270f89437e2fd09731636 scipy-0.19.1-cp35-cp35m-manylinux1_x86_64.whl fc2e4679e83590ff19c1a5c5b1aa4786 scipy-0.19.1-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 458615e9a56429a72038531dd5dcb3cb scipy-0.19.1-cp36-cp36m-manylinux1_i686.whl 65b1667ac56861da4cbc609960ed735b scipy-0.19.1-cp36-cp36m-manylinux1_x86_64.whl b704ebe9a28b8fe83d9f238d40031266 scipy-0.19.1.tar.gz cad6bac0638b176f72c00fe81ed54d19 scipy-0.19.1.tar.xz eb69261e5026ef2f3b9ae827caa7e5b8 scipy-0.19.1.zip SHA256 ~~~~~~ 1e8fedf602859b541ebae78667ccfc53158edef58d9ee19ee659309004565952 scipy-0.19.1-cp27-cp27m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 023ee29faa76c184a607e21076f097dc32f3abba7c71ece374588f95920aa993 scipy-0.19.1-cp27-cp27m-manylinux1_i686.whl 2a26d06a642e3c9107ca06df125f5dc5507abe2b87fd7865415d03ab654b0b43 scipy-0.19.1-cp27-cp27m-manylinux1_x86_64.whl b3e97be2cd9f052d984fc5ba2d441897971b744c64d658617944c47bc366f8ff scipy-0.19.1-cp27-cp27mu-manylinux1_i686.whl 78713101b32af384c564837fd7ae665a2a72cb6d49edbd8f32148d74724a65a8 scipy-0.19.1-cp27-cp27mu-manylinux1_x86_64.whl 2c9e87d556b83a8e11de7a064856c3997bbaff7f9cf62bf63ff0623751549e4c scipy-0.19.1-cp34-cp34m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl b87a923ed390ba0aafcbbcc6f0e023d495f19d2bd22ae59bdef3b0aec6485b39 scipy-0.19.1-cp34-cp34m-manylinux1_i686.whl 2dc9bcfaa585d9d941fb1add0d160556fe8587c3800264a77643695565a2d279 scipy-0.19.1-cp34-cp34m-manylinux1_x86_64.whl 93825cc80c638d901099f657dfff852ad2421beb51cb7d1d3f91157741ebe287 scipy-0.19.1-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 4118647273c907ed984da52b71fa2bbb30229f1820fb79b1ed087c8bc9a20cca scipy-0.19.1-cp35-cp35m-manylinux1_i686.whl 4c26ef44e8bb2cd2aef11c60d163caa04670d6f42996789b209526677310ded2 scipy-0.19.1-cp35-cp35m-manylinux1_x86_64.whl 2a3b6ceadbb58d8b8d4a329f8219f9e6f17757ec6c85baf03987bbd2b728c263 scipy-0.19.1-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 909be30bdd1d8cd57609760ea72a1499543169ed6ea5c66fad50946582682cf8 scipy-0.19.1-cp36-cp36m-manylinux1_i686.whl 4de84e3870228e8afd55a6e63e762aa7c9d1e3bd9a9ef5ab716835a69c77d257 scipy-0.19.1-cp36-cp36m-manylinux1_x86_64.whl 9147f7b8b5ed4b80fefe82057a6d0d4bf3a50375a1d573407f84686d3b82c3bb scipy-0.19.1.tar.gz 0dca04c4860afdcb066cab4fd520fcffa8c85e9a7b5aa37a445308e899d728b3 scipy-0.19.1.tar.xz 2cc1baed85f7f702d958ad19e5d11c9dad917e981d3d0c299a7f0fd15027516a scipy-0.19.1.zip -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJZTTG2AAoJEO2+o3i/Gl69V8gH/3S199hh1Fcl0a05VOCgt7aZ zRKvdZhYkqGvWoWX+YwJBaZn0aXThJfIDE2lAGt4S9PyxObBKzsujI8OLIZF4zU5 PtAARrooOqDEH1CC39k2gscF9GBhxAlxwntM2Hd8h+4xsklAhFVxn4UT0M8igBoX txpaIqghzBJnenkMq6lqrj7vhupuulz0zrMnJU4LetpdSxX1lb5sGvWmZDTKd/nr xmthQ4TmHPbf9jAYCtLI4V6OUGFGLQ+d7IqiYvU+DVKNZFEgyPMnvN9QvSdu6diR JBEIBcijxM0BqjPwRoavCQjCHk37kR/G3UsgcEyHO2tr5zuOXogjjBo3Bei8jnI= =lFXD -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From fizis at outlook.com Sat Jun 24 00:10:03 2017 From: fizis at outlook.com (Ming Lu) Date: Sat, 24 Jun 2017 04:10:03 +0000 Subject: [SciPy-User] =?gb2312?b?tPC4tDogIHNjaXB5LnNwZWNpYWwubWF0aGlldV9t?= =?gb2312?b?b2RjZW0xIGlzIG5vdCBlcXVhbCB0byB0aGUgY29ycmVzcG9uZGluZyBmdW5j?= =?gb2312?b?dGlvbiBpbiBnc2w=?= In-Reply-To: <204180f2-a86e-9ba4-0592-21d4cb56065a@iki.fi> References: , <204180f2-a86e-9ba4-0592-21d4cb56065a@iki.fi> Message-ID: Thanks for this comment, after I add that prefactor. It really works, i.e. the python's value equals the gsl value. However, it works only in the lower order. If I increase the order beyond 65, they deviates dramatically. "order" means the second argument in the gsl function. You can see from the figure, when order is between 0~60, they have the same value. But beyond that, they goes crazy. One of them must have problem, or even both. Anyone can tell me which one and how to figure it... A related question have been asked on stackoverflow: https://stackoverflow.com/questions/44713610/strange-behavior-of-scipy-special-mathieu-modcem-is-it-a-bug [https://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch-icon at 2.png?v=73d79a89bded] Strange behavior of scipy.special.mathieu_modcem, is it a bug? stackoverflow.com Consider the following code, the value seems to vanish as m increases: import scipy.special as sp import numpy as np import matplotlib.pyplot as plt q=24 mu0=1.83 m = range(50) y = sp.mathieu_modc... [cid:4c0f3f3f-9f17-4741-ac35-7d23c34e04d0] [cid:3844997a-b65a-4fde-b009-be98b289f4cb] ________________________________ ???: SciPy-User ?? Pauli Virtanen ????: 2017?6?23? 20:44:56 ???: scipy-user at python.org ??: Re: [SciPy-User] scipy.special.mathieu_modcem1 is not equal to the corresponding function in gsl GSL has prefactor of sqrt(pi/2). scipy iirc follows abramowitz&stegun. Ming Lu kirjoitti 23.06.2017 klo 09:07: > Consider this code in python: > > > import scipy.special as sp > q=24 > x=1.83 > sp.mathieu_modcem1(0,q,x)[0] > > > the result is: -0.094807461318619515 > > > Translate into c++ with gsl: > > > # include > # include > > int main() { > double q = 24; > double x = 1.83; > double y = gsl_sf_mathieu_Mc(1,0,q,x); > std::cout << y << std::endl; > return 0; > } > > > the result is: -0.118824 > > > What's the problem? > > > > _______________________________________________ > SciPy-User mailing list > SciPy-User at python.org > https://mail.python.org/mailman/listinfo/scipy-user > _______________________________________________ SciPy-User mailing list SciPy-User at python.org https://mail.python.org/mailman/listinfo/scipy-user -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ???? 2017-06-24 11.12.44.png Type: image/png Size: 441058 bytes Desc: ???? 2017-06-24 11.12.44.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ???? 2017-06-24 11.14.39.png Type: image/png Size: 227822 bytes Desc: ???? 2017-06-24 11.14.39.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ???? 2017-06-24 10.24.29.png Type: image/png Size: 171727 bytes Desc: ???? 2017-06-24 10.24.29.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ???? 2017-06-24 10.24.59.png Type: image/png Size: 98486 bytes Desc: ???? 2017-06-24 10.24.59.png URL: From eric at depagne.org Sun Jun 25 22:27:47 2017 From: eric at depagne.org (=?ISO-8859-1?Q?=C9ric?= Depagne) Date: Mon, 26 Jun 2017 04:27:47 +0200 Subject: [SciPy-User] Selecting elements in a numpy array by their indices contained in two arrays Message-ID: <2702311.GQ7nDSaZgA@notebook> Hi list. Suppose I have a numpy array A (4,4) and two 1D array, one (X1) that would contain (2,2,1,1) and the other one X2 that would be (3,3,3,3). Is there a way to select all the elements of A that have indices between X1 and X2? In the current case, that would mean selecting A[2:3,0], A[2:3,1], A[1:3,2] and A[1:3,3] Thanks. ?ric. -- Un clavier azerty en vaut deux ---------------------------------------------------------- ?ric Depagne eric at depagne.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierre.debuyl at kuleuven.be Mon Jun 26 06:49:53 2017 From: pierre.debuyl at kuleuven.be (Pierre de Buyl) Date: Mon, 26 Jun 2017 12:49:53 +0200 Subject: [SciPy-User] EuroSciPy 2017 call for contributions - extension of deadline Message-ID: <20170626104953.GA16487@pi-x230> (Apologies if you receive multiple copies of this message) 10th European Conference on Python in Science August 28 - September 1, 2017 in Erlangen, Germany The Call for Papers is extended to July 02, 2017 23:00 CEST Description: The EuroSciPy meeting is a cross-disciplinary gathering focused on the use and development of the Python language in scientific research. This event strives to bring together both users and developers of scientific tools, as well as academic research and state of the art industry. Erlangen is one of Germany's major science hubs and located north of Munich (90 minutes by train). The Call for Papers is extended to July 02, 2017 23:00 CEST Regards, The EuroSciPy team https://www.euroscipy.org/2017/ From robert.winkler.mail at gmail.com Mon Jun 26 18:23:06 2017 From: robert.winkler.mail at gmail.com (Robert Winkler) Date: Mon, 26 Jun 2017 17:23:06 -0500 Subject: [SciPy-User] Convert linkage matrix to tree (scipy.cluster.hierarchy.to_tree, python3) Message-ID: <9f649f05-cd76-d2b2-7aab-b2b532df69c6@gmail.com> Hi, I want to translate a linkage matrix to a tree (to convert it in further steps to newick format). The linkage matrix looks like this: |[[0.1.1.2.][2.4.4.3.][3.5.6.4.]]| When I run the code ('from ete3 import Tree'): |T =scipy.cluster.hierarchy.to_tree(Z)root =Tree()root.dist =0root.name ="root"item2node ={T:root}| the program terminates at item2node with the error message: Exception "unhandled TypeError" unhashable type: 'ClusterNode' Any ideas? Robert The data, I run Y = scipy.cluster.hierarchy.linkage(refspec_array, 'complete') print(Y) T = scipy.cluster.hierarchy.to_tree(Y) look like this: [ ('1', 0.0, 0.0, 0.0, 0.0, 4.38755898755899, 0.0, 0.0, 11.4813953488372, 0.0, 0.0, 0.0, 0.0, 0.0, 3.37222222222222, 17.453347427766, 0.0, 0.0, 0.0, 6.10327695560254, 0.0, 0.0, 0.0, 12.4255813953488, 0.0, 5.1536069904491, 0.0, 0.0, 15.016330162086, 3.16285714285714, 3.83170731707317, 0.0, 18.7087586831773, 7.88292682926829, 45.4125613035912, 10.4775101513474, 12.0366102889359, 0.0, 0.0, 0.0, 3.2839463523674, 14.2130258077626, 70.5372093023256, 13.6720930232558, 19.715657343224, 4.91362382790954, 7.00714285714286, 0.0, 3.6776026026026, 0.0, 15.3790697674419, 4.15201131363922, 56.9372093023256, 0.0, 0.0, 0.0, 22.5604743447767, 0.0, 8.04212974296206, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 19.002380952381, 4.03296703296703, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 4.67, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0) ('2', 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 3.27097625891554, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 3.80990740740741, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 21.6565696834911, 6.580014781966, 19.9112912622229, 0.0, 0.0, 0.0, 0.0, 5.2982335122579, 52.672519005238, 25.1761382113821, 58.6225154191197, 6.53954083820578, 5.0235253034919, 0.0, 5.59207185091331, 6.8450632459782, 41.9248475609756, 8.94831608491355, 17.9927195135152, 3.56784893267652, 0.0, 0.0, 14.6637340301974, 10.2320372068382, 87.4304539295393, 17.6128532713899, 3.61942687747036, 4.9223667570009, 21.7575067583061, 4.87, 10.0497729362015, 7.4825, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0)..] -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren.weckesser at gmail.com Mon Jun 26 18:38:00 2017 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Mon, 26 Jun 2017 18:38:00 -0400 Subject: [SciPy-User] Convert linkage matrix to tree (scipy.cluster.hierarchy.to_tree, python3) In-Reply-To: <9f649f05-cd76-d2b2-7aab-b2b532df69c6@gmail.com> References: <9f649f05-cd76-d2b2-7aab-b2b532df69c6@gmail.com> Message-ID: On Mon, Jun 26, 2017 at 6:23 PM, Robert Winkler < robert.winkler.mail at gmail.com> wrote: > Hi, > > I want to translate a linkage matrix to a tree (to convert it in further > steps to newick format). The linkage matrix looks like this: > > [[ 0. 1. 1. 2.][ 2. 4. 4. 3.][ 3. 5. 6. 4.]] > > When I run the code ('from ete3 import Tree'): > > T = scipy.cluster.hierarchy.to_tree(Z) > root = Tree() > root.dist = 0 > root.name = "root" > item2node = {T: root} > > the program terminates at item2node with the error message: > > Exception "unhandled TypeError" > unhashable type: 'ClusterNode' > > Any ideas? > > Robert > > > I don't know what is causing the unhandled exception, but the second part of that error message explains the problem (well, in Python-speak, anyway): you can't use T as the key of a dictionary because T is "unhashable". Here's another example of the error: In [13]: y = np.random.randint(0, 5, size=(4, 3)) In [14]: Z = linkage(y) In [15]: T = to_tree(Z) In [16]: d = {T: 0} # Try to create a dictionary with T as a key --------------------------------------------------------------------------- TypeError Traceback (most recent call last) in () ----> 1 d = {T: 0} TypeError: unhashable type: 'ClusterNode' You'll also get that error if you try hash(T) (where hash is the builtin Python function): In [22]: hash(T) --------------------------------------------------------------------------- TypeError Traceback (most recent call last) in () ----> 1 hash(T) TypeError: unhashable type: 'ClusterNode' Warren > The data, I run > > Y = scipy.cluster.hierarchy.linkage(refspec_array, 'complete') > print(Y) > T = scipy.cluster.hierarchy.to_tree(Y) > > look like this: > > [ ('1', 0.0, 0.0, 0.0, 0.0, 4.38755898755899, 0.0, 0.0, 11.4813953488372, > 0.0, 0.0, 0.0, 0.0, 0.0, 3.37222222222222, 17.453347427766, 0.0, 0.0, 0.0, > 6.10327695560254, 0.0, 0.0, 0.0, 12.4255813953488, 0.0, 5.1536069904491, > 0.0, 0.0, 15.016330162086, 3.16285714285714, 3.83170731707317, 0.0, > 18.7087586831773, 7.88292682926829, 45.4125613035912, 10.4775101513474, > 12.0366102889359, 0.0, 0.0, 0.0, 3.2839463523674, 14.2130258077626, > 70.5372093023256, 13.6720930232558, 19.715657343224, 4.91362382790954, > 7.00714285714286, 0.0, 3.6776026026026, 0.0, 15.3790697674419, > 4.15201131363922, 56.9372093023256, 0.0, 0.0, 0.0, 22.5604743447767, 0.0, > 8.04212974296206, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, > 19.002380952381, 4.03296703296703, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, > 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 4.67, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, > 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, > 0.0, 0.0) > ('2', 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 3.27097625891554, 0.0, > 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 3.80990740740741, 0.0, 0.0, 0.0, 0.0, > 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 21.6565696834911, > 6.580014781966, 19.9112912622229, 0.0, 0.0, 0.0, 0.0, 5.2982335122579, > 52.672519005238, 25.1761382113821, 58.6225154191197, 6.53954083820578, > 5.0235253034919, 0.0, 5.59207185091331, 6.8450632459782, 41.9248475609756, > 8.94831608491355, 17.9927195135152, 3.56784893267652, 0.0, 0.0, > 14.6637340301974, 10.2320372068382, 87.4304539295393, 17.6128532713899, > 3.61942687747036, 4.9223667570009, 21.7575067583061, 4.87, > 10.0497729362015, 7.4825, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, > 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, > 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, > 0.0, 0.0, 0.0, 0.0)..] > > _______________________________________________ > SciPy-User mailing list > SciPy-User at python.org > https://mail.python.org/mailman/listinfo/scipy-user > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at depagne.org Mon Jun 26 19:40:20 2017 From: eric at depagne.org (=?ISO-8859-1?Q?=C9ric?= Depagne) Date: Tue, 27 Jun 2017 01:40:20 +0200 Subject: [SciPy-User] Selecting elements in a numpy array by their indices contained in two arrays In-Reply-To: <2702311.GQ7nDSaZgA@notebook> References: <2702311.GQ7nDSaZgA@notebook> Message-ID: <88155528.hj84zYeio9@notebook> Le lundi 26 juin 2017, 04:27:47 SAST ?ric Depagne a ?crit : > Hi list. Hi list, Some more details on my problem. I know that I can select the elements individually through a for loop, and that will provide me with the extraction I need, but I was wondering if there was a way to do that without a loop. Repeating 4 times A[X1[i]:X2[i],1] will work fine, but I was looking for something like A[X1:X2, 1] Since in my problem, A is (4000x2000), X1 and X2 (2000,1), avoiding unnecessary loops will make a significant difference. Thanks. ?ric. > > Suppose I have a numpy array A (4,4) and two 1D array, one (X1) that would > contain (2,2,1,1) and the other one X2 that would be (3,3,3,3). > Is there a way to select all the elements of A that have indices between X1 > and X2? In the current case, that would mean selecting A[2:3,0], A[2:3,1], > A[1:3,2] and A[1:3,3] > > Thanks. > ?ric. -- Un clavier azerty en vaut deux ---------------------------------------------------------- ?ric Depagne eric at depagne.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.kern at gmail.com Mon Jun 26 19:47:20 2017 From: robert.kern at gmail.com (Robert Kern) Date: Mon, 26 Jun 2017 16:47:20 -0700 Subject: [SciPy-User] Selecting elements in a numpy array by their indices contained in two arrays In-Reply-To: <88155528.hj84zYeio9@notebook> References: <2702311.GQ7nDSaZgA@notebook> <88155528.hj84zYeio9@notebook> Message-ID: On Mon, Jun 26, 2017 at 4:40 PM, ?ric Depagne wrote: > > Le lundi 26 juin 2017, 04:27:47 SAST ?ric Depagne a ?crit : > > > Hi list. > > Hi list, > > Some more details on my problem. > > I know that I can select the elements individually through a for loop, and that will provide me with the extraction I need, but I was wondering if there was a way to do that without a loop. > > Repeating 4 times A[X1[i]:X2[i],1] will work fine, but I was looking for something like > A[X1:X2, 1] There isn't one since for each `i`, there will be a different number of items in the slice, so the result would not be able to be fit into an array with a uniform shape. The loop is the right way to do this. -- Robert Kern -------------- next part -------------- An HTML attachment was scrubbed... URL: From jni.soma at gmail.com Mon Jun 26 20:18:25 2017 From: jni.soma at gmail.com (Juan Nunez-Iglesias) Date: Tue, 27 Jun 2017 10:18:25 +1000 Subject: [SciPy-User] Selecting elements in a numpy array by their indices contained in two arrays In-Reply-To: References: <2702311.GQ7nDSaZgA@notebook> <88155528.hj84zYeio9@notebook> Message-ID: <73946fbf-71d6-4f6b-acf3-9a458453e828@Spark> Well, the resulting array size is known ahead of time. I haven?t come up with a nice vectorised NumPy way to do it, but I would recommend preallocating the result array and then using Numba or Cython to loop. You?ll get some pretty nice speed. Also, since you are grabbing column-wise chunks, if possible, I would suggest making sure your A matrix has order=?F?. (Incidentally, if you want to keep track of the origin columns, I think scipy.sparse.csc_matrix is a nice format for the result.) Juan. On 27 Jun 2017, 9:48 AM +1000, Robert Kern , wrote: > On Mon, Jun 26, 2017 at 4:40 PM, ?ric Depagne wrote: > > > > Le lundi 26 juin 2017, 04:27:47 SAST ?ric Depagne a ?crit : > > > > > Hi list. > > > > Hi list, > > > > Some more details on my problem. > > > > I know that I can select the elements individually through a for loop, and that will provide me with the extraction I need, but I was wondering if there was a way to do that without a loop. > > > > Repeating 4 times A[X1[i]:X2[i],1] will work fine, but I was looking for something like > > A[X1:X2, 1] > > There isn't one since for each `i`, there will be a different number of items in the slice, so the result would not be able to be fit into an array with a uniform shape. The loop is the right way to do this. > > -- > Robert Kern > _______________________________________________ > SciPy-User mailing list > SciPy-User at python.org > https://mail.python.org/mailman/listinfo/scipy-user -------------- next part -------------- An HTML attachment was scrubbed... URL: From barth.alexander at gmail.com Tue Jun 27 03:30:44 2017 From: barth.alexander at gmail.com (Alexander Barth) Date: Tue, 27 Jun 2017 09:30:44 +0200 Subject: [SciPy-User] Selecting elements in a numpy array by their indices contained in two arrays In-Reply-To: <73946fbf-71d6-4f6b-acf3-9a458453e828@Spark> References: <2702311.GQ7nDSaZgA@notebook> <88155528.hj84zYeio9@notebook> <73946fbf-71d6-4f6b-acf3-9a458453e828@Spark> Message-ID: Dear Eric, I think you can use numpy.ravel_multi_index for this. https://docs.scipy.org/doc/numpy/reference/generated/numpy.ravel_multi_index.html Here is an example: In [10]: A = np.random.randn(4,4) In [11]: A Out[11]: array([[ 1.9158152 , -0.69065018, 0.71567087, -1.31872821], [ 1.00126163, 0.34461176, 0.30298258, -1.19507848], [-0.14355935, 0.18827163, 0.78383867, -1.01362843], [ 0.33303015, -1.49289243, -1.02713378, 0.24379566]]) In [12]: i = np.array([2,2,1,1]) In [13]: j = np.array([3,3,3,3]) In [16]: ij = np.ravel_multi_index((i,j),A.shape) In [17]: ij Out[17]: array([11, 11, 7, 7]) In [21]: A.flatten()[ij] Out[21]: array([-1.01362843, -1.01362843, -1.19507848, -1.19507848]) In [23]: [A[i[l],j[l]] for l in range(len(i))] Out[23]: [-1.0136284267170597, -1.0136284267170597, -1.195078482610719, -1.195078482610719] I hope this helps, Cheers, Alex