Mailman 3 April 2013 - NumPy-Discussion

timezones and datetime64
by Chris Barker - NOAA Federal 09 Apr '13

09 Apr '13

Hey folks, We've recently run into some issues with time zones and datetime64 (in numpy 1.7). Specifically, there no longer seems to be a way to have what the python datetime module calls "naive" datetime objects -- i.e. ones that have no awareness of timezones. Moreover, datetime64 seems to enforce the locale settings of the machine you're running on, with no way to turn that off. This is a "Bad Thing™". Time zones are a nightmare -- particularly a nightmare for computer code, and particularly with Daylight Savings issues. As a result, an application needs to either be fully-properly timezone aware, and manage it all properly, or be completely timezone naive -- mixing the two is a recipe for disaster! (OK, OK, I'm being a little histrionic here...) Getting timezone handling right is actually pretty tricky, and takes a fair bit of code, and is incompatible with some simple libraries. As a result, many of us punt and go with the naive approach. In particular a major app I'm working on has always made it the responsibility of the user to provide all input in the same timezone. If/when we do get smarter, we'll still treat timezone handling as an I/O issue -- internally, all datetimes with be in the same, naive, timezone. So I want it to be possible, and ideally easy, to use naive DateTime64s. One way to think about it is that the UTC time zone is equivalent to a naive object -- if you use UTC everywhere, no timezone conversions will take place, but with numpy1.7, this can be a trick. These issues come up in two core places: 1) Creating a DateTIme64 from the docs: "ISO 8601 specifies to use the local time zone if none is explicitly given" Well, yes and no -- ISO 8601 specifies that if no time zone is given, it means "local time". But it does not specify what local time means, nor how it should be used in a computer library. dateTime64 seems to define it as "use the computer's locale setting for the time zone" it also seems to not just keep the time zone around as meta-data, but actually change the internal representation to UTC. This is a really bad idea: - people have their time zones set wrong - or move their laptops around between time zones! - people, for example, run models for a location that is not their computer time zone - people run apps through the web -- who knows or should care what time zone the server is in? Note that this isn't just the string representation, but also conversion from a datetime.datetime object: In [28]: dt = datetime.datetime(2013, 4, 2, 12) In [29]: dt64 = np.datetime64(dt) In [30]: dt64 Out[30]: numpy.datetime64('2013-04-02T05:00:00.000000-0700') This is particularly problematic, as the built-in datetime module has no tzinfo objects -- you need a third-party library to supply them... 2) creating something else from a datetime64: In [47]: np.datetime64('2013-04-02T12:00:00-07').astype(datetime.datetime) Out[47]: datetime.datetime(2013, 4, 2, 19, 0) so I put in 12:00, but get back 19:00 -- and the datetime.datetime object has lost the timezone info. In [54]: str(np.datetime64('2013-04-02T12:00:00Z')) Out[54]: '2013-04-02T05:00:00-0700' I put in a UTC datetime, but get a string representation in my locale time -- this can get pretty ugly, particularly if you have to deal with DST. Using the locale also means that you have to do DST whether you want to or not, which can be weird: In [7]: np.arange('2013-03-10T07Z', '2013-03-10T12Z', dtype='datetime64[h]') Out[7]: array(['2013-03-09T23-0800', '2013-03-10T00-0800', '2013-03-10T01-0800', '2013-03-10T03-0700', '2013-03-10T04-0700'], dtype='datetime64[h]') so not all the elements in the the same TZ what happens when you want to go the reverse route -- very odd things with DST: In [15]: np.datetime64('2013-03-10T01:30') Out[15]: numpy.datetime64('2013-03-10T01:30-0800') In [16]: np.datetime64('2013-03-10T02:00') Out[16]: numpy.datetime64('2013-03-10T03:00-0700') # I put in 2:00, get back 3:00 ! In [17]: np.datetime64('2013-03-10T02:30') Out[17]: numpy.datetime64('2013-03-10T03:30-0700') # I put in 2:30, get back 3:30 ! In [18]: np.datetime64('2013-03-10T03:00') Out[18]: numpy.datetime64('2013-03-10T03:00-0700') # I put in 3:00, get back 3:00 ! To deal with all this, what we'll have to do is ensure that we are using UTC everywhere, and not ever use the built-in string representation. As you can see from the above, that's kind of a pain -- datetime.datetimes are often not timezone aware, people put whatever strings they put in, etc. My understanding is that datetime64 is still in experimental, and thus we have room to make some changes, so I propose: 1) allow a "naive" datetime64 -- one with no specified timezone. 2) have the default for ISO string interpretation be naive if no TZ is specified 3) never use the locale setting unless explicitly asked for. we'd need a way to specify timezone in string formatting, etc, not sure how do that. A couple questions: Are there docs defining the internals of timezone handling, and how one might change the timezone of an existing datetime64 array? As I poke at this a bit, I"m noticing that maybe time zones aren't handles at all internally -- rather, the conversion is done to UTC when creating a datetime64, and conversion is then done to the locale when creating a strng representation -- maybe nothing inside at all. Does the timezone info survive saving in npz, etc? PS: may have found a bug messing with arange and datetime64: In [56]: a = np.arange(np.datetime64('2013-04-02T12:00:00Z')) Bus error: 10 ( repeatable with 1.7.0, py2.7 OS-X 32 bit ) not good, even though that probably shouldn't be legal anyway. I'm guessing it's using the raw 64 bit integer and trying got build an array that big -- but it'd be better to get a ValueError. Thoughts? In particular, how does Pandas or any other time series package deal with all this? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker(a)noaa.gov

16 34

Re: [Numpy-discussion] Numpy discussion - was: Raveling, reshape order keyword unnecessarily confuses index and memory ordering
by Matthew Brett 09 Apr '13

09 Apr '13

Hi, On Sat, Apr 6, 2013 at 10:18 AM, matti picus <matti.picus(a)gmail.com> wrote: > as a lurker, may I say that this discussion seems to have become > non-productive? Well - the discussion is about two things - as so often the case on numpy. The first is about the particular change. The second is implicit, and keeps coming up, and that is about how change of any sort comes about in numpy. These questions keep coming up. Who decides on change? Is there a veto? Who has it? When do we vote, when do we negotiate? For example, one small part of the discussion was the lack of developers in numpy. For some, stopping these long discussions (somehow) will help recruit developers. The idea is that developers don't like these discussions, and, implicitly, that there is no problem, so the discussion is unnecessary. This is a version of the old 'no man, no problem' solution. For others, these long and unproductive discussions are pointing at a severe problem right at the heart of numpy development, which is that it is very hard to work in a system where it is unclear how decisions get made. See for example Mark Wiebe's complaint at the end here [1]. If this second lot of people are right then we have two options a) stop the discussions, numpy decays and dies from lack of direction b) continue the discussions and hope that it becomes clear that this is indeed a serious problem, and there develops some agreement to fix it. > It seems all agree that docs needs improvement, perhaps a first step would > be to suggest doc improvements, and then the need for renaming may become > self-evident, or not. I'm sure you're right - that doing the docs first would help, and thank you for the suggestion. Cheers, Matthew [1] https://github.com/numpy/numpy.org/blob/master/NA-overview.rst

