On 6/7/11 4:53 PM, Pierre GM wrote:
> Anyhow, each time yo
> read 'frequency' in scikits.timeseries, think 'unit'.
or maybe "precision" -- when I think if unit, I think of something that
can be represented as a floating point value -- but here, with integers,
it's the precision that can be repr
On Wed, Jun 8, 2011 at 1:52 PM, Fernando Perez wrote:
> On Tue, Jun 7, 2011 at 4:35 PM, Mark Wiebe wrote:
>> I went ahead and did the merge today as I said I wanted to, that pull
>> request is some further development for someone to code-review if they have
>> time.
>
> I'm curious as to why ther
On Tue, Jun 7, 2011 at 4:35 PM, Mark Wiebe wrote:
> I went ahead and did the merge today as I said I wanted to, that pull
> request is some further development for someone to code-review if they have
> time.
I'm curious as to why there was a need to push ahead with the merge
right away, without g
On Tue, Jun 7, 2011 at 5:53 PM, Angus McMorland wrote:
> Thanks Mark. That fixed it for i686, but on x86_64 I get the
> following. Still looks datetime related.
Same failure here...
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mai
On 7 June 2011 17:57, Mark Wiebe wrote:
> Hi Angus,
> Thanks for reporting that, I've committed a fix so it builds in the
> monolithic mode again.
Thanks Mark. That fixed it for i686, but on x86_64 I get the
following. Still looks datetime related.
compile options: '-Ibuild/src.linux-x86_64-2.6/
>
> It supports .astype(), with a truncation policy. This is motivated partially
> because that's how Pythons integer division works, and partially because if
> you consider a full datetime '2011-03-14T13:22:16', it's natural to think of
> the year as '2011', the date as '2011-03-14', etc, whic
On Tue, Jun 7, 2011 at 6:53 PM, Pierre GM wrote:
>
> On Jun 8, 2011, at 1:16 AM, Mark Wiebe wrote:
>
> > Hi Dave,
> >
> > Thanks for all the feedback on the datetime, it's very useful to help
> understand the timeseries ideas, in particular with the many examples you're
> sprinkling in.
> >
> > O
On Jun 8, 2011, at 1:16 AM, Mark Wiebe wrote:
> Hi Dave,
>
> Thanks for all the feedback on the datetime, it's very useful to help
> understand the timeseries ideas, in particular with the many examples you're
> sprinkling in.
>
> One overall impression I have about timeseries in general is t
On Tue, Jun 7, 2011 at 6:27 PM, Fernando Perez wrote:
> Hi Mark,
>
> On Tue, Jun 7, 2011 at 10:09 AM, Mark Wiebe wrote:
> > I'd like to merge the changes I've done to datetime so far into NumPy
> master
> > today. It's a fairly big chunk of changes, with the following highlights:
>
> Is it this
On Tue, Jun 7, 2011 at 4:47 PM, Dave Hirschfeld
wrote:
> Mark Wiebe gmail.com> writes:
>
> >
> > >>> a = np.datetime64('today')
> >
> > >>> a - a.astype('M8[Y]')
> >
> > numpy.timedelta64(157,'D')
> >
> > vs
> >
> >
> > >>> a = np.datetime64('today')
> > >>> a - a.astype('M8[Y]')
> > Traceback (m
Hi Mark,
On Tue, Jun 7, 2011 at 10:09 AM, Mark Wiebe wrote:
> I'd like to merge the changes I've done to datetime so far into NumPy master
> today. It's a fairly big chunk of changes, with the following highlights:
Is it this pull request: https://github.com/numpy/numpy/pull/85 or is
there more
On Tue, Jun 7, 2011 at 3:56 PM, Pierre GM wrote:
>
> On Jun 7, 2011, at 5:54 PM, Robert Kern wrote:
>
> > On Tue, Jun 7, 2011 at 07:34, Dave Hirschfeld
> wrote:
> >
> >> I'm not convinced about the events concept - it seems to add complexity
> >> for something which could be accomplished better
Hi Dave,
Thanks for all the feedback on the datetime, it's very useful to help
understand the timeseries ideas, in particular with the many examples you're
sprinkling in.
One overall impression I have about timeseries in general is the use of the
term "frequency" synonymously with the time unit.
Hi Angus,
Thanks for reporting that, I've committed a fix so it builds in the
monolithic mode again.
-Mark
On Tue, Jun 7, 2011 at 4:23 PM, Angus McMorland wrote:
> Hi all,
>
> I'm experiencing a build failure from current numpy git, which seems
> to be datetime related. Here's the error messag
Mark Wiebe gmail.com> writes:
>
> >>> a = np.datetime64('today')
>
> >>> a - a.astype('M8[Y]')
>
> numpy.timedelta64(157,'D')
>
> vs
>
>
> >>> a = np.datetime64('today')
> >>> a - a.astype('M8[Y]')
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: ufunc subtract can
Hi all,
I'm experiencing a build failure from current numpy git, which seems
to be datetime related. Here's the error message.
creating build/temp.linux-i686-2.6/numpy/core/src/multiarray
compile options: '-Inumpy/core/include
-Ibuild/src.linux-i686-2.6/numpy/core/include/numpy
-Inumpy/core/src/p
Christopher Barker noaa.gov> writes:
>
> Dave Hirschfeld wrote:
> > That would be one way of dealing with irregularly spaced data. I would argue
> > that the example is somewhat back-to-front though. If something happens
> > twice a month it's not occuring at a monthly frequency, but at a higher
On Jun 7, 2011, at 5:54 PM, Robert Kern wrote:
> On Tue, Jun 7, 2011 at 07:34, Dave Hirschfeld
> wrote:
>
>> I'm not convinced about the events concept - it seems to add complexity
>> for something which could be accomplished better in other ways. A [Y]//4
>> dtype is better specified as [3M]
The NEP for datetime specifies a set of rules for how units should behave
when combined with + or -. After playing around with the implementation a
bit, I think the rules need to be changed. First, subtracting two
datetime64's should produce the more precise unit. This allows things like
the follow
What is the rule to determine the dtype returned by numpy functions
that return indices such as np.argmax?
I assumed that np.argmax() returned the same dtype as np.int_. That
works on linux32/64 and win32 but on win-amd64 np.int_ is int32 and
np.argmax() returns int64.
Someone suggested using int
Dave Hirschfeld wrote:
> Robert Kern gmail.com> writes:
>> Well, [D/100] doesn't represent [864s]. It represents something that
>> happens 100 times a day, but not necessarily at precise regular
>> intervals.
>> For example, suppose that I am representing payments that
>> happen twice a month, s
On Tue, Jun 7, 2011 at 8:59 PM, Mark Wiebe wrote:
> On Tue, Jun 7, 2011 at 1:41 PM, Ralf Gommers
> wrote:
>
>> On Mon, Jun 6, 2011 at 6:56 PM, Mark Wiebe wrote:
>>
>>> On Mon, Jun 6, 2011 at 10:30 AM, Mark Wiebe wrote:
>>>
On Sun, Jun 5, 2011 at 3:43 PM, Ralf Gommers <
ralf.gomm...@g
On Tue, Jun 7, 2011 at 1:41 PM, Ralf Gommers wrote:
> On Mon, Jun 6, 2011 at 6:56 PM, Mark Wiebe wrote:
>
>> On Mon, Jun 6, 2011 at 10:30 AM, Mark Wiebe wrote:
>>
>>> On Sun, Jun 5, 2011 at 3:43 PM, Ralf Gommers <
>>> ralf.gomm...@googlemail.com> wrote:
>>>
On Thu, Jun 2, 2011 at 10:12 PM,
On Tue, Jun 7, 2011 at 13:53, Charles R Harris
wrote:
> Because the C standard allows char to be either signed or unsigned and this
> affects sort order I believe we should pick one or the other for sorting.
> Thoughts?
Unsigned for (at least notional) compatibility with the unicode dtype.
--
R
Because the C standard allows char to be either signed or unsigned and this
affects sort order I believe we should pick one or the other for sorting.
Thoughts?
Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailm
On Mon, Jun 6, 2011 at 6:56 PM, Mark Wiebe wrote:
> On Mon, Jun 6, 2011 at 10:30 AM, Mark Wiebe wrote:
>
>> On Sun, Jun 5, 2011 at 3:43 PM, Ralf Gommers > > wrote:
>>
>>> On Thu, Jun 2, 2011 at 10:12 PM, Mark Wiebe wrote:
>>>
On Thu, Jun 2, 2011 at 3:09 PM, Gael Varoquaux <
gael.varoq
Robert Kern gmail.com> writes:
>
> On Tue, Jun 7, 2011 at 07:34, Dave Hirschfeld gmail.com>
wrote:
>
> > I'm not convinced about the events concept - it seems to add complexity
> > for something which could be accomplished better in other ways. A [Y]//4
> > dtype is better specified as [3M] dt
I'd like to merge the changes I've done to datetime so far into NumPy master
today. It's a fairly big chunk of changes, with the following highlights:
* Abstract the ufunc type resolution into a replaceable function, for
datetime's type rules
* Remove the TimeInteger scalar type, make timedelta64
Pierre GM wrote:
> Using the ISO as reference, you have a good definition of months.
Yes, but only one. there are others. For instance, the climate modelers
like to use a calendar that has 360 days a year: 12 30 day months. That
way they get something with the same timescale as months and years,
On Tue, Jun 7, 2011 at 9:54 AM, Robert Kern wrote:
> On Tue, Jun 7, 2011 at 07:34, Dave Hirschfeld
> wrote:
>
> > I'm not convinced about the events concept - it seems to add complexity
> > for something which could be accomplished better in other ways. A [Y]//4
> > dtype is better specified as
On Tue, Jun 7, 2011 at 07:34, Dave Hirschfeld wrote:
> I'm not convinced about the events concept - it seems to add complexity
> for something which could be accomplished better in other ways. A [Y]//4
> dtype is better specified as [3M] dtype, a [D]//100 is an [864S]. There
> may well be a good
We are looking for help to predict tomorrow's stock returns.
The challenge is model selection in the presence of noisy data. The
tools are ubuntu, python, cython, c, numpy, scipy, la, bottleneck,
git.
A quantitative background and experience or interest in model
selection, machine learning, and s
On Tue, Jun 7, 2011 at 2:29 AM, Mark Dickinson wrote:
> On Mon, Jun 6, 2011 at 11:12 PM, Mark Wiebe wrote:
>
>
> > On the other hand,
> > with POSIX time, anybody that wants things precise with respect to
> > leap-seconds is automatically excluded. The potential surprises from
> > leap-seconds
As a user of numpy/scipy in finance I thought I would put in my 2p worth as
it's something which is of great importance in this area.
I'm currently a heavy user of the scikits.timeseries package by Matt & Pierre
and I'm also following the development of statsmodels and pandas should we
require m
On Mon, Jun 6, 2011 at 11:12 PM, Mark Wiebe wrote:
> On Mon, Jun 6, 2011 at 3:47 PM, Mark Dickinson
>> On Mon, Jun 6, 2011 at 9:24 PM, Mark Wiebe wrote:
>> > and an ambiguity-resolution in the few cases that need it,
>>
>> Where does the ambiguity come from? (Assuming we're not more than 6
>> m
35 matches
Mail list logo
