Mailman 3 December 2015 - NumPy-Discussion

numpy.power -> numpy.random.choice Probabilities don't sum to 1
by Ryan R. Rosario Dec. 19, 2015

Dec. 19, 2015

Hi, I have a matrix whose entries I must raise to a certain power and then normalize by row. After I do that, when I pass some rows to numpy.random.choice, I get a ValueError: probabilities do not sum to 1. I understand that floating point is not perfect, and my matrix is so large that I cannot use np.longdouble because I will run out of RAM. As an example on a smaller matrix: np.power(mymatrix, 10, out=mymatrix) row_normalized = np.apply_along_axis(lambda x: x / np.sum(x), 1, mymatrix) … [View More]

4 3

7th Annual Scientific Software Days Conference (25-26 February, 2016 -- Austin, TX)
by Damon McDougall Dec. 18, 2015

Dec. 18, 2015

The 7th Annual Scientific Software Days Conference (SSD) <http://scisoftdays.org/> targets users and developers of scientific software. The conference will be held at the University of Texas at Austin Thursday Feb 25 - Friday Feb 26, 2016 and focuses on two themes: a) sharing best practices across scientific software communities; b) sharing the latest tools and technology relevant to scientific software. Past keynotes speakers include Greg Wilson (2008), Victoria Stodden (2009), … [View More]

1 0

Introducing outer/orthonongal indexing to numpy
by Sebastian Berg Dec. 18, 2015

Dec. 18, 2015

Hello all, sorry for cross posting (discussion should go to the numpy list). But I would like to get a bit of discussion on the introduction of (mostly) two new ways to index numpy arrays. This would also define a way for code working with different array-likes, some of which implement outer indexing (i.e. xray and dask I believe), to avoid ambiguity. The new methods are (names up for discussion): 1. arr.oindex[...] 2. arr.vindex[...] The difference beeing that `oindex` will return outer/… [View More]orthogonal type indexing, while `vindex` would be a (hopefully) less confusing variant of "fancy" indexing. The biggest reason for introducing this is to provide `oindex` for situations such as: >>> arr = np.arange(25).reshape((5, 5)) >>> arr[[0, 1], [1, 2]] array([1, 7]) >>> # While most might expect the result to be: >>> arr.oindex[[0, 1], [1, 2]] array([[1, 2], [6, 7]]) To provide backwards compatibility the current plan is to also introduce `arr.legacy_index[...]` or similar, with the (long term) plan to force the users to explicitly choose `oindex`, `vindex`, or `legacy_index` if the indexing operation is otherwise not well defined. There are still some open questions for me regarding, for example: * the exact time line (should we start deprecation immediately, etc.) * the handling of boolean indexing arrays * questions that might crop up about other array-likes/subclasses * Are there indexing needs that we are forgetting but are related? More details the current status of my NEP, which has a lot of examples, can be found at: https://github.com/numpy/numpy/pull/6256/files?short_path=01e4dd9#diff-01e4… and comments about are very welcome. There is a fully functional implementation available at https://github.com/numpy/numpy/pull/6075 and you can test it using (after cloning numpy): git fetch upstream pull/6075/head:pr-6075 && git checkout pr-6075; python runtests.py --ipython # Inside ipython (too see the deprecations): import warnings; warnings.simplefilter("always") My current hope for going forward is to get clear feedback of what is wanted, for the naming and generally from third party module people, so that we can polish up the NEP and the community can accept it. With good feedback, I think we may be able to get the new attributes into 1.11. So if you are interested in teaching and have suggestions for the names, or have thoughts about subclasses, or... please share your thoughts! :) Regards, Sebastian [View Less]

1 0

array_equal too strict?
by Nico Schlömer Dec. 17, 2015

Dec. 17, 2015

Hi everyone, I noticed a funny behavior in numpy's array_equal. The two arrays ``` a1 = numpy.array( [3.14159265358979320], dtype=numpy.float64 ) a2 = numpy.array( [3.14159265358979329], dtype=numpy.float64 ) ``` (differing the in the 18th overall digit) are reported equal by array_equal: ``` print(numpy.array_equal(a1, a2)) # output: true ``` That's expected because the difference is only in the 18th overall digit, and the mantissa length of float64 is 52 bits [1], i.e.… [View More]