6 6

Sources more confusing in Python
by Happyman 08 Apr '13

08 Apr '13

Hello, I started using python 4-5 months ago. At that time I didn't realize there are incredibly many resource like modules, additional programs (ready one) in python. The problem is to which one I can get all I want "properly". I mean where (exact place) I can download standard modules without going other links?? For example, Excel python module, Image processing module, something module..Every time I get modules from different links.. Is there exact place (stable) to get simply rather than picking/jumping from one to another site?? Any answer is appreciated

9 15

Sort performance with structured array
by Tom Aldcroft 08 Apr '13

08 Apr '13

I'm seeing about a factor of 50 difference in performance between sorting a random integer array versus sorting that same array viewed as a structured array. Am I doing anything wrong here? In [2]: x = np.random.randint(10000, size=10000) In [3]: xarr = x.view(dtype=[('a', np.int)]) In [4]: timeit np.sort(x) 1000 loops, best of 3: 588 us per loop In [5]: timeit np.sort(xarr) 10 loops, best of 3: 29 ms per loop In [6]: timeit np.sort(xarr, order=('a',)) 10 loops, best of 3: 28.9 ms per loop I was wondering if this slowdown is expected (maybe the comparison is dropping back to pure Python or ??). I'm showing a simple example here, but in reality I'm working with non-trivial structured arrays where I might want to sort on multiple columns. Does anyone have suggestions for speeding things up, or have a sort implementation (perhaps Cython) that has better performance for structured arrays? Thanks, Tom

