On Sun, Jul 13, 2008 at 6: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
__
+1 to remove them
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 been changed from
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 would a
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 matplotlib's
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
A Saturday 12 July 2008, Matt Knox escrigué:
Christopher Barker Chris.Barker at 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 would
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
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 simplicity.
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
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, 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
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
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 numpy
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
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
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])
a.hour
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
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
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.
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 using
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 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 having the
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 see what it's
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
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 or
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 backport
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
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
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 and
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 116 of my
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 but it
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 and it
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 (the
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? (
37 matches
Mail list logo