4 3

A minor clarification no why count_nonzero is faster for boolean arrays
by Raghav R V Dec. 17, 2015

Dec. 17, 2015

I was just playing with `count_nonzero` and found it to be significantly faster for boolean arrays compared to integer arrays >>> a = np.random.randint(0, 2, (100, 5)) >>> a_bool = a.astype(bool) >>> %timeit np.sum(a) 100000 loops, best of 3: 5.64 µs per loop >>> %timeit np.count_nonzero(a) 1000000 loops, best of 3: 1.42 us per loop >>> %timeit np.count_nonzero(a_bool) 1000000 loops, best of 3: 279 ns per loop (… [View More]

4 4

Re: [Numpy-discussion] performance solving system of equations in numpy and MATLAB
by Edward Richards Dec. 17, 2015

Dec. 17, 2015

Thanks everyone for helping me glimpse the secret world of FORTRAN compilers. I am running a Linux machine, so I will look into MKL and openBLAS. It was easy for me to get a Intel parallel studio XE license as a student, so I have options.

1 0

performance solving system of equations in numpy and MATLAB
by Edward Richards Dec. 17, 2015

Dec. 17, 2015

I recently did a conceptual experiment to estimate the computational time required to solve an exact expression in contrast to an approximate solution (Helmholtz vs. Helmholtz-Kirchhoff integrals). The exact solution requires a matrix inversion, and in my case the matrix would contain ~15000 rows. On my machine MATLAB seems to perform this matrix inversion with random matrices about 9x faster (20 sec vs 3 mins). I thought the performance would be roughly the same because I presume both … [View More]

11 13

Why does np.repeat build a full array?
by Juan Nunez-Iglesias Dec. 16, 2015

Dec. 16, 2015

Hi, I've recently been using the following pattern to create arrays of a specific repeating value: from numpy.lib.stride_tricks import as_strided value = np.ones((1,), dtype=float) arr = as_strided(value, shape=input_array.shape, strides=(0,)) I can then use arr e.g. to count certain pairs of elements using sparse.coo_matrix. It occurred to me that numpy might have a similar function, and found np.repeat. But it seems that repeat actually creates the full, replicated array, rather than using … [View More]

2 3

Build broken
by Jaime Fernández del Río Dec. 15, 2015

Dec. 15, 2015

Hi, Travis is repeatedly being unable to complete one of our test builds. It all started after I merged a very simple PR that changed a single word in a docstring, so I have a hard time believing that is the actual cause. Can anyone who actually knows what Travis is doing take a look at the log: https://travis-ci.org/numpy/numpy/builds/96836128 Thanks, Jaime -- (\__/) ( O.o) ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial.

4 4

Question about nump.ma.polyfit
by Samuel Dupree Dec. 15, 2015

Dec. 15, 2015

I'm running Python 2.7.11 from the Anaconda distribution (version 2.4.1) on a MacBook Pro running Mac OS X version 10.11.2 (El Capitan) I'm attempting to use numpy.ma.polyfit to perform a linear least square fit on some data I have. I'm running NumPy version 1.10.1. I've observed that in executing either numpy.polyfit or numpy.ma.polyfit I get the following traceback: /Users/user/anaconda/lib/python2.7/site-packages/numpy/lib/polynomial.py:594: RankWarning: Polyfit may be poorly … [View More]

2 1

cross platform build issue: powerpc-e500v2-linux-gnuspe-gcc: error: unrecognized argument in option '-mtune=generic'
by jo Dec. 15, 2015

Dec. 15, 2015

Hi I am trying to do a cross platform build of numpy (host=x86 target=ppc). This worked for python compiler itself but for numpy I run into following problem. It does select the correct compiler but the options are not correct. please advise... numpy-1.10.2rc2]$ CC=powerpc-e500v2-linux-gnuspe-gcc CXX=powerpc-e500v2-linux-gnuspe-g++ AR=powerpc-e500v2-linux-gnuspe-ar &… [View More]nbsp; BLAS=None LAPACK=None ATLAS=None python setup.py build bdist_egg --plat-name=powerpc powerpc-e500v2-linux-gnuspe-gcc: _configtest.c powerpc-e500v2-linux-gnuspe-gcc: error: unrecognized argument in option '-mtune=generic' powerpc-e500v2-linux-gnuspe-gcc: note: valid arguments to '-mtune=' are: 401 403 405 405fp 440 440fp 464 464fp 476 476fp 505 601 602 603 603e 604 604e 620 630 740 7400 7450 750 801 821 823 8540 8548 860 970 G3 G4 G5 a2 cell common e300c2 e300c3 e500mc e500mc64 ec603e native power power2 power3 power4 power5 power5+ power6 power6x power7 powerpc powerpc64 rios rios1 rios2 rs64 rsc rsc1 titan powerpc-e500v2-linux-gnuspe-gcc: error: unrecognized argument in option '-mtune=generic' powerpc-e500v2-linux-gnuspe-gcc: note: valid arguments to '-mtune=' are: 401 403 405 405fp 440 440fp 464 464fp 476 476fp 505 601 602 603 603e 604 604e 620 630 740 7400 7450 750 801 821 823 8540 8548 860 970 G3 G4 G5 a2 cell common e300c2 e300c3 e500mc e500mc64 ec603e native power power2 power3 power4 power5 power5+ power6 power6x power7 powerpc powerpc64 rios rios1 rios2 rs64 rsc rsc1 titan powerpc-e500v2-linux-gnuspe-gcc: error: unrecognized argument in option '-mtune=generic' powerpc-e500v2-linux-gnuspe-gcc: note: valid arguments to '-mtune=' are: 401 403 405 405fp 440 440fp 464 464fp 476 476fp 505 601 602 603 603e 604 604e 620 630 740 7400 7450 750 801 821 823 8540 8548 860 970 G3 G4 G5 a2 cell common e300c2 e300c3 e500mc e500mc64 ec603e native power power2 power3 power4 power5 power5+ power6 power6x power7 powerpc powerpc64 rios rios1 rios2 rs64 rsc rsc1 titan powerpc-e500v2-linux-gnuspe-gcc: error: unrecognized argument in option '-mtune=generic' powerpc-e500v2-linux-gnuspe-gcc: note: valid arguments to '-mtune=' are: 401 403 405 405fp 440 440fp 464 464fp 476 476fp 505 601 602 603 603e 604 604e 620 630 740 7400 7450 750 801 821 823 8540 8548 860 970 G3 G4 G5 a2 cell common e300c2 e300c3 e500mc e500mc64 ec603e native power power2 power3 power4 power5 power5+ power6 power6x power7 powerpc powerpc64 rios rios1 rios2 rs64 rsc rsc1 titan failure. removing: _configtest.c _configtest.o Traceback (most recent call last): File "setup.py", line 266, in <module> setup_package() File "setup.py", line 258, in setup_package setup(**metadata) File "/home/jenkins/Python-2.7.3/tmp/numpy-1.10.2rc2/numpy/distutils/core.py", line 169, in setup return old_setup(**new_attr) File "/usr/lib64/python2.6/distutils/core.py", line 152, in setup dist.run_commands() File "/usr/lib64/python2.6/distutils/dist.py", line 975, in run_commands self.run_command(cmd) File "/usr/lib64/python2.6/distutils/dist.py", line 995, in run_command cmd_obj.run() File "/home/jenkins/Python-2.7.3/tmp/numpy-1.10.2rc2/numpy/distutils/command/build.py", line 47, in run old_build.run(self) File "/usr/lib64/python2.6/distutils/command/build.py", line 134, in run self.run_command(cmd_name) File "/usr/lib64/python2.6/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/usr/lib64/python2.6/distutils/dist.py", line 995, in run_command cmd_obj.run() File "/home/jenkins/Python-2.7.3/tmp/numpy-1.10.2rc2/numpy/distutils/command/build_src.py", line 153, in run self.build_sources() File "/home/jenkins/Python-2.7.3/tmp/numpy-1.10.2rc2/numpy/distutils/command/build_src.py", line 164, in build_sources self.build_library_sources(*libname_info) File "/home/jenkins/Python-2.7.3/tmp/numpy-1.10.2rc2/numpy/distutils/command/build_src.py", line 299, in build_library_sources sources = self.generate_sources(sources, (lib_name, build_info)) File "/home/jenkins/Python-2.7.3/tmp/numpy-1.10.2rc2/numpy/distutils/command/build_src.py", line 387, in generate_sources source = func(extension, build_dir) File "numpy/core/setup.py", line 669, in get_mathlib_info raise RuntimeError("Broken toolchain: cannot link a simple C program") RuntimeError: Broken toolchain: cannot link a simple C program Thanks, Jo [View Less]