2 2

Growing the contributor base of Numpy
by Jonathan Rocher 08 Apr '13

08 Apr '13

Dear all, One recurring question is how to *grow the contributor base* to NumPy and provide help and relief to core developers and maintainers. One way to do this would be to *leverage the upcoming SciPy conference* in 2 ways: 1. Provide an intermediate or advanced level tutorial on NumPy focusing on teaching the C-API and the architecture of the package to help people navigate the source code, and find answers to precise deep questions. I think that many users would be interested in being better able to understand the underlayers to become powerful users (and contributors if they want to). 2. Organize a Numpy sprint to leverage all this freshly graduated students apply what they learned to tackle some of the work under the guidance of core developers. This would be a great occasion to share and grow knowledge that is fundamental to our community. And the fact that the underlayers are in C is fine IMHO: SciPy is about scientific programming in Python and that is done with a lot of C. *Thoughts? Anyone interested in leading a tutorial (can be a team of people)? Anyone willing to coordinate the sprint? Who would be willing to be present and help during the sprint? * Note that there is less than 1 week left until the tutorial submission deadline. I am happy to help brainstorm on this to make it happen. Thanks, Jonathan and Andy, for the SciPy2013 organizers -- Jonathan Rocher, PhD Scientific software developer SciPy2013 conference co-chair Enthought, Inc. jrocher(a)enthought.com 1-512-536-1057 http://www.enthought.com

4 7

question about the data entry in the __array_interface__
by Valentin Haenel 08 Apr '13

08 Apr '13

Hi, I am currently working with a C extension that wraps a C library. The library contains a function that takes, amongst others, a 'void *' as an argument. Now, I would like for that function to be able to read the 'data' buffer of a numpy array and thus need to pass address from Python down into the C-extension. I know that the address is contained in the 'data' field of the '__array_interface__' and is either an int or a long. My guess is that this depends on the architecture of the system, i.e. 32 vs 64 bit systems. My question is: what is the correct type to use when using PyArg_ParseTuple to convert the value. I am currently using: k (integer) [unsigned long] Convert a Python integer or long integer to a C unsigned long without overflow checking. The reason I chose 'k' is because it seems to be the only option that can deal with both Python int and long types. And was wondering if this is the correct choice. Also note that whatever it is, it will be cast to a 'void *' later. Thanks in advance for advice. V- FYI: the gory details can be found in: https://github.com/FrancescAlted/python-blosc/pull/16

4 3

converting "numpy.bytes_" from numpy 1.7.0 to "numpy.string_" of numpy 1.6.1
by Sergio Rojas 07 Apr '13

07 Apr '13

Dear all, I am using a function which under python 2.2.7 and numpy 1.6.1 returns a "list" (called d) whose elements are of type "numpy.string_" (see below). Under python 3.3.0 and numpy 1.7.0 the same function returns the list as an object of type "builtins.list" whose elements are of type "numpy.bytes_". I am trying to find a way to have the function returns the same type of object in both versions of python. Acordingly I am wondering if there is a function which could convert the "numpy.bytes_" into "numpy.string_". The closes I have found is using "str(d[1]).lstrip('b')" (see below) but it wraps the contents of d[1] in double quotes. In python 2.7.2 In python 3.3.0 numpy 1.6.1 numpy 1.7.0 --------------- --------------- In [6]: type(d) In [5]: type(d) Out[6]: list Out[5]: builtins.list In [7]: d[1] In [6]: d[1] Out[7]: '05-Jan-00' Out[6]: b'05-Jan-00' In [8]: type(d[1]) In [7]: type(d[1]) Out[8]: numpy.string_ Out[7]: numpy.bytes_ In [9]: str(d[1]).lstrip('b') In [10]: str(d[1]).lstrip('b') Out[9]: '05-Jan-00' Out[10]: "'05-Jan-00'" In [10]: str(d[1]).lstrip('b')[0] In [11]: str(d[1]).lstrip('b')[0] Out[10]: '0' Out[11]: "'" I want to have extra double quotes I want to delete the double quotes enclosing the string stored in d[1] enclosing the string stored in d[1] Thanks in advance for your help, Sergio

