Hi,
scikits.learn.machine/manifold_learning.regression.neighbor contains a
kd-tree for neighbors search as well (implemented in C++).
Matthieu
2008/7/11 Charles R Harris [EMAIL PROTECTED]:
On Thu, Jul 10, 2008 at 5:48 PM, Andrew Dalke [EMAIL PROTECTED]
wrote:
snip
You can also grab the
2008/7/11 Robert Kern [EMAIL PROTECTED]:
On Thu, Jul 10, 2008 at 09:26, Alan McIntyre [EMAIL PROTECTED] wrote:
On Thu, Jul 10, 2008 at 10:06 AM, Christopher Hanley [EMAIL PROTECTED]
wrote:
From the svn log it looks like the tests are intended to fail? However
I would prefer tests that are
The problem is the Out[#] appended to the output.
Out[4]: poly1d([ 1., 2.,
3.])
**
File /usr/lib/python2.5/site-packages/numpy/lib/tests/test_polynomial.py,
line 6, in
On Fri, Jul 11, 2008 at 1:11 AM, Charles R Harris [EMAIL PROTECTED]
wrote:
The problem is the Out[#] appended to the output.
^^
prepended.
Chuck
___
Numpy-discussion mailing list
On Fri, Jul 11, 2008 at 02:06, Stéfan van der Walt [EMAIL PROTECTED] wrote:
2008/7/11 Robert Kern [EMAIL PROTECTED]:
On Thu, Jul 10, 2008 at 09:26, Alan McIntyre [EMAIL PROTECTED] wrote:
On Thu, Jul 10, 2008 at 10:06 AM, Christopher Hanley [EMAIL PROTECTED]
wrote:
From the svn log it looks
My Unit class is supposed to represent a neuron that can be linked to
any other unit. The neuron itself is merely a (float) potential that can
vary along time under the influence of other units and learning. I
gather these units into groups which are in fact 2D matrix of units.
Currently, I
On Fri, Jul 11, 2008 at 02:11, Charles R Harris
[EMAIL PROTECTED] wrote:
The problem is the Out[#] appended to the output.
Out[4]: poly1d([ 1., 2.,
3.])
**
File
On Thu, Jul 10, 2008 at 16:45, Nicolas Rougier [EMAIL PROTECTED] wrote:
Ideally, I would like to be able to write
z = N.array (a, dtype=Unit)
and would expect numpy to make a copy of the array by calling my type
with each element of a. Then, if my type accepts the argument during
creation,
On Fri, Jul 11, 2008 at 12:29 AM, Robert Kern [EMAIL PROTECTED] wrote:
Yes. This is well-known. IPython cannot run doctests in general
without modification. This is not a bug in numpy's tests; just an
incompatibility between IPython and doctest.
Couple of questions:
- how are these being
2008/7/11 Robert Kern [EMAIL PROTECTED]:
Branches may also be built using the buildbot.
What is the procedure for requesting this? Do we just email you and
ask for the buildbots to build a particular branch?
Go to the waterfall display and click on a build-slave name at the
top. Use Force
On Fri, Jul 11, 2008 at 1:29 AM, Robert Kern [EMAIL PROTECTED] wrote:
On Fri, Jul 11, 2008 at 02:11, Charles R Harris
[EMAIL PROTECTED] wrote:
The problem is the Out[#] appended to the output.
Out[4]: poly1d([ 1., 2.,
3.])
On Fri, Jul 11, 2008 at 02:37, Fernando Perez [EMAIL PROTECTED] wrote:
On Fri, Jul 11, 2008 at 12:29 AM, Robert Kern [EMAIL PROTECTED] wrote:
Yes. This is well-known. IPython cannot run doctests in general
without modification. This is not a bug in numpy's tests; just an
incompatibility
On Fri, Jul 11, 2008 at 02:39, Stéfan van der Walt [EMAIL PROTECTED] wrote:
2008/7/11 Robert Kern [EMAIL PROTECTED]:
Branches may also be built using the buildbot.
What is the procedure for requesting this? Do we just email you and
ask for the buildbots to build a particular branch?
Go to
On Fri, Jul 11, 2008 at 02:50, Robert Kern [EMAIL PROTECTED] wrote:
I don't see this problem with the
trunk of numpy (and IPython, incidentally):
Also, nose 0.10.3, which may be part of the solution.
--
Robert Kern
I have come to believe that the whole world is an enigma, a harmless
enigma
On Fri, Jul 11, 2008 at 1:40 AM, Robert Kern [EMAIL PROTECTED] wrote:
On Fri, Jul 11, 2008 at 02:37, Fernando Perez [EMAIL PROTECTED]
wrote:
On Fri, Jul 11, 2008 at 12:29 AM, Robert Kern [EMAIL PROTECTED]
wrote:
Yes. This is well-known. IPython cannot run doctests in general
without
On Fri, Jul 11, 2008 at 1:52 AM, Robert Kern [EMAIL PROTECTED] wrote:
On Fri, Jul 11, 2008 at 02:50, Robert Kern [EMAIL PROTECTED] wrote:
I don't see this problem with the
trunk of numpy (and IPython, incidentally):
Also, nose 0.10.3, which may be part of the solution.
Maybe. Upgrading
Hi,
We are planning to implement some date/time types for NumPy, and I'm
sending a document that explains our approach. We would love to hear
the feedback of the NumPy community in order to cover their needs as
much as possible.
Cheers,
Francesc
On Fri, Jul 11, 2008 at 12:58 AM, Charles R Harris
[EMAIL PROTECTED] wrote:
The problem might be the old ipython version (8.1) shipped with ubuntu 8.04.
Debian is slow to update and I've been trying out ubuntu for 64 bit testing.
Debian Lenny is at ipython 0.8.4.
Francesc,
We are planning to implement some date/time types for NumPy, and I'm
sending a document that explains our approach. We would love to hear
the feedback of the NumPy community in order to cover their needs as
much as possible.
That sounds like an excellent idea. Matt Knox and I
2008/7/11 Pierre GM [EMAIL PROTECTED]:
A final note on time scales
---
Wow, indeed. In environmental sciences (my side) and in finances (Matt's), we
very rarely have a need for that precision, thankfully...
We do, sometimes, in pulsar astronomy. But I think it's
On Friday 11 July 2008 12:28:30 Anne Archibald wrote:
A date/time class that tries to do everything is quickly going to become
unfeasibly complicated.
I quite agree, and I think that's why Francesc and Ivan are considering
different classes for different problems: one targetting series at a
A Friday 11 July 2008, Pierre GM escrigué:
Francesc,
We are planning to implement some date/time types for NumPy, and
I'm sending a document that explains our approach. We would love
to hear the feedback of the NumPy community in order to cover their
needs as much as possible.
That
A Friday 11 July 2008, Pierre GM escrigué:
On Friday 11 July 2008 12:28:30 Anne Archibald wrote:
A date/time class that tries to do everything is quickly going to
become unfeasibly complicated.
I quite agree, and I think that's why Francesc and Ivan are
considering different classes for
On Fri, Jul 11, 2008 at 12:47 PM, Francesc Alted [EMAIL PROTECTED]
wrote:
A Friday 11 July 2008, Pierre GM escrigué:
Our approach for dealing with dates was to translate them into
integers through a particular class (Date).
That's very interesting. We will have a look at your
Nicolas Rougier wrote:
My Unit class is supposed to represent a neuron that can be linked to
any other unit. The neuron itself is merely a (float) potential that can
vary along time under the influence of other units and learning.
gather these units into groups which are in fact 2D matrix of
If your positions are static (I'm not clear on that from your message), then
you might want to check the technique of slice searching. It only requires
one sort of the data for each dimension initially, then uses a simple, but
clever look up to find neighbors within some epsilon of a chosen
A Friday 11 July 2008, Christopher Barker escrigué:
Francesc Alted wrote:
We are planning to implement some date/time types for NumPy,
+1
A couple questions/comments:
``datetime64``
- Expressed in microseconds since POSIX epoch (January 1, 1970).
- Resolution: nanoseconds.
how
Hello,
Nice idea - please can you make it work with matplotlib's time/date
stuff too?
Thanks,
Jon
Francesc Alted wrote:
...
===
A proposal for implementing some date/time types in NumPy
A Friday 11 July 2008, Jon Wright escrigué:
Hello,
Nice idea - please can you make it work with matplotlib's time/date
stuff too?
Hmmm, following the matplotlib docstrings:
datetime objects are converted to floating point numbers
which represent the number of days since 0001-01-01 UTC
So
On Friday 11 July 2008 14:01:39 Francesc Alted wrote:
Ah! Very smart! I wonder if we could use this to implement a special
array with a fixed timestep that could be indexed by time instead than
by index. Something like:
t1 = datetime.datetime(1,2,3)
t2 = datetime.datetime(3,4,5)
Well,
A Friday 11 July 2008, Francesc Alted escrigué:
A Friday 11 July 2008, Jon Wright escrigué:
Hello,
Nice idea - please can you make it work with matplotlib's time/date
stuff too?
Hmmm, following the matplotlib docstrings:
datetime objects are converted to floating point numbers
On Fri, Jul 11, 2008 at 12:37 PM, Francesc Alted [EMAIL PROTECTED]
wrote:
A Friday 11 July 2008, Francesc Alted escrigué:
A Friday 11 July 2008, Jon Wright escrigué:
Hello,
Nice idea - please can you make it work with matplotlib's time/date
stuff too?
Hmmm, following the
A Friday 11 July 2008, Pierre GM escrigué:
On Friday 11 July 2008 14:01:39 Francesc Alted wrote:
Ah! Very smart! I wonder if we could use this to implement a
special array with a fixed timestep that could be indexed by time
instead than by index. Something like:
t1 =
Pierre GM wrote:
but you can use integers/dates/strings as indices and get your
result.
cool! I like that.
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
On Friday 11 July 2008 14:58:33 Francesc Alted wrote:
Well, we coded something like that in our TimeSeries class: its
__getitem__ is quite bloated, but you can use integers/dates/strings
as indices and get your result. We implemented in Python, so that's
slow, but it works great.
That's
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 time/date
Hmmm, following the matplotlib
2008/7/11 Jon Wright [EMAIL PROTECTED]:
Timezones are a heck of a problem if you want to be accurate. You are
talking about nanosecond resolutions, however, atomic clocks in orbit
apparently suffer from relativistic corrections of the order 38000
nanoseconds per day [1]. What will you do
PyArray_DescrFromType can return NULL
static PyArray_Descr *
PyArray_DescrFromType(int type)
{
PyArray_Descr *ret = NULL;
if (type PyArray_NTYPES) {
ret = _builtin_descrs[type];
}
else if (type == PyArray_NOTYPE) {
/*
* This needs to not raise an error
38 matches
Mail list logo