1 0

Fwd: Python 3.3 i386 Build
by G Young Dec. 14, 2015

Dec. 14, 2015

I accidentally subscribed to the defunct discussion mailing list, so my email got rejected the first time I sent to the active mailing list. My question is in the forwarded email below: ---------- Forwarded message ---------- From: G Young <gfyoung17(a)gmail.com> Date: Mon, Dec 14, 2015 at 3:47 PM Subject: re: Python 3.3 i386 Build To: numpy-discussion(a)scipy.org Hello all, I was wondering if anyone else has been running into issues with the Python 3.3 i386 build on Travis. There … [View More]

1 0

NumPy 1.10.2 release
by Charles R Harris Dec. 14, 2015

Dec. 14, 2015

Hi All, I'm pleased to announce the release of Numpy 1.10.2. This release should take care of the bugs discovered in the 1.10.1 release, some of them severe. Upgrading is strongly advised if you are currently using 1.10.1. Windows binaries and source releases can be found at the usual place on Sourceforge <https://sourceforge.net/projects/numpy/files/NumPy/1.10.2/>. The sources are also available from PyPi <https://pypi.python.org/pypi/numpy/>. Cheers, Chuck

1 0

Numpy intermittent seg fault
by Jacopo Sabbatini Dec. 13, 2015