2 1

ANN: SciPy 0.12.0 release
by Ralf Gommers 07 Apr '13

07 Apr '13

We are pleased to announce the availability of SciPy 0.12.0. This release has some cool new features (see highlights below) and a large amount of bug fixes and maintenance work under the hood. The number of contributors also keeps rising steadily - 75 people contributed patches to this release. We hope to see this trend continue. Some of the highlights of this release are: - Completed QHull wrappers in scipy.spatial. - cKDTree now a drop-in replacement for KDTree. - A new global optimizer, basinhopping. - Support for Python 2 and Python 3 from the same code base (no more 2to3). This release requires Python 2.6, 2.7 or 3.1-3.3 and NumPy 1.5.1 or greater. Support for Python 2.4 and 2.5 has been dropped as of this release. Sources and binaries can be found at http://sourceforge.net/projects/scipy/files/scipy/0.12.0/, release notes are copied below. Enjoy, The SciPy developers ========================== SciPy 0.12.0 Release Notes ========================== SciPy 0.12.0 is the culmination of 7 months of hard work. It contains many new features, numerous bug-fixes, improved test coverage and better documentation. There have been a number of deprecations and API changes in this release, which are documented below. All users are encouraged to upgrade to this release, as there are a large number of bug-fixes and optimizations. Moreover, our development attention will now shift to bug-fix releases on the 0.12.x branch, and on adding new features on the master branch. Some of the highlights of this release are: - Completed QHull wrappers in scipy.spatial. - cKDTree now a drop-in replacement for KDTree. - A new global optimizer, basinhopping. - Support for Python 2 and Python 3 from the same code base (no more 2to3). This release requires Python 2.6, 2.7 or 3.1-3.3 and NumPy 1.5.1 or greater. Support for Python 2.4 and 2.5 has been dropped as of this release. New features ============ ``scipy.spatial`` improvements ------------------------------ cKDTree feature-complete ^^^^^^^^^^^^^^^^^^^^^^^^ Cython version of KDTree, cKDTree, is now feature-complete. Most operations (construction, query, query_ball_point, query_pairs, count_neighbors and sparse_distance_matrix) are between 200 and 1000 times faster in cKDTree than in KDTree. With very minor caveats, cKDTree has exactly the same interface as KDTree, and can be used as a drop-in replacement. Voronoi diagrams and convex hulls ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `scipy.spatial` now contains functionality for computing Voronoi diagrams and convex hulls using the Qhull library. (Delaunay triangulation was available since Scipy 0.9.0.) Delaunay improvements ^^^^^^^^^^^^^^^^^^^^^ It's now possible to pass in custom Qhull options in Delaunay triangulation. Coplanar points are now also recorded, if present. Incremental construction of Delaunay triangulations is now also possible. Spectral estimators (``scipy.signal``) -------------------------------------- The functions ``scipy.signal.periodogram`` and ``scipy.signal.welch`` were added, providing DFT-based spectral estimators. ``scipy.optimize`` improvements ------------------------------- Callback functions in L-BFGS-B and TNC ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ A callback mechanism was added to L-BFGS-B and TNC minimization solvers. Basin hopping global optimization (``scipy.optimize.basinhopping``) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ A new global optimization algorithm. Basinhopping is designed to efficiently find the global minimum of a smooth function. ``scipy.special`` improvements ------------------------------ Revised complex error functions ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The computation of special functions related to the error function now uses a new `Faddeeva library from MIT <http://ab-initio.mit.edu/Faddeeva>`__ which increases their numerical precision. The scaled and imaginary error functions ``erfcx`` and ``erfi`` were also added, and the Dawson integral ``dawsn`` can now be evaluated for a complex argument. Faster orthogonal polynomials ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Evaluation of orthogonal polynomials (the ``eval_*`` routines) in now faster in ``scipy.special``, and their ``out=`` argument functions properly. ``scipy.sparse.linalg`` features -------------------------------- - In ``scipy.sparse.linalg.spsolve``, the ``b`` argument can now be either a vector or a matrix. - ``scipy.sparse.linalg.inv`` was added. This uses ``spsolve`` to compute a sparse matrix inverse. - ``scipy.sparse.linalg.expm`` was added. This computes the exponential of a sparse matrix using a similar algorithm to the existing dense array implementation in ``scipy.linalg.expm``. Listing Matlab(R) file contents in ``scipy.io`` ----------------------------------------------- A new function ``whosmat`` is available in ``scipy.io`` for inspecting contents of MAT files without reading them to memory. Documented BLAS and LAPACK low-level interfaces (``scipy.linalg``) ------------------------------------------------------------------ The modules `scipy.linalg.blas` and `scipy.linalg.lapack` can be used to access low-level BLAS and LAPACK functions. Polynomial interpolation improvements (``scipy.interpolate``) ------------------------------------------------------------- The barycentric, Krogh, piecewise and pchip polynomial interpolators in ``scipy.interpolate`` accept now an ``axis`` argument. Deprecated features =================== `scipy.lib.lapack` ------------------ The module `scipy.lib.lapack` is deprecated. You can use `scipy.linalg.lapack` instead. The module `scipy.lib.blas` was deprecated earlier in Scipy 0.10.0. `fblas` and `cblas` ------------------- Accessing the modules `scipy.linalg.fblas`, `cblas`, `flapack`, `clapack` is deprecated. Instead, use the modules `scipy.linalg.lapack` and `scipy.linalg.blas`. Backwards incompatible changes ============================== Removal of ``scipy.io.save_as_module`` -------------------------------------- The function ``scipy.io.save_as_module`` was deprecated in Scipy 0.11.0, and is now removed. Its private support modules ``scipy.io.dumbdbm_patched`` and ``scipy.io.dumb_shelve`` are also removed. Other changes ============= Authors ======= * Anton Akhmerov + * Alexander Eberspächer + * Anne Archibald * Jisk Attema + * K.-Michael Aye + * bemasc + * Sebastian Berg + * François Boulogne + * Matthew Brett * Lars Buitinck * Steven Byrnes + * Tim Cera + * Christian + * Keith Clawson + * David Cournapeau * Nathan Crock + * endolith * Bradley M. Froehle + * Matthew R Goodman * Christoph Gohlke * Ralf Gommers * Robert David Grant + * Yaroslav Halchenko * Charles Harris * Jonathan Helmus * Andreas Hilboll * Hugo + * Oleksandr Huziy * Jeroen Demeyer + * Johannes Schönberger + * Steven G. Johnson + * Chris Jordan-Squire * Jonathan Taylor + * Niklas Kroeger + * Jerome Kieffer + * kingson + * Josh Lawrence * Denis Laxalde * Alex Leach + * Tim Leslie * Richard Lindsley + * Lorenzo Luengo + * Stephen McQuay + * MinRK * Sturla Molden + * Eric Moore + * mszep + * Matt Newville + * Vlad Niculae * Travis Oliphant * David Parker + * Fabian Pedregosa * Josef Perktold * Zach Ploskey + * Alex Reinhart + * Gilles Rochefort + * Ciro Duran Santillli + * Jan Schlueter + * Jonathan Scholz + * Anthony Scopatz * Skipper Seabold * Fabrice Silva + * Scott Sinclair * Jacob Stevenson + * Sturla Molden + * Julian Taylor + * thorstenkranz + * John Travers + * True Price + * Nicky van Foreest * Jacob Vanderplas * Patrick Varilly * Daniel Velkov + * Pauli Virtanen * Stefan van der Walt * Warren Weckesser A total of 75 people contributed to this release. People with a "+" by their names contributed a patch for the first time.

