On 6/2/11 12:57 PM, Robert Kern wrote:
>>> Anyhow, years and months are simple enough.
>>
>> no, they are not -- they are fundamentally different than hours, days, etc.
>
> That doesn't make them *difficult*.
I won't comment on how difficult it is -- I'm not writing the code. My
core point is tha
Bumping my question tentatively. I am fairly sure there is a good answer and
for some reason it got overlooked.
Regards
srean
-- Forwarded message --
From: srean
Date: Fri, May 27, 2011 at 10:36 AM
Subject: Adding the arrays in an array iterator
To: Discussion of Numerical Pyth
On Wed, Jun 1, 2011 at 22:06, Travis Oliphant wrote:
>
> On May 31, 2011, at 8:08 PM, Charles R Harris wrote:
>> 2) Ufunc fadd (nanadd?) Treats nan as zero in addition. Should make a faster
>> version of nansum possible.
>
> +0 --- Some discussion at the data array summit led to the view that
On Thu, Jun 2, 2011 at 3:09 PM, Gael Varoquaux <
gael.varoqu...@normalesup.org> wrote:
> On Thu, Jun 02, 2011 at 03:06:58PM -0500, Mark Wiebe wrote:
> >Would anyone object to, at least temporarily, tightening up the
> default
> >ufunc casting rule to 'same_kind' in NumPy master? It's a one
On Thu, Jun 02, 2011 at 03:06:58PM -0500, Mark Wiebe wrote:
>Would anyone object to, at least temporarily, tightening up the default
>ufunc casting rule to 'same_kind' in NumPy master? It's a one line change,
>so would be easy to undo, but such a change is very desirable in my
>opin
Would anyone object to, at least temporarily, tightening up the default
ufunc casting rule to 'same_kind' in NumPy master? It's a one line change,
so would be easy to undo, but such a change is very desirable in my opinion.
This would raise an exception, since it's np.add(a, 1.9, out=a), convertin
On Thu, Jun 2, 2011 at 13:44, Christopher Barker wrote:
> Pierre GM wrote:
>> Anyhow, years and months are simple enough.
>
> no, they are not -- they are fundamentally different than hours, days, etc.
That doesn't make them *difficult*. It's tricky to convert between
months and hours, yes, but
Mark Wiebe wrote:
> It is possible to implement the system so that if you don't use Y/M/B,
> things work out unambiguously, but if you do use them you get a behavior
> that's a little weird, but with rules to eliminate the calendar-created
> ambiguities.
yes, but everyone wants different rule
On Thu, Jun 2, 2011 at 14:07, Ralf Gommers wrote:
>
> On Wed, Jun 1, 2011 at 5:45 PM, martin smith wrote:
>>
>> I have a bit of code that performs multi-taper power spectra using numpy
>> and a C extension module. The C portion consists of an interface file
>> and a python-unaware computational
On Wed, Jun 1, 2011 at 5:45 PM, martin smith wrote:
> I have a bit of code that performs multi-taper power spectra using numpy
> and a C extension module. The C portion consists of an interface file
> and a python-unaware computational file. The latter invokes fftpack.
>
> The straightforward s
On Thu, Jun 2, 2011 at 12:44 PM, Christopher Barker
wrote:
> Pierre GM wrote:
> >> I also don't think that units like "month", "year", "business day"
> >> should be allowed -- it just adds confusion. It's not a killer if they
> >> are defined in the spec:
> >
> > -1 In scikits.timeseries, not only
On Thu, Jun 2, 2011 at 1:09 PM, Pierre GM wrote:
>
>
> > """
> > A representation is also supported such that the stored date-time
> > integer can encode both the number of a particular unit as well as a
> > number of sequential events tracked for each unit.
> > """
> >
> > I'm not sure I unde
Pierre GM wrote:
>> I also don't think that units like "month", "year", "business day"
>> should be allowed -- it just adds confusion. It's not a killer if they
>> are defined in the spec:
>
> -1 In scikits.timeseries, not only did we have years,months and
> business days, but we also had weeks,
Benjamin Root wrote:
> Just throwing it out there. Back in my Perl days (I do not often admit
> this), the one module that I thought was really well done was the
> datetime module. Now, I am not saying that we would need to support the
> calendar from Lord of the Rings or anything like that, b
thanks. My solution was much hackier.
-Mathew
On Thu, Jun 2, 2011 at 10:27 AM, Olivier Delalleau wrote:
> I think this does what you want:
>
> def seq_split(x):
> r = [0] + list(numpy.where(x[1:] != x[:-1] + 1)[0] + 1) + [None]
> return [x[r[i]:r[i + 1]] for i in xrange(len(r) - 1)]
>
> -=-
On Jun 2, 2011, at 6:57 PM, Christopher Barker wrote:
> Mark Wiebe wrote:
>> I'm following what I understand the NEP to mean for combining dates and
>> deltas of different units. This means for timedeltas, the metadata
>> becomes more precise, in particular it becomes the GCD of the input
>> m
On Thu, Jun 2, 2011 at 10:57 AM, Christopher Barker
wrote:
> Mark Wiebe wrote:
> > I'm following what I understand the NEP to mean for combining dates and
> > deltas of different units. This means for timedeltas, the metadata
> > becomes more precise, in particular it becomes the GCD of the input
On Thu, Jun 2, 2011 at 12:17 PM, Benjamin Root wrote:
>
>
Just throwing it out there. Back in my Perl days (I do not often admit
> this), the one module that I thought was really well done was the datetime
> module. Now, I am not saying that we would need to support the calendar
> from Lord of
On Thu, Jun 2, 2011 at 1:11 PM, Robert Kern wrote:
> On Thu, Jun 2, 2011 at 12:08, Skipper Seabold wrote:
>> On Wed, Jun 1, 2011 at 10:10 PM, Alan G Isaac wrote:
On Thu, Jun 2, 2011 at 1:49 AM, Mark Miller
wrote:
> Not quite. Bincount is fine if you have a set of approximately
>>
I think this does what you want:
def seq_split(x):
r = [0] + list(numpy.where(x[1:] != x[:-1] + 1)[0] + 1) + [None]
return [x[r[i]:r[i + 1]] for i in xrange(len(r) - 1)]
-=- Olivier
2011/6/2 Mathew Yeates
> Hi
> I have indices into an array I'd like split so they are sequential
> e.g.
> [1
On Thu, Jun 2, 2011 at 11:42 AM, Mark Wiebe wrote:
> On Thu, Jun 2, 2011 at 11:22 AM, Christopher Barker > wrote:
>
>> Charles R Harris wrote:
>> > Good support for units and delta times is very useful, but
>> > parsing dates and times and handling timezones, daylight savings, leap
>> > seconds
On Thu, Jun 2, 2011 at 11:57 AM, Christopher Barker
wrote:
> Mark Wiebe wrote:
> > I'm following what I understand the NEP to mean for combining dates and
> > deltas of different units. This means for timedeltas, the metadata
> > becomes more precise, in particular it becomes the GCD of the input
On Thu, Jun 2, 2011 at 12:08, Skipper Seabold wrote:
> On Wed, Jun 1, 2011 at 10:10 PM, Alan G Isaac wrote:
>>> On Thu, Jun 2, 2011 at 1:49 AM, Mark Miller
>>> wrote:
Not quite. Bincount is fine if you have a set of approximately
sequential numbers. But if you don't
>>
>>
>> On 6/
Hi
I have indices into an array I'd like split so they are sequential
e.g.
[1,2,3,10,11] -> [1,2,3],[10,11]
How do I do this?
-Mathew
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Wed, Jun 1, 2011 at 10:10 PM, Alan G Isaac wrote:
>> On Thu, Jun 2, 2011 at 1:49 AM, Mark Miller
>> wrote:
>>> Not quite. Bincount is fine if you have a set of approximately
>>> sequential numbers. But if you don't
>
>
> On 6/1/2011 9:35 PM, David Cournapeau wrote:
>> Even worse, it fails
Mark Wiebe wrote:
> I'm following what I understand the NEP to mean for combining dates and
> deltas of different units. This means for timedeltas, the metadata
> becomes more precise, in particular it becomes the GCD of the input
> metadata, and between timedelta and datetime the datetime alway
On Thu, Jun 2, 2011 at 11:22 AM, Christopher Barker
wrote:
> Charles R Harris wrote:
> > Good support for units and delta times is very useful, but
> > parsing dates and times and handling timezones, daylight savings, leap
> > seconds, business days, etc., is probably best served by addon package
On Thu, Jun 2, 2011 at 11:22, Christopher Barker wrote:
> Charles R Harris wrote:
>> * Leap seconds probably deserve a rigorous treatment, but having an
>> internal representation with leap-seconds overcomplicates otherwise very
>> simple and fast operations.
>
> could you explain more? I don't g
On Thu, Jun 2, 2011 at 10:36 AM, Pierre GM wrote:
>
> On Jun 1, 2011, at 11:16 PM, Mark Wiebe wrote:
>
> > On Wed, Jun 1, 2011 at 3:52 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
> >
> >
> > Just a quick comment, as this really needs more thought, but time is a
> bag of worms.
> >
Charles R Harris wrote:
> Good support for units and delta times is very useful, but
> parsing dates and times and handling timezones, daylight savings, leap
> seconds, business days, etc., is probably best served by addon packages
> specialized to an area of interest. Just my $.02
I agree here
Peter Butterworth wrote:
> in np.histogram the top-most bin edge is inclusive of the upper range
> limit. As documented in the docstring (see below) this is actually the
> expected behavior, but this can lead to some weird enough results:
>
> In [72]: x=[1, 2, 3, 4]; np.histogram(x, bins=3)
> Out[
On Jun 1, 2011, at 11:16 PM, Mark Wiebe wrote:
> On Wed, Jun 1, 2011 at 3:52 PM, Charles R Harris
> wrote:
>
>
> Just a quick comment, as this really needs more thought, but time is a bag of
> worms.
>
> Certainly a bag of worms, I agree.
Oh yes... Keep in mind that the inclusion of time i
On Thu, Jun 2, 2011 at 10:16 AM, Mark Wiebe wrote:
> On Thu, Jun 2, 2011 at 7:25 AM, Marc Shivers wrote:
>>
>> Regarding business days, for financial data, trading days are
>> determined by each exchange, so, in particular, there is no such thing
>> as a US Trading Calendar, only a NYSE Calendar,
On Thu, Jun 2, 2011 at 7:25 AM, Marc Shivers wrote:
> Regarding business days, for financial data, trading days are
> determined by each exchange, so, in particular, there is no such thing
> as a US Trading Calendar, only a NYSE Calendar, NYMEX Calendar, etc,
> etc... . I think it would be usefu
Regarding business days, for financial data, trading days are
determined by each exchange, so, in particular, there is no such thing
as a US Trading Calendar, only a NYSE Calendar, NYMEX Calendar, etc,
etc... . I think it would be useful to have functionality where you
could start with a weekday c
On Thu, Jun 2, 2011 at 5:42 PM, wrote:
> On Wed, Jun 1, 2011 at 9:35 PM, David Cournapeau wrote:
>> On Thu, Jun 2, 2011 at 1:49 AM, Mark Miller
>> wrote:
>>> Not quite. Bincount is fine if you have a set of approximately
>>> sequential numbers. But if you don't
>>
>> Even worse, it fails m
in np.histogram the top-most bin edge is inclusive of the upper range
limit. As documented in the docstring (see below) this is actually the
expected behavior, but this can lead to some weird enough results:
In [72]: x=[1, 2, 3, 4]; np.histogram(x, bins=3)
Out[72]: (array([1, 1, 2]), array([ 1.,
On Wed, Jun 1, 2011 at 9:35 PM, David Cournapeau wrote:
> On Thu, Jun 2, 2011 at 1:49 AM, Mark Miller wrote:
>> Not quite. Bincount is fine if you have a set of approximately
>> sequential numbers. But if you don't
>
> Even worse, it fails miserably if you sequential numbers but with a high
38 matches
Mail list logo