Dec. 13, 2015

Hi, I'm experiencing random segmentation faults from numpy. I have generated a core dumped and extracted a stack trace, the following: #0 0x00007f3a8d921d5d in getenv () from /lib64/libc.so.6 #1 0x00007f3a843bde21 in blas_set_parameter () from /opt/apps/sidescananalysis-9.7.1-42-gdd3e068+dev/lib/python2.7/site-packages/numpy/core/../../../../libopenblas.so.0 #2 0x00007f3a843bcd91 in blas_memory_alloc () from /opt/apps/sidescananalysis-9.7.1-42-gdd3e068+dev/lib/python2.7/site-packages/numpy/… [View More]

3 3

Re: [Numpy-discussion] Memory mapping and NPZ files
by Nathaniel Smith Dec. 12, 2015

Dec. 12, 2015

On Dec 12, 2015 10:53 AM, "Mathieu Dubois" <mathieu.dubois(a)icm-institute.org> wrote: > > Le 11/12/2015 11:22, Sturla Molden a écrit : >> >> Mathieu Dubois <mathieu.dubois(a)icm-institute.org> wrote: >> >>> The point is precisely that, you can't do memory mapping with Npz files >>> (while it works with Npy files). >> >> The operating system can memory map any file. But as npz-files are >> compressed, you will need to … [View More]

1 0

Re: [Numpy-discussion] FeatureRequest: support for array
by Peter Creasey Dec. 12, 2015

Dec. 12, 2015

> > > > from itertools import chain > > def fromiter_awesome_edition(iterable): > > elem = next(iterable) > > dtype = whatever_numpy_does_to_infer_dtypes_from_lists(elem) > > return np.fromiter(chain([elem], iterable), dtype=dtype) > > > > I think this would be a huge win for usability. Always getting tripped up by > > the dtype requirement. I can submit a PR if people like this pattern. > > This isn't the semantics of np.… [View More]

1 0

Fast vectorized arithmetic with ~32 significant digits under Numpy
by Thomas Baruchel Dec. 12, 2015

Dec. 12, 2015