1 0

ANN: NumPy 1.7.1rc1 release
by Ondřej Čertík 07 Apr '13

07 Apr '13

Hi, I'm pleased to announce the availability of the first release candidate of NumPy 1.7.1rc1. Sources and binary installers can be found at https://sourceforge.net/projects/numpy/files/NumPy/1.7.1rc1/ Please test it and report any bugs. It fixes a few bugs, listed below. I would like to thank everybody who contributed patches to this release: Nathaniel J. Smith, Sebastian Berg, Charles Harris, Bradley M. Froehle, Ralf Gommers, Christoph Gohlke, Mark Wiebe and Maximilian Albert. Cheers, Ondrej ========================= NumPy 1.7.1 Release Notes ========================= This is a bugfix only release in the 1.7.x series. Issues fixed ------------ gh-2973 Fix `1` is printed during numpy.test() gh-2983 BUG: gh-2969: Backport memory leak fix 80b3a34. gh-3007 Backport gh-3006 gh-2984 Backport fix complex polynomial fit gh-2982 BUG: Make nansum work with booleans. gh-2985 Backport large sort fixes gh-3039 Backport object take gh-3105 Backport nditer fix op axes initialization gh-3108 BUG: npy-pkg-config ini files were missing after Bento build. gh-3124 BUG: PyArray_LexSort allocates too much temporary memory. gh-3131 BUG: Exported f2py_size symbol prevents linking multiple f2py modules. gh-3117 Backport gh-2992 gh-3135 DOC: Add mention of PyArray_SetBaseObject stealing a reference gh-3134 DOC: Fix typo in fft docs (the indexing variable is 'm', not 'n'). gh-3136 Backport #3128 Checksums ========= 28c3f3e71b5eaa6bfab6e8340dbd35e7 release/installers/numpy-1.7.1rc1.tar.gz 436f416dee10d157314bd9da7ab95c9c release/installers/numpy-1.7.1rc1-win32-superpack-python2.7.exe a543c8cf69f66ff2b4c9565646105863 release/installers/numpy-1.7.1rc1-win32-superpack-python2.6.exe 6dfcbbd449b7fe4e841c5fd1bfa7af7c release/installers/numpy-1.7.1rc1-win32-superpack-python2.5.exe 22912792a1b6155ae2bdbc30bee8fadc release/installers/numpy-1.7.1rc1-win32-superpack-python3.2.exe 95bc5a5fcce9fcbc2717a774dccae31b release/installers/numpy-1.7.1rc1-win32-superpack-python3.3.exe 33cf283765a148846b49b89fb96d67d5 release/installers/numpy-1.7.1rc1-win32-superpack-python3.1.exe 9761de4b35493fed38c5d177da9c3b37 release/installers/numpy-1.7.1rc1.zip

