On Tue, Aug 25, 2015 at 12:21 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Tue, 25 Aug 2015 03:03:41 -0700 Nathaniel Smith <njs@pobox.com> wrote:
Supporting third-party dtypes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[...]
Some features that would become straightforward to implement (e.g. even in third-party libraries) if this were fixed: - missing value support - physical unit tracking (meters / seconds -> array of velocity; meters + seconds -> error) - better and more diverse datetime representations (e.g. datetimes with attached timezones, or using funky geophysical or astronomical calendars) - categorical data - variable length strings - strings-with-encodings (e.g. latin1) - forward mode automatic differentiation (write a function that computes f(x) where x is an array of float64; pass that function an array with a special dtype and get out both f(x) and f'(x)) - probably others I'm forgetting right now
It should also be the opportunity to streamline datetime64 and timedelta64 dtypes. Currently the unit information is IIRC hidden in some weird metadata thing called the PyArray_DatetimeMetaData.
Yeah, and PyArray_DatetimeMetaData is an "NpyAuxData", which is its own personal little object system implemented in C with its own reference counting system... the design of dtypes has great bones, but the current implementation has a lot of, um, historical baggage. -n -- Nathaniel J. Smith -- http://vorpus.org