A Thursday 31 July 2008, Matt Knox escrigué:
While on the topic of FAME... being a financial analyst, I really am
quite fond of the multitude of quarterly frequencies we have in the
timeseries package (with different year end points) because they are
very useful when doing things like
A Thursday 31 July 2008, Alan G Isaac escrigué:
A Thursday 31 July 2008, Matt Knox escrigué:
While on the topic of FAME... being a financial analyst, I really
am quite fond of the multitude of quarterly frequencies we have in
the timeseries package (with different year end points) because
Pierre GM (el 2008-07-29 a les 15:47:52 -0400) va dir::
On Tuesday 29 July 2008 15:14:13 Ivan Vilata i Balaguer wrote:
Pierre GM (el 2008-07-29 a les 12:38:19 -0400) va dir::
Relative time versus relative time
--
This case would be the same than
On Wednesday 30 July 2008 06:35:32 Francesc Alted wrote:
A Wednesday 30 July 2008, Ivan Vilata i Balaguer escrigué:
Pierre GM (el 2008-07-29 a les 15:47:52 -0400) va dir::
On Tuesday 29 July 2008 15:14:13 Ivan Vilata i Balaguer wrote:
Pierre GM (el 2008-07-29 a les 12:38:19 -0400) va
A Wednesday 30 July 2008, Pierre GM escrigué:
On Wednesday 30 July 2008 06:35:32 Francesc Alted wrote:
A Wednesday 30 July 2008, Ivan Vilata i Balaguer escrigué:
Pierre GM (el 2008-07-29 a les 15:47:52 -0400) va dir::
On Tuesday 29 July 2008 15:14:13 Ivan Vilata i Balaguer wrote:
On Wed, Jul 30, 2008 at 12:35 PM, Francesc Alted [EMAIL PROTECTED]wrote:
A Wednesday 30 July 2008, Pierre GM escrigué:
In my mind, .tounit(*args) should be available for both relative
(timedeltas) and absolute (datetime) times.
Well, what we are proposing is that the conversion time unit
A Wednesday 30 July 2008, Pierre GM escrigué:
Now, what format do you consider for this reference ?
Whatever that can be converted into a datetime64 scalar. Some
examples:
ref = '2001-04-01'
ref = datetime.datetime(2001, 4, 1)
Er, should I see ref as having a 'day' unit or
On Wednesday 30 July 2008 13:16:25 Francesc Alted wrote:
A Wednesday 30 July 2008, Pierre GM escrigué:
It's just that I have trouble understanding the
meaning of something like
t2 = numpy.ones(5, dtype=datetime64[s])
That's five times one second after the epoch, right ? But in what
When people are refering to busienss days are you talking about
weekdays or are you saying weekday non-holidays?
On 7/30/08, Francesc Alted [EMAIL PROTECTED] wrote:
A Wednesday 30 July 2008, Pierre GM escrigué:
Now, what format do you consider for this reference ?
Whatever that can be
A Wednesday 30 July 2008, Pierre GM escrigué:
Which brings me to another question:
datetime64 and timedelta64 are just dtypes, therefore they don't
impose any restriction (in terms of uniqueness of elements, ordering
of the elements...) on the underlying ndarray, right ?
That's right.
A Wednesday 30 July 2008, Tom Denniston escrigué:
When people are refering to busienss days are you talking about
weekdays or are you saying weekday non-holidays?
Plain weekdays. Taking in account holidays for all the world round
would be certainly much more complex than timezones, which
If it's really just weekdays why not call it that instead of using a
term like business days that (quite confusingly) suggests holidays are
handled properly?
Also, I view the timezone and holiday issues as totally seperate. I
would definately NOT recommend basing holidays on a timezone because
A Wednesday 30 July 2008, Tom Denniston escrigué:
If it's really just weekdays why not call it that instead of using a
term like business days that (quite confusingly) suggests holidays
are handled properly?
Well, we were adopting the name from the TimeSeries package. Perhaps
the authors can
Yes this all makes a lot of sense. I would propose changing the name
from business days to weekdays though. Does anyone object wih that?
On 7/30/08, Ivan Vilata i Balaguer [EMAIL PROTECTED] wrote:
Tom Denniston (el 2008-07-30 a les 13:12:45 -0500) va dir::
If it's really just weekdays why
If it's really just weekdays why not call it that instead of using a
term like business days that (quite confusingly) suggests holidays
are handled properly?
Well, we were adopting the name from the TimeSeries package. Perhaps
the authors can answer this better than me.
A lot of the
Hi,
During the making of the date/time proposals and the subsequent
discussions in this list, we have changed a couple of times our point
of view about the way how the castings would work between different
date/time types and the different time units (previously called
resolutions). So I'd
Ops, after reviewing this document, I've discovered a couple of typos.
A Tuesday 29 July 2008, Francesc Alted escrigué:
[snip]
series = numpy.array(['1970-01-01', '1970-02-01', '1970-09-01'],
dtype='datetime64[D]')
series2 = series + numpy.timedelta(1, 'Y') # Add 2 years
Hi,
Silent casting is often a source of bugs and I appreciate the strict rules
you want to enforce.
However, I think there should be a simpler mechanism for operations between
different types
than creating a copy of a variable with the correct type.
My suggestion is to have a dtype argument for
Francesc,
Absolute time versus relative time
--
We think that in this case the absolute time should have priority for
determining the time unit of the outcome.
+1
Absolute time versus absolute time
--
When operating
Francesc,
The datetime proposal is very impressive in its depth and thought.
For me as well as many other people this would be a massive
improvement to numpy and allow numpy to get a foothold in areas like
econometrics where R/S is now dominant.
I had one question regarding casting of strings:
A Tuesday 29 July 2008, David Huard escrigué:
Hi,
Silent casting is often a source of bugs and I appreciate the strict
rules you want to enforce.
However, I think there should be a simpler mechanism for operations
between different types
than creating a copy of a variable with the correct
On Tuesday 29 July 2008 14:08:28 Francesc Alted wrote:
A Tuesday 29 July 2008, David Huard escrigué:
Hmm, the idea of the ``.add()`` and ``.subtract()`` methods is tempting,
but I not sure it is a good idea to add new methods to the ndarray
object that are meant to be used with just the
David Huard (el 2008-07-29 a les 12:31:54 -0400) va dir::
Silent casting is often a source of bugs and I appreciate the strict
rules you want to enforce. However, I think there should be a simpler
mechanism for operations between different types than creating a copy
of a variable with the
A Tuesday 29 July 2008, Tom Denniston escrigué:
Francesc,
The datetime proposal is very impressive in its depth and thought.
For me as well as many other people this would be a massive
improvement to numpy and allow numpy to get a foothold in areas like
econometrics where R/S is now
Tom Denniston (el 2008-07-29 a les 12:21:39 -0500) va dir::
[...]
I think it would be ideal if things like the following worked:
series = numpy.array(['1970-02-01','1970-09-01'], dtype = 'datetime64[D]')
series == '1970-02-01'
[True, False]
I view this as similar to:
series =
Pierre GM (el 2008-07-29 a les 12:38:19 -0400) va dir::
Relative time versus relative time
--
This case would be the same than the previous one (absolute vs
absolute). Our proposal is to forbid this operation if the time units
of the operands are
On Tuesday 29 July 2008 15:14:13 Ivan Vilata i Balaguer wrote:
Pierre GM (el 2008-07-29 a les 12:38:19 -0400) va dir::
Relative time versus relative time
--
This case would be the same than the previous one (absolute vs
absolute). Our proposal is to
27 matches
Mail list logo
