On 11/11/2010 11:15 PM, Travis Oliphant wrote:
Thanks for starting the discussion, Charles.
Merging of the re-factor is a priority for me once I get back from
last 9 weeks of travel I have been on (I have been travelling for
business 7 of the last 9 weeks).
Ilan Schnell has already been look
On Fri, Nov 12, 2010 at 7:15 AM, Travis Oliphant wrote:
> At the same time, the work on the .NET framework has pushed us to move more
> of SciPy to a Cython-generated set. There are additional things I would
> like to see SciPy improve on as well, but I am not sure who is going to work
> on the
On Thu, Nov 11, 2010 at 3:15 PM, Travis Oliphant wrote:
> Thanks for starting the discussion, Charles.
>
> Merging of the re-factor is a priority for me once I get back from last 9
> weeks of travel I have been on (I have been travelling for business 7 of the
> last 9 weeks).
>
> Ilan Schnell has
On Thu, Nov 11, 2010 at 5:48 PM, Pauli Virtanen wrote:
> On Thu, 11 Nov 2010 16:37:53 -0600, Jason McCampbell wrote:
> [clip]
> > We will take a look at this and the script. There is also a feature in
> > git that allows two trees to be grafted together so the refactoring will
> > end up as a br
On Thu, 11 Nov 2010 16:37:53 -0600, Jason McCampbell wrote:
[clip]
> We will take a look at this and the script. There is also a feature in
> git that allows two trees to be grafted together so the refactoring will
> end up as a branch on the main repository with all edits.
Yes, this is pretty mu
On Thu, 11 Nov 2010 21:08:55 +, Pauli Virtanen wrote:
[clip]
> The first step I would like to see is to re-graft the teoliphant branch
> onto the current Git history -- currently, it's still based on Git-SVN.
> Re-grafting would make incremental merging and tracking easier. Luckily,
> this is e
Hi Chuck, Pauli,
This is indeed a good time to bring this up as we are in the process fixing
Python 3 issues and then merging changes from the master tree in preparation
for being able to consider merging the work. More specific comments inline
below.
Regards,
Jason
On Thu, Nov 11, 2010 at 3:3
Thanks for starting the discussion, Charles.
Merging of the re-factor is a priority for me once I get back from last 9 weeks
of travel I have been on (I have been travelling for business 7 of the last 9
weeks).
Ilan Schnell has already been looking at how to accomplish the merge (and I
have
On Thu, Nov 11, 2010 at 2:08 PM, Pauli Virtanen wrote:
> On Thu, 11 Nov 2010 12:38:53 -0700, Charles R Harris wrote:
> > I'd like to open a discussion about the steps to be followed in merging
> > the numpy refactor. I have two concerns about this. First, the refactor
> > repository branched off
On Thu, 11 Nov 2010 12:38:53 -0700, Charles R Harris wrote:
> I'd like to open a discussion about the steps to be followed in merging
> the numpy refactor. I have two concerns about this. First, the refactor
> repository branched off some time ago and I'm concerned about code
> divergence, not just
Hi,
On Thu, Nov 11, 2010 at 11:44 AM, Charles R Harris
wrote:
> On Thu, Nov 11, 2010 at 12:32 PM, Matthew Brett
>> Tiny patch for py3k attached.
>>
>> Should the generated numpy/version.py be in .gitignore? Is there a
>> better name in order to signal the generated nature of the file?
>>
>
> I
On Thu, Nov 11, 2010 at 12:32 PM, Matthew Brett wrote:
> Hi,
>
> On Tue, Nov 9, 2010 at 7:48 AM, Charles R Harris
> wrote:
> >
> >
> > On Tue, Nov 9, 2010 at 8:20 AM, Scott Sinclair gmail.com>
> > wrote:
> >>
> >> On 8 November 2010 23:17, Matthew Brett
> wrote:
> >> >> Since the change to git
Hi All,
I''d like to open a discussion about the steps to be followed in merging the
numpy refactor. I have two concerns about this. First, the refactor
repository branched off some time ago and I'm concerned about code
divergence, not just in the refactoring, but in fixes going into the master
br
On Nov 11, 2010, at 8:31 PM, Lluís wrote:
> Pierre GM writes:
>
>> In practice, that's exactly what happens below the hood when
>> genfromtxt tries to guess the output type of the converter. It tries a
>> single value ('1'), fails, and decides that the result must be an
>> object... Probably not
Hi,
On Tue, Nov 9, 2010 at 7:48 AM, Charles R Harris
wrote:
>
>
> On Tue, Nov 9, 2010 at 8:20 AM, Scott Sinclair
> wrote:
>>
>> On 8 November 2010 23:17, Matthew Brett wrote:
>> >> Since the change to git the numpy version in setup.py is '2.0.0.dev'
>> >> regardless because the prior numbering
Pierre GM writes:
> In practice, that's exactly what happens below the hood when
> genfromtxt tries to guess the output type of the converter. It tries a
> single value ('1'), fails, and decides that the result must be an
> object... Probably not the best strategy, as it crashes in your
> case. Bu
All,
Sorry for the delayed answer. I had a bit of time and examined the issue in
more details:
As you've seen, the output of your converter is not detected as a float, but as
an object. That's an unfortunate side effect of using a lambda function such as
yours: what if your input string has onl
On Thu, Nov 11, 2010 at 08:44, Michael Friedlander wrote:
> I'm a hopeful Matlab refugee trying to understand the numpy way.
> Perhaps someone can explain why some numpy functions require
> shape specifications in different ways. For example, below I create
> a random 2-by-3 array, and then a "o
I'm a hopeful Matlab refugee trying to understand the numpy way.
Perhaps someone can explain why some numpy functions require
shape specifications in different ways. For example, below I create
a random 2-by-3 array, and then a "ones" 2-by-3 array:
A = numpy.random.randn(2,3)
B = numpy.ones((2,3
On Tue, Nov 9, 2010 at 10:24 PM, Ralf Gommers
wrote:
> 2010/11/9 Sébastien Barthélemy :
>> On Sun, 7 Nov 2010, Ralf Gommers wrote:
>>> That will require renaming those files in the source tree from *.txt
>>> to *.rst, otherwise there's no way to have github render them
>>> properly. Unless I misse
This problem has nothing to do with numpy -- somehow, gcc binaries
themselves were overwritten by a process that installed just 32-bit
versions, ... so the problem is with the c compiler itself, and has been
resolved.
thanks!
Dan
On Thu, Nov 11, 2010 at 7:48 AM, Dan Yamins wrote:
>
>
>
>> Yes,
> Yes, it should. This was fixed a couple of days ago in
> commit:435c7262592e94c8519f (master) and commit:8346ba04a5c574441304
> (1.5.x). I guess you used an older revision, can you please update and
> try again?
>
Did this, but am having the same problem.This is the relevant output at
the be
Pauli Virtanen :
> On Thu, 11 Nov 2010 00:43:32 +0100, LittleBigBrain wrote:
>
>> I am wondering, is numpy.convolve based on LAPACK routine? Can it be
>> speedup by using ATLAS?
>>
>
> LAPACK and Atlas do not AFAIK have convolution routines -- that's not
> linear algebra. MKL on the other
On 11/11/2010 10:54 AM, Charles R Harris wrote:
> Hi All,
>
> Apparently the 64 bit version of memcpy in the Fedora 14 glibc will do
> the copy in the downwards rather than the usual upwards direction on
> some processors. This has exposed bugs where the the source and
> destination overlap in memo
24 matches
Mail list logo
