On Mon, Jul 14, 2008 at 10:50 PM, Gael Varoquaux <
[EMAIL PROTECTED]> wrote:
> On Sun, Jul 13, 2008 at 01:49:18AM -0700, Jarrod Millman wrote:
> > The NumPy 1.1.1 release date (7/31/08) is rapidly approaching and we
> > need everyone's help. Chuck Harris has volunteered to take the lead
> > on co
On Sun, Jul 13, 2008 at 01:49:18AM -0700, Jarrod Millman wrote:
> The NumPy 1.1.1 release date (7/31/08) is rapidly approaching and we
> need everyone's help. Chuck Harris has volunteered to take the lead
> on coordinating this release.
Anybody has an idea what the status is on #844? (
http://sci
On Mon, Jul 14, 2008 at 8:21 PM, Pierre GM <[EMAIL PROTECTED]> wrote:
> I did as much as I could to ensure compatibility with Python 2.3, but I can't
> test it myself (can't install Python 2.3 on my machine). It'd be great if
> somebody could check it works with that version, otherwise I'm all go (
On Mon, Jul 14, 2008 at 7:58 PM, Fernando Perez <[EMAIL PROTECTED]> wrote:
> It's actually coming from doctest. Hardcode
>
> import doctest
> doctest.master = None
>
> in the code that runs the tests. This resets a module-global that's
> the cause of that message.
Thanks, Fernando, I added that
On Monday 14 July 2008 22:27:25 Robert Kern wrote:
> I have a slightly newer version of the book. The majority of this text
> appears verbatim under the description of dtype.names, so I assume
> dtype.fields[-1] got removed in favor of dtype.names. As well it
> should.
OK then, I should be set. T
On Mon, Jul 14, 2008 at 21:15, Pierre GM <[EMAIL PROTECTED]> wrote:
> On Monday 14 July 2008 21:56:47 Robert Kern wrote:
>> > Oh, with dtype.names and dtype.fields I can work. The Guide mentions a
>> > key [-1] in dtype.fields that should store the names in order: that would
>> > be quite useful bu
On Monday 14 July 2008 21:56:47 Robert Kern wrote:
> > Oh, with dtype.names and dtype.fields I can work. The Guide mentions a
> > key [-1] in dtype.fields that should store the names in order: that would
> > be quite useful but it doesn't work (KeyError).
>
> Where do you see this mention?
Page 11
On Mon, Jul 14, 2008 at 19:41, Pierre GM <[EMAIL PROTECTED]> wrote:
> On Monday 14 July 2008 19:39:39 Robert Kern wrote:
>> Right. If you want order, use dtype.descr, or sort on the last item in
>> the tuple. We can probably reimplement the dictproxy to guarantee
>> order.
>
> Oh, with dtype.names
On Monday 14 July 2008 19:39:39 Robert Kern wrote:
> Right. If you want order, use dtype.descr, or sort on the last item in
> the tuple. We can probably reimplement the dictproxy to guarantee
> order.
Oh, with dtype.names and dtype.fields I can work. The Guide mentions a key
[-1] in dtype.fields
> Pierre, I know you have been working diligently to get masked arrays up to
> speed and have made numerous fixes in the 1.1.x branch. All the tests pass
> for me. Is there more that needs to be done?
Charles,
I did as much as I could to ensure compatibility with Python 2.3, but I can't
test it m
On Mon, Jul 14, 2008 at 19:05, Charles R Harris
<[EMAIL PROTECTED]> wrote:
> All,
>
> The rc release of numpy-1.1.1 is due out next Sunday. I have gone through
> the commits made to the trunk since the 1.1.x branch to pull out backport
> candidates. If you find your name here could you make the bac
On Mon, Jul 14, 2008 at 5:05 PM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
> The rc release of numpy-1.1.1 is due out next Sunday. I have gone through
> the commits made to the trunk since the 1.1.x branch to pull out backport
> candidates. If you find your name here could you make the backport o
All,
The rc release of numpy-1.1.1 is due out next Sunday. I have gone through
the commits made to the trunk since the 1.1.x branch to pull out backport
candidates. If you find your name here could you make the backport or say
why you think it inappropriate.
David, I know that these are mostly bu
On Sun, Jul 13, 2008 at 10:59 PM, Alan McIntyre <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 14, 2008 at 1:31 AM, Charles R Harris
> <[EMAIL PROTECTED]> wrote:
>> Any idea what this is:
>>
>> *** DocTestRunner.merge: '__main__' in both testers; summing outcomes.
>
> Hmm..that's coming from nose. I'll
On Mon, Jul 14, 2008 at 18:24, Pierre GM <[EMAIL PROTECTED]> wrote:
> On Monday 14 July 2008 18:53:41 Robert Kern wrote:
>> dtype.fields is a dict-like object containing the same information,
>> but accessible by field name.
>
> But as it's a dictionary, I can't use iteritems() without risking havi
On Monday 14 July 2008 18:53:41 Robert Kern wrote:
> dtype.fields is a dict-like object containing the same information,
> but accessible by field name.
But as it's a dictionary, I can't use iteritems() without risking having the
wrong order of fields, right ? Or do dictproxies behave differently
On Mon, Jul 14, 2008 at 17:06, Pierre GM <[EMAIL PROTECTED]> wrote:
> All,
> Anybody could point me to some docs on dtypes ? Michael Droettboom's recent
> question made me realize that things were far more complex than I thought.
> For example, how can I find the shape and type of a field (without
All,
Anybody could point me to some docs on dtypes ? Michael Droettboom's recent
question made me realize that things were far more complex than I thought.
For example, how can I find the shape and type of a field (without using
dtype.descr).
Thanks a lot in advance
P.
__
The NumPy 1.1.1 release date (7/31/08) is rapidly approaching and we
need everyone's help. Chuck Harris has volunteered to take the lead
on coordinating this release.
As a reminder here is the schedule for 1.1.1:
- 7/20/08 tag the 1.1.1rc1 release and prepare packages
- 7/27/08 tag the
On Monday 14 July 2008 15:12:18 Francesc Alted wrote:
> I see. However, the more I think about this, the more I see the need to
> split the date/time functionalities and duties in two parts:
>
> * the first one implementing a date/time dtype with the basic
> functionality for timestamping and/or t
A Monday 14 July 2008, Christopher Barker escrigué:
> Matt Knox wrote:
> > The DateArray class in the timeseries scikits can do part of what
> > you want. Observe...
> >
> a.year
> >
> > array([2008, 2008, 2008, 2008, 2008, 2008, 2008, 2008, 2008, 2008,
> > 2008, 2008, 2008, 2008, 2008])
> >
>
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 'freq
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 'AN
On Monday 14 July 2008 13:53:09 Michael Droettboom wrote:
> I'm running into a couple of small problems with mrecarray. I'm not
> sure if they're bugs or a usage error.
Bugs are my bet. I'll check that.
The first one might be problematic, as it probable comes from ma.core.
The second one is most
I'm running into a couple of small problems with mrecarray. I'm not
sure if they're bugs or a usage error.
First, the constructor throws an exception when the format string
contains nested arrays (if that is the proper term) such as "(2,2)f8".
This creates a three-element tuple in the dtype.
Matt Knox wrote:
> The DateArray class in the timeseries scikits can do part of what you want.
> Observe...
a.year
> array([2008, 2008, 2008, 2008, 2008, 2008, 2008, 2008, 2008, 2008, 2008,
>2008, 2008, 2008, 2008])
a.hour
> array([11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22,
On Mon, Jul 14, 2008 at 12:22, John Hunter <[EMAIL PROTECTED]> wrote:
> I have a rather unconventional install pipeline at work and owner only
> read permissions on a number of the tests are causing me minor
> problems. It appears the permissions on the tests are set rather
> inconsistently in num
I have a rather unconventional install pipeline at work and owner only
read permissions on a number of the tests are causing me minor
problems. It appears the permissions on the tests are set rather
inconsistently in numpy and python -- is there any reason not to make
these all 644?
[EMAIL PROTEC
A Monday 14 July 2008, Anne Archibald escrigué:
> 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 bas
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' frequency, that
> > corresponds to 1 point a
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.
>
A Monday 14 July 2008, Pierre GM escrigué:
> 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"
The NumPy 1.1.1 release date (7/31/08) is rapidly approaching and we
need everyone's help. Chuck Harris has volunteered to take the lead
on coordinating this release.
As a reminder here is the schedule for 1.1.1:
- 7/20/08 tag the 1.1.1rc1 release and prepare packages
- 7/27/08 tag the
A Monday 14 July 2008, David Huard escrigué:
> 2008/7/14 Francesc Alted <[EMAIL PROTECTED]>:
> > [...]
> >
> > > DateArray([14-Jan-2001 14:34:33, 16-Jan-2001 10:09:11],
> > > freq='S')
> >
> > That's great. However we only planned to import/export dates from
> > the ``datetime`` module f
> data = loadtxt('18B180.dat', skiprows = 1, usecols = xrange(1,46))
On Sat, Jul 12, 2008 at 04:35:20PM +0200, Lorenzo Bolla wrote:
> why not using:
or data = loadtxt('18B180.dat', skiprows=1, unpack=True)[1:]
>
> obviously, you need to know how many columns you have.
Or not, if you don't mind th
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' wo
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
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",
2008/7/14 Francesc Alted <[EMAIL PROTECTED]>:
> [...]
> > DateArray([14-Jan-2001 14:34:33, 16-Jan-2001 10:09:11],
> > freq='S')
>
> That's great. However we only planned to import/export dates from the
> ``datetime`` module for the time being, mainly because of efficency but
> also simp
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 Sun, Jul 13, 2008 at 8:26 PM, Alan McIntyre <[EMAIL PROTECTED]> wrote:
> Does anybody know whether there's any reason to keep the following
> functions? They don't appear to be used anywhere.
>
> linalg/linalg.py:95 _castCopyAndTranspose
> lib/function_base.py:659 _asarray1d
_castCopyAndTransp
A Saturday 12 July 2008, Matt Knox escrigué:
> Christopher Barker noaa.gov> writes:
> >> I'm also imaging some extra utility functions/method that would be
> >> nice:
> >>
> >> aDateTimeArray.hours(dtype=float)
> >>
> >> to convert to hours (and days, and seconds, etc). And maybe some
> >> that wo
Le lundi 23 juin 2008 à 14:10 +0200, Fabrice Silva a écrit :
> > I don't have ideas what is causing this import error. Try
> > the instructions above, may be it is due to some compile object
> > conflicts.
> The only posts on mailing lists I've read mention security policies
> (SElinux) and /tmp e
A Saturday 12 July 2008, Jon Wright escrigué:
> Charles R Harris wrote:
> > On Fri, Jul 11, 2008 at 12:37 PM, Francesc Alted
> >
> > A Friday 11 July 2008, Francesc Alted escrigué:
> > > A Friday 11 July 2008, Jon Wright escrigué:
> > > > Nice idea - please can you make it work with m
A Friday 11 July 2008, Christopher Barker escrigué:
> print example
> >
> > [Jul-2008 Aug-2008 Sep-2008 Oct-2008 Nov-2008 Dec-2008]
>
> I like this -- seeing the integers for the times makes me wonder what
> that point is -- we've all been using numbers for time for years
> already -- what wou
On Mon, Jul 14, 2008 at 7:50 AM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
`>
>
> On Tue, Jul 8, 2008 at 6:21 PM, Sebastian Haase <[EMAIL PROTECTED]> wrote:
>>
>> Hi,
>> I haven't checked out a recent numpy (( >>> N.__version__
>> '1.0.3.1'))
>> But could someone please check if the division has
46 matches
Mail list logo
