A Tuesday 15 July 2008, Pierre GM escrigué:
On Tuesday 15 July 2008 07:30:09 Francesc Alted wrote:
Maybe is only that. But by using the term 'frequency' I tend to
think that you are expecting to have one entry (observation) in
your array for each time 'tick' since time start. OTOH, the
A Tuesday 15 July 2008, Anne Archibald escrigué:
2008/7/15 Francesc Alted [EMAIL PROTECTED]:
Maybe is only that. But by using the term 'frequency' I tend to
think that you are expecting to have one entry (observation) in
your array for each time 'tick' since time start. OTOH, the term
A Monday 14 July 2008, Pierre GM escrigué:
On Monday 14 July 2008 14:17:18 Francesc Alted wrote:
Well, what we are after is precisely this: a new dtype type. After
integrating it in NumPy, I suppose that your DateArray would be
similar than a NumPy array with a dtype ``datetime64`` (bar
On Tuesday 15 July 2008 07:30:09 Francesc Alted wrote:
Maybe is only that. But by using the term 'frequency' I tend to think
that you are expecting to have one entry (observation) in your array
for each time 'tick' since time start. OTOH, the term 'resolution'
doesn't have this implication,
2008/7/15 Francesc Alted [EMAIL PROTECTED]:
Maybe is only that. But by using the term 'frequency' I tend to think
that you are expecting to have one entry (observation) in your array
for each time 'tick' since time start. OTOH, the term 'resolution'
doesn't have this implication, and only
Hi,
Before giving more thought to the new proposal of the date/time types
for NumPy based in the concept of 'resolution', I'd like to gather more
feedback on your opinions about this.
After pondering about the opinions about the first proposal, the idea we
are incubating is to complement the
On Monday 14 July 2008 09:07:47 Francesc Alted wrote:
The advantage of this abstraction is that the user can easily choose the
scale of resolution that better fits his need. I'm thinking in
providing the next resolutions:
[femtosec, picosec, nanosec, microsec, millisec, sec, min,
hour,
On Mon, 14 Jul 2008, Francesc Alted apparently wrote:
Before giving more thought to the new proposal of the
date/time types for NumPy based in the concept of
'resolution', I'd like to gather more feedback on your
opinions about this.
It might be a good idea to run the proposal(s) past
2008/7/14 Francesc Alted [EMAIL PROTECTED]:
After pondering about the opinions about the first proposal, the idea we
are incubating is to complement the ``datetime64`` with a 'resolution'
metainfo. The ``datetime64`` will still be based on a int64 type, but
the meaning of the 'ticks' would
A Monday 14 July 2008, Alan G Isaac escrigué:
On Mon, 14 Jul 2008, Francesc Alted apparently wrote:
Before giving more thought to the new proposal of the
date/time types for NumPy based in the concept of
'resolution', I'd like to gather more feedback on your
opinions about this.
It
A Monday 14 July 2008, Pierre GM escrigué:
On Monday 14 July 2008 12:50:21 Francesc Alted wrote:
A very useful point that Matt Knox had coded is the possibility
to specify starting points for switching from one resolution to
another. For example, you can have a series with a 'ANN_MAR'
On Monday 14 July 2008 14:17:18 Francesc Alted wrote:
Well, what we are after is precisely this: a new dtype type. After
integrating it in NumPy, I suppose that your DateArray would be similar
than a NumPy array with a dtype ``datetime64`` (bar the conceptual
differences between your
12 matches
Mail list logo