4 5

mrecarray indexing behaviour
by Joel Nothman 07 Apr '13

07 Apr '13

Hello all! I am a bit confused by the behaviour of mrecarray: >>> import numpy.ma.mrecords >>> data = [(1, 'a'), (2, 'b')] >>> ra = numpy.rec.fromrecords(data) >>> mra = numpy.ma.mrecords.fromrecords(data) >>> ra rec.array([(1, 'a'), (2, 'b')], dtype=[('f0', '<i4'), ('f1', '|S1')]) >>> mra masked_records( f0 : [1 2] f1 : [a b] fill_value : (999999, 'N') ) >>> for a in [ra, mra]: ... for cname, cell in [('row first', a[0]['f1']), ('field first', a['f1'][0])]: ... print(type(a), cname, cell, type(cell), sep=', ') ... <class 'numpy.core.records.recarray'>, row first, a, <type 'numpy.string_'> <class 'numpy.core.records.recarray'>, field first, a, <type 'numpy.string_'> <class 'numpy.ma.mrecords.MaskedRecords'>, row first, a, <class 'numpy.ma.core.MaskedArray'> <class 'numpy.ma.mrecords.MaskedRecords'>, field first, a, <type 'numpy.string_'> Why when I index an mrecarray by offset before field do I get a zero-dimension MaskedArray instead of the object I get when indexing by field then offset? This seems strange behaviour. Is it documented? It doesn't seem to be tested; ma/tests/test_mrecords.py:79,87<https://github.com/numpy/numpy/blob/master/numpy/ma/tests/test_mrecords.py#…>asserts equality of value but says nothing about the types that should be returned. Similarly: >>> mra['f1'][0] == mra[0]['f1'] masked_array(data = True, mask = False, fill_value = True) >>> type(mra['f1'][0]) == type(mra[0]['f1']) False I look forward to any explanation or clarification! Thanks, - Joel

1 0