>From time to time it is asked on forums how to extend precision of computation on Numpy array. The most common answer given to this question is: use the dtype=object with some arbitrary precision module like mpmath or gmpy. See http://stackoverflow.com/questions/6876377/numpy-arbitrary-precision-linear… or http://stackoverflow.com/questions/21165745/precision-loss-numpy-mpmath or http://stackoverflow.com/questions/15307589/numpy-array-with-mpz-mpfr-values While this is obviously the most … [View More]relevant answer for many users because it will allow them to use Numpy arrays exactly as they would have used them with native types, the wrong thing is that from some point of view "true" vectorization will be lost. With years I got very familiar with the extended double-double type which has (for usual architectures) about 32 accurate digits with faster arithmetic than "arbitrary precision types". I even used it for research purpose in number theory and I got convinced that it is a very wonderful type as long as such precision is suitable. I often implemented it partially under Numpy, most of the time by trying to vectorize at a low-level the libqd library. But I recently thought that a very nice and portable way of implementing it under Numpy would be to use the existing layer of vectorization on floats for computing the arithmetic operations by "columns containing half of the numbers" rather than by "full numbers". As a proof of concept I wrote the following file: https://gist.github.com/baruchel/c86ed748939534d8910d I converted and vectorized the Algol 60 codes from http://szmoore.net/ipdf/documents/references/dekker1971afloating.pdf (Dekker, 1971). A test is provided at the end; for inverting 100,000 numbers, my type is about 3 or 4 times faster than GMPY and almost 50 times faster than MPmath. It should be even faster for some other operations since I had to create another np.ones array for testing this type because inversion isn't implemented here (which could of course be done). You can run this file by yourself (maybe you will have to discard mpmath or gmpy if you don't have it). I would like to discuss about the way to make available something related to that. a) Would it be relevant to include that in Numpy ? (I would think to some "contribution"-tool rather than including it in the core of Numpy because it would be painful to code all ufuncs; on the other hand I am pretty sure that many would be happy to perform several arithmetic operations by knowing that they can't use cos/sin/etc. on this type; in other words, I am not sure it would be a good idea to embed it as an every-day type but I think it would be nice to have it quickly available in some way). If you agree with that, in which way should I code it (the current link only is a "proof of concept"; I would be very happy to code it in some cleaner way)? b) Do you think such attempt should remain something external to Numpy itself and be released on my Github account without being integrated to Numpy? Best regards, -- Thomas Baruchel [View Less]

11 12

Re: [Numpy-discussion] Memory mapping and NPZ files
by Sturla Molden Dec. 12, 2015

Dec. 12, 2015

Mathieu Dubois <mathieu.dubois(a)icm-institute.org> wrote: > The point is precisely that, you can't do memory mapping with Npz files > (while it works with Npy files). The operating system can memory map any file. But as npz-files are compressed, you will need to uncompress the contents in your memory mapping to make sense of it. I would suggest you use PyTables instead of npz-files. It allows on the fly compression and uncompression (via blosc) and will probably do what you want. Sturla

2 1

Re: [Numpy-discussion] Memory mapping and NPZ files
by Erik Bray Dec. 11, 2015

Dec. 11, 2015

On Wed, Dec 9, 2015 at 9:51 AM, Mathieu Dubois <mathieu.dubois(a)icm-institute.org> wrote: > Dear all, > > If I am correct, using mmap_mode with Npz files has no effect i.e.: > f = np.load("data.npz", mmap_mode="r") > X = f['X'] > will load all the data in memory. > > Can somebody confirm that? > > If I'm correct, the mmap_mode argument could be passed to the NpzFile class > which could in turn perform the correct operation. One way to handle that > … [View More]

1 0

ANN: pyMIC v0.7 Released
by Klemm, Michael Dec. 11, 2015

Dec. 11, 2015

Announcement: pyMIC v0.7 ========================= I'm happy to announce the release of pyMIC v0.7. pyMIC is a Python module to offload computation in a Python program to the Intel Xeon Phi coprocessor. It contains offloadable arrays and device management functions. It supports invocation of native kernels (C/C++, Fortran) and blends in with Numpy's array types for float, complex, and int data types. For more information and downloads please visit pyMIC's Github page: https://github.com/… [View More]01org/pyMIC. You can find pyMIC's mailinglist at https://lists.01.org/mailman/listinfo/pymic. Full change log: ================= Version 0.7 ---------------------------- * Experimental support for Python 3. * 'None' arguments of kernels are converted to nullptr or NULL. * Switched to Python's distutils to build and install pyMIC. * Deprecated the build system based on Makefiles. Version 0.6 ---------------------------- * Experimental support for the Windows operating system. * Switched to Cython to generate the glue code for pyMIC. * Now using Markdown for README and CHANGELOG. * Introduced PYMIC_DEBUG=3 to trace argument passing for kernels. * Bugfix: added back the translate_device_pointer() function. * Bugfix: example SVD now respects order of the passed matrices when applying the `dgemm` routine. * Bugfix: fixed memory leak when invoking kernels. * Bugfix: fixed broken translation of fake pointers. * Refactoring: simplified bridge between pyMIC and LIBXSTREAM. Version 0.5 ---------------------------- * Introduced new kernel API that avoids insane pointer unpacking. * pyMIC now uses libxstreams as the offload back-end (https://github.com/hfp/libxstream). * Added smart pointers to make handling of fake pointers easier. Version 0.4 ---------------------------- * New low-level API to allocate, deallocate, and transfer data (see OffloadStream). * Support for in-place binary operators. * New internal design to handle offloads. Version 0.3 ---------------------------- * Improved handling of libraries and kernel invocation. * Trace collection (PYMIC_TRACE=1, PYMIC_TRACE_STACKS={none,compact,full}). * Replaced the device-centric API with a stream API. * Refactoring to better match PEP8 recommendations. * Added support for int(int64) and complex(complex128) data types. * Reworked the benchmarks and examples to fit the new API. * Bugfix: fixed syntax errors in OffloadArray. Version 0.2 ---------------------------- * Small improvements to the README files. * New example: Singular Value Decomposition. * Some documentation for the API functions. * Added a basic testsuite for unit testing (WIP). * Bugfix: benchmarks now use the latest interface. * Bugfix: numpy.ndarray does not offer an attribute 'order'. * Bugfix: number_of_devices was not visible after import. * Bugfix: member offload_array.device is now initialized. * Bugfix: use exception for errors w/ invoke_kernel & load_library. Version 0.1 ---------------------------- Initial release. Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928 [View Less]

1 0

When to stop supporting Python 2.6?
by Charles R Harris Dec. 11, 2015

Dec. 11, 2015

Hi All, Thought I would raise the topic apropos this post <http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html> . There is not a great advantage to dropping 2.6, OTOH, 2.7 has more features (memoryview) and we could clean up the code a bit. Along the same lines, dropping support for Python 3.2 would allow more cleanup. In fact, I'd like to get to 3.4 as soon as possible, but don't know what would be a reasonable schedule. The Python 3 series might be easier to … [View More]

14 19

volunteers for 1.11.0 release manager?
by Charles R Harris Dec. 10, 2015

Dec. 10, 2015

Hi All, Thought I'd bring this up. I think the 1.11.0 release should be fairly easy as releases go, so if someone wants to get some practice with making releases this is probably a good one to start with. We should branch 1.11.x sometime before the end of January. It is almost in branchable condition as is, IMHO, but there are some things to take care of: the pile of PRs, `__numpy_ufunc__`, and maybe a few more deprecations that should be changed to errors. Chuck

1 0

Should dtypes have an ndim attribute?
by Gerrit Holl Dec. 10, 2015

Dec. 10, 2015

Hi, I have made a modest proposal in issue #6752 <https://github.com/numpy/numpy/issues/6752>. Basically, the proposal is to add an `ndim` attribute to dtypes. Currently, arrays have a shape and an ndim attribute, where ndim equals len(shape). dtype objects have a shape attribute, but no corresponding ndim. An ndim attribute would help in immediately determining whether a field in a structured dtype is multidimensional or not. Thoughts? Gerrit.

3 2

Re: [Numpy-discussion] Memory mapping and NPZ files
by Sebastian Berg Dec. 10, 2015

Dec. 10, 2015

On Mi, 2015-12-09 at 15:51 +0100, Mathieu Dubois wrote: > Dear all, > > If I am correct, using mmap_mode with Npz files has no effect i.e.: > f = np.load("data.npz", mmap_mode="r") > X = f['X'] > will load all the data in memory. > My take on it is, that no, I do not want implicit extraction/copy of the file. However, npz files are not necessarily compressed, and I expect that in the non-compressed version, memory-mapping is possible on the uncompressed version. If that … [View More]

2 1

Re: [Numpy-discussion] Memory mapping and NPZ files
by Sturla Molden Dec. 10, 2015

Dec. 10, 2015

Mathieu Dubois <mathieu.dubois(a)icm-institute.org> wrote: > Does it make sense? No. Memory mapping should just memory map, not do all sorts of crap. Sturla

2 1