The last two Travis builds of master have failed consistently with the
same error:
http://travis-ci.org/#!/numpy/numpy/builds
It looks like a real failure -- we're getting the same error on every
build variant, some sort of problem in test_pareto. Example:
http://travis-ci.org/#!/numpy/numpy/jo
On Tue, Sep 4, 2012 at 1:47 PM, Scott Sinclair
wrote:
> On 4 September 2012 12:23, Matthew Brett wrote:
>> On Tue, Sep 4, 2012 at 11:15 AM, Nathaniel Smith wrote:
>>> The last two Travis builds of master have failed consistently with the
>>> same error:
>>>
On Tue, Sep 4, 2012 at 9:17 PM, Ondřej Čertík wrote:
> On Tue, Sep 4, 2012 at 12:41 PM, Ondřej Čertík
> wrote:
>> On Tue, Sep 4, 2012 at 12:31 PM, Ondřej Čertík
>> wrote:
>>> On Tue, Sep 4, 2012 at 3:15 AM, Nathaniel Smith wrote:
>>>> The last
On Wed, Sep 5, 2012 at 6:36 PM, Frédéric Bastien wrote:
> Hi,
>
> I spent up to now 2 or 3 days making change to Theano to support numpy
> 1.7b1. But now, I just find an interface change that will need
> recoding a function, not just small code change.
My understanding was that 1.7 is not suppose
On Wed, Sep 5, 2012 at 10:02 PM, Yaroslav Halchenko
wrote:
> quick question -- either this is a desired effect that ndarray.base is no
> longer chains to point to all parent arrays? following code produces
> different outputs with 1.6.3 and 1.7.0b1:
>
> $> python -c 'import numpy as np; print np._
On Thu, Sep 6, 2012 at 1:41 AM, Sebastian Berg
wrote:
> Hey,
>
> No idea if this is simply not support or just a bug, though I am
> guessing that such usage simply is not planned.
I think that's right... currently numpy simply makes no guarantees
about what order ufunc loops will be performed in,
On 7 Sep 2012 14:38, "Benjamin Root" wrote:
>
> An issue just reported on the matplotlib-users list involved a user who
ran out of memory while attempting to do an imshow() on a large array.
While this wouldn't be totally unexpected, the user's traceback shows that
they ran out of memory before an
On Wed, Sep 12, 2012 at 2:46 PM, Matthew Brett wrote:
> Hi,
>
> I just noticed that this works for numpy 1.6.1:
>
> In [36]: np.concatenate(([2, 3], [1]), 1)
> Out[36]: array([2, 3, 1])
>
> but the beta release branch:
>
> In [3]: np.concatenate(([2, 3], [1]), 1)
>
On Thu, Sep 13, 2012 at 11:12 AM, Matthew Brett wrote:
> Hi,
>
> While writing some tests for np.concatenate, I ran foul of this code:
>
> if (axis >= NPY_MAXDIMS) {
> ret = PyArray_ConcatenateFlattenedArrays(narrays, arrays, NPY_CORDER);
> }
> else {
> ret = PyArray_Co
On 18 Sep 2012 18:40, "Benjamin Root" wrote:
>
>
>
> On Fri, Sep 7, 2012 at 12:05 PM, Nathaniel Smith wrote:
>>
>> On 7 Sep 2012 14:38, "Benjamin Root" wrote:
>> >
>> > An issue just reported on the matplotlib-users list involved
On Thu, Sep 20, 2012 at 3:33 PM, Ondřej Čertík wrote:
> On Thu, Sep 20, 2012 at 4:50 AM, Richard Hattersley
> wrote:
>> Hi,
>>
>> [First of all - thanks to everyone involved in the 1.7 release. Especially
>> Ondřej - it takes a lot of time & energy to coordinate something like this.]
>>
>> Is the
On Mon, Sep 17, 2012 at 10:22 AM, Matthew Brett wrote:
> Hi,
>
> On Sun, Sep 9, 2012 at 6:12 PM, Frédéric Bastien wrote:
>> The third is releated to change to the casting rules in numpy. Before
>> a scalar complex128 * vector float32 gived a vector of dtype
>> complex128. Now it give a vector of
On Wed, Sep 19, 2012 at 1:08 AM, Charles R Harris
wrote:
>
>
> The relevant setting is in numpy/core/include/numpy/ndarraytypes.h
>
> #define NPY_DEFAULT_ASSIGN_CASTING NPY_SAME_KIND_CASTING
>
> I think that if we want to raise a warning we could define a new rule,
>
> NPY_WARN_SAME_KIND_CASTING
On Thu, Sep 20, 2012 at 10:56 PM, Orion Poplawski wrote:
> This is a plea for some help. We've been having trouble getting scipy to
> pass all of the tests in the Fedora 18 build with python 3.3 (although it
> seems to build okay in Fedora 19). Below are the logs of the build. There
> appears t
On 21 Sep 2012 17:31, "Chris Barker" wrote:
>
> On Thu, Sep 20, 2012 at 2:48 PM, Nathaniel Smith wrote:
> > because a += b
> > really should be the same as a = a + b.
>
> I don't think that's the case - the inplace operator should be (and
> are) mor
On Fri, Sep 21, 2012 at 9:42 PM, Ralf Gommers wrote:
> Eh, just installing numpy with "python setup.py install" uses plain
> distutils, not setuptools. So there indeed isn't an entry in
> easy-install.pth. Which some consider a feature:)
I don't think this is correct. To be clear on the technica
On Fri, Sep 21, 2012 at 10:04 PM, Chris Barker wrote:
> On Fri, Sep 21, 2012 at 10:03 AM, Nathaniel Smith wrote:
>
>> You're right of course. What I meant is that
>> a += b
>> should produce the same result as
>> a[...] = a + b
>>
>> If we ch
On Sat, Sep 22, 2012 at 10:24 PM, Sebastian Berg
wrote:
> In case you are interested, the second (real odditiy), is caused by
> ISFORTRAN and IS_F_CONTIGUOUS mixup, I have found three occurances where
> I think ISFORTRAN should be replaced by the latter. Check also:
>
> https://github.com/seberg/n
On Sat, Sep 22, 2012 at 4:46 PM, Olivier Grisel
wrote:
> There is also a third use case that is problematic on numpy master:
>
> orig = np.memmap('tmp.mmap', dtype=np.float64, shape=100, mode='w+')
> orig[:] = np.arange(orig.shape[0]) * -1.0 # negative markers to
> detect under / overflows
>
> a
On Sun, Sep 23, 2012 at 7:55 PM, Olivier Grisel
wrote:
> 2012/9/23 Olivier Grisel :
>>
>> The only clean solution for the collapsed base of numpy 1.7 I see
>> would be to replace the direct mmap.mmap buffer instance from the
>> numpy.memmap class to use a custom wrapper of mmap.mmap that would
>>
On Sat, Sep 22, 2012 at 1:18 PM, Ralf Gommers wrote:
> On Fri, Sep 21, 2012 at 11:39 PM, Nathaniel Smith wrote:
>> So the question is, how do we get a .egg-info? For the specific case
>> Ralf ran into, I'm pretty sure the solution is just that if you're
>> clever
On Mon, Sep 24, 2012 at 7:19 PM, Gael Varoquaux
wrote:
> Hi Fred,
>
> On Mon, Sep 24, 2012 at 02:17:16PM -0400, Frédéric Bastien wrote:
>> with numpy '1.6.1', I have no problem.
>
>> With numpy 1.7.0b2, I can reproduce the problem.
>
> OK, thanks. I think that I'll start a bisect to figure out whe
On Mon, Sep 24, 2012 at 7:45 PM, Nathaniel Smith wrote:
> On Mon, Sep 24, 2012 at 7:19 PM, Gael Varoquaux
> wrote:
>> Hi Fred,
>>
>> On Mon, Sep 24, 2012 at 02:17:16PM -0400, Frédéric Bastien wrote:
>>> with numpy '1.6.1', I have no problem.
>>
&g
On Mon, Sep 24, 2012 at 10:47 PM, Charles R Harris
wrote:
>
>
> On Mon, Sep 24, 2012 at 2:25 PM, Frédéric Bastien wrote:
>>
>> Hi,
>>
>> I tested this new beta on Theano and discovered an interface change
>> that was not there in the beta 1.
>>
>> New behavior:
>> numpy.ndindex().next()
>> (0,)
>
On Tue, Sep 25, 2012 at 10:03 AM, William Furnass wrote:
> Hi all,
>
> I want to be able to within a loop a) apply a mathematical operation
> to all elements in a vector (can be done atomically) then b) pop zero
> or more elements from one end of the vector and c) push zero or more
> elements on t
On Tue, Sep 25, 2012 at 12:31 PM, Sturla Molden wrote:
> On 25.09.2012 11:38, Nathaniel Smith wrote:
>
>> Implementing a ring buffer on top of ndarray would be pretty
>> straightforward and probably work better than a linked-list
>> implementation.
>
> Amaz
On Tue, Sep 25, 2012 at 1:27 AM, Ondřej Čertík wrote:
> On Mon, Sep 24, 2012 at 3:49 PM, Nathaniel Smith wrote:
>> On Mon, Sep 24, 2012 at 10:47 PM, Charles R Harris
>> wrote:
>>>
>>>
>>> On Mon, Sep 24, 2012 at 2:25 PM, Frédéric Bastien wrote:
>>
On Thu, Sep 27, 2012 at 3:22 PM, Thouis (Ray) Jones wrote:
> On Thu, Sep 27, 2012 at 8:46 AM, David Cournapeau wrote:
>
>> Thouis, what needs to be done to make a testbed of the conversion ?
>
> I just returned to this a couple of days ago [*], and last night
> successfully imported all the trac
Hi all,
I've gotten a pull request for scikits-sparse to switch it to using
numpy.distutils:
https://github.com/njsmith/scikits-sparse/pull/2
Overall this seems fair enough, finding libraries is a pain and
numpy.distutils has that knowledge.
1) What's the proper way to find lapack using numpy.
On Fri, Sep 28, 2012 at 10:23 PM, Gael Varoquaux <
gael.varoqu...@normalesup.org> wrote:
> Hi numpy developers,
>
> First of all, thanks a lot for the hard work you put in numpy. I know
> very well that maintaining such a core library is a lot of effort and a
> service to the community. But "with g
There are three basic Python APIs to copy an array in numpy:
a.copy(): has always returned a C-contiguous array by default. has
always taken an order= argument, which defaults to "C".
np.array(a, copy=True): by default, produces an array with whatever
memory ordering that 'a' had. Can also spe
On Sun, Sep 30, 2012 at 8:59 PM, Travis Oliphant wrote:
> Hey all,
>
> In a github-discussion with Gael and Nathaniel, we came up with a proposal
> for .base that we should put before this list.Traditionally, .base has
> always pointed to None for arrays that owned their own memory and to th
On Sun, Sep 30, 2012 at 7:22 PM, Gael Varoquaux
wrote:
> On Sun, Sep 30, 2012 at 07:17:42PM +0100, Nathaniel Smith wrote:
>> Is there anything better to do than simply revert np.copy() to its
>> traditional behaviour and accept that np.copy(a) and a.copy() will
>> conti
On Mon, Oct 1, 2012 at 3:40 PM, Thouis (Ray) Jones wrote:
> On Mon, Oct 1, 2012 at 8:20 AM, Nathaniel Smith wrote:
>> [...]
>> How can we discourage people from doing this in the future? Can we
>> make .base write-only from the Python level (with suitable deprecation
>
This PR submitted a few months ago adds a substantial new API to numpy, so
it'd be great to get more review. No-one's replied yet, though...
Any thoughts, anyone? Is it useful, could it be better...?
-n
On 9 Jun 2012 22:47, "Nathaniel Smith" wrote:
>
On Thu, Oct 11, 2012 at 10:50 AM, Nicolas Rougier
wrote:
> I missed the original post but I personally find this addition especially
> useful for my work in computational neuroscience.
>
> I did something vaguely similar in a small framework (http://dana.loria.fr/,
> you can look more specifical
This PR changes the behaviour of masked record arrays. The rationale makes
sense to me, but I don't actually use this functionality. Any masked array
users want to chime in?
-n
-- Forwarded message --
From: "Thomas Robitaille"
Date: 11 Oct 2012 19:35
Subject: [numpy] When accessin
On Tue, Oct 16, 2012 at 4:36 PM, Byron Blay wrote:
> Copying / deepcopying an array does not copy the writeable flag:
>
import numpy
from copy import deepcopy
a = numpy.array([1,2,3,4,5])
a.flags.writeable = False
b = deepcopy(a)
b.flags.writeable
> True
>
> Is this a
On Tue, Oct 16, 2012 at 9:06 PM, Thouis (Ray) Jones wrote:
> On Sun, Oct 7, 2012 at 10:15 AM, Thouis (Ray) Jones wrote:
>> I plan to import all the Trac issues to github by the end of this
>> week. I want to get an up-to-date snapshot of the Trac DB, and run
>> another test import with it (just
There's nothing like that built into numpy, no. I guess you could use
reduceat to calculate the total for each span of non-nans and then replace
each nan with the negative of that value so that plain cumsum would work,
but a loop is going to be easier (and a loop in Cython will be faster).
-n
On 2
On Fri, Nov 2, 2012 at 2:18 PM, Neal Becker wrote:
> I'm trying to convert some matlab code. I see this:
>
> b(1)=[];
>
> AFAICT, this removes the first element of the array, shifting the others.
>
> What is the preferred numpy equivalent?
Perhaps np.delete is what you're looking for. (Esp. if y
On Wed, Nov 7, 2012 at 10:41 PM, Nicolas SCHEFFER
wrote:
> Hi,
>
> I've written a snippet of code that we could call scipy.dot, a drop-in
> replacement for numpy.dot.
> It's dead easy, and just answer the need of calling the right blas
> function depending on the type of arrays, C or F order (aka
ests)
>>> >> > > http://pastebin.com/M8TfbURi
>>> >> > >
>>> >> > > -n
>>> >> > >
>>> >> > > On Thu, Nov 8, 2012 at 11:38 AM, Nicolas SCHEFFER
>>> >> > > wrote:
>>>
On 9 Nov 2012 08:48, "Gael Varoquaux" wrote:
>
> On Thu, Nov 08, 2012 at 11:29:19AM -0600, Anthony Scopatz wrote:
> > Indeed, there is no reason not to make this available in NumPy.
>
> > +1, I agree, this should be a fix in numpy, not scipy.
>
> I agree.
>
> My point was a bit of a side issue
On Fri, Nov 9, 2012 at 2:45 PM, Frédéric Bastien wrote:
>
>
>
> On Fri, Nov 9, 2012 at 3:32 AM, Nathaniel Smith wrote:
>>
>> On Fri, Nov 9, 2012 at 6:18 AM, Nicolas SCHEFFER
>> wrote:
>> > Fred,
>> >
>> > Thanks for the advice.
>> &
On Fri, Nov 9, 2012 at 4:25 PM, Gael Varoquaux
wrote:
> On Fri, Nov 09, 2012 at 03:12:42PM +0000, Nathaniel Smith wrote:
>> But what if someone compiles numpy against an optimized blas (mkl,
>> say) and then compiles SciPy against the reference blas? What do you
>> do then
On Fri, Nov 9, 2012 at 2:17 PM, Alan G Isaac wrote:
> I just noticed that 1.7 is scheduled to add a random.choice function.
> I wonder if the best structure has been chosen. Specifically, it does
> not provide for array flattening, and it does not provide for subarray
> choice.
I think in terms
for another thread, the confusion we'd like to
>> > fix here is that users shouldn't have to understand the C/F contiguous
>> > concepts to get the maximum speed for np.dot()
>> >
>> > To summarize:
>> > - The python snippet I posted is stil
On Mon, Nov 12, 2012 at 2:48 PM, Alan G Isaac wrote:
> On 11/9/2012 12:21 PM, Nathaniel Smith wrote:
>> you might want to double-check that the
>> np.random.choice in 1.7 actually*does* give an error if the input
>> array is not 1-d
>
> Any idea where I can look at t
On Mon, Nov 12, 2012 at 3:50 PM, Alan G Isaac wrote:
> On 11/12/2012 8:59 AM, Sebastian Berg wrote:
>> https://github.com/numpy/numpy/blob/master/numpy/random/mtrand/mtrand.pyx#L919
>>
>> Sounds like it should be pretty simple to add axis=None which would
>> change the current behavior very little
On Mon, Nov 12, 2012 at 5:31 PM, Alan G Isaac wrote:
> In a comment on the issue https://github.com/numpy/numpy/issues/2724
> Sebastian notes:
> "it could also be reasonable to have size=None as default and have it return
> a scalar/the given axes removed in that case. That would be a real chang
On Mon, Nov 12, 2012 at 9:08 PM, Nicolas SCHEFFER
wrote:
> I've pushed my code to a branch here
> https://github.com/leschef/numpy/tree/faster_dot
> with the commit
> https://github.com/leschef/numpy/commit/ea037770e03f23aca1a06274a1a8e8bf0e0e2ee4
>
> Let me know if that's enough to create a pull
On Mon, Nov 12, 2012 at 8:54 PM, Matthew Brett wrote:
> Hi,
>
> I wanted to check that everyone knows about and is happy with the
> scalar casting changes from 1.6.0.
>
> Specifically, the rules for (array, scalar) casting have changed such
> that the resulting dtype depends on the _value_ of the
On Mon, Nov 12, 2012 at 10:27 PM, Matthew Brett wrote:
> Hi,
>
> On Mon, Nov 12, 2012 at 1:11 PM, Nathaniel Smith wrote:
>> On Mon, Nov 12, 2012 at 8:54 PM, Matthew Brett
>> wrote:
>>> Hi,
>>>
>>> I wanted to check that everyone knows about and i
On Mon, Nov 12, 2012 at 11:34 PM, Alan G Isaac wrote:
> On 11/12/2012 12:16 PM, Sebastian Berg wrote:
>> So instead of taking a sequence of length 1, take an element as default.
>
> Sebastien has proposed that np.random.choice return
> a single *element* by default, not a 1d array of length 1.
> H
On Tue, Nov 13, 2012 at 8:26 AM, Austin Bingham
wrote:
> I'm trying to understand how numpy decides when to release memory and
> whether it's possible to exert any control over that. The situation is that
> I'm profiling memory usage on a system in which a great deal of the overall
> memory is tie
On Mon, Nov 12, 2012 at 11:27 PM, Ondřej Čertík wrote:
> I successfully defended my Ph.D. thesis last Thursday, I just need to
> do some changes to it and submit it and I am done.
Congratulations!
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy
On Tue, Nov 13, 2012 at 6:13 AM, Benjamin Root wrote:
>
> On Monday, November 12, 2012, Matthew Brett wrote:
>>
>> Hi,
>>
>> On Mon, Nov 12, 2012 at 8:15 PM, Benjamin Root wrote:
>> >
>> >
>> > On Monday, November 12, 2012, Olivie
On Tue, Nov 13, 2012 at 1:31 PM, Austin Bingham
wrote:
> I've been using psutil, pmap (linux command), and resource in various
> capacities, all on cpython. When I wasn't seeing memory freed when I
> expected, I got to wondering if maybe numpy was maintaining pools of buffers
> for reuse or someth
On Fri, Nov 16, 2012 at 6:37 AM, Charles R Harris
wrote:
> On Thu, Nov 15, 2012 at 8:24 PM, Gökhan Sever wrote:
>>
>> Hello,
>>
>> Could someone briefly explain why are these two operations are casting my
>> float32 arrays to float64?
>>
>> I1 (np.arange(5, dtype='float32')).dtype
>> O1 dtype('fl
On Fri, Nov 16, 2012 at 9:53 PM, Gökhan Sever wrote:
> Thanks for the explanations.
>
> For either case, I was expecting to get float32 as a resulting data type.
> Since, float32 is large enough to contain the result. I am wondering if
> changing casting rule this way, requires a lot of modificati
On Wed, Nov 21, 2012 at 2:52 PM, Sturla Molden wrote:
> But if this issue is in the GCD, it will probably affect other
> applications that uses the GCD and fork without exec as well. Unless you
> are certain the GCD is not used, a fork would never be safe without an exec.
I think the point is tha
On Wed, Nov 21, 2012 at 3:01 PM, Sturla Molden wrote:
> On 21.11.2012 15:55, Nathaniel Smith wrote:
>
>> I think the point is that it's easy for programmers to decide to avoid
>> GCD if they want to use multiprocessing. But it's not so easy for them
>> to deci
On Thu, Nov 22, 2012 at 12:41 PM, Chao YUE wrote:
> Dear all,
>
> if I have two ndarray arr1 and arr2 (with the same shape), is there some
> difference when I do:
>
> arr = arr1 + arr2
>
> and
>
> arr = np.add(arr1, arr2),
>
> and then if I have more than 2 arrays: arr1, arr2, arr3, arr4, arr5, th
On 23 Nov 2012 03:34, "Charles R Harris" wrote:
>
> Examples,
>
> In [13]: ones(()).flags.writeable
> Out[13]: True
>
> In [14]: (-ones(())).flags.writeable
> Out[14]: False
>
> In [15]: (-1*ones(())).flags.writeable
> Out[15]: False
>
> In [16]: (1 + ones(())).flags.writeable
> Out[16]: False
>
>
On 29 Nov 2012 16:27, "Jim Kitchen" wrote:
>
> I understand the historical reason for the "Truth value of an array" error,
> avoiding the pitfalls of:
> >>> a = np.arange(10)
> >>> if a==0: # this is ambiguous, use any() or all()
>
> I also understand the issues with logical and/or:
> >>> if (a<1
On Sun, Dec 2, 2012 at 3:16 PM, Ralf Gommers wrote:
>
> On Fri, Nov 30, 2012 at 9:07 AM, Martin Raspaud
> wrote:
>>
>> Hi,
>>
>> We noticed that comparing arrays of different shapes with allclose
>> doesn't work anymore in numpy 1.6.2.
>>
>> Is this a feature or a bug ? :)
>
>
> I vote for featur
On Mon, Dec 3, 2012 at 1:28 AM, Raul Cota wrote:
> I finally decided to track down the problem and I started by getting
> Python 2.6 from source and profiling it in one of my cases. By far the
> biggest bottleneck came out to be PyString_FromFormatV which is a
> function to assemble a string for a
On 4 Dec 2012 02:27, "Ondřej Čertík" wrote:
>
> Hi,
>
> I started to work on the release again and noticed weird failures at
Travis-CI:
[…]
> File
"/home/travis/virtualenv/python2.5/lib/python2.5/site-packages/numpy/core/tests/test_iterator.py",
The problem is that Travis started installing num
Heh, looks like we did the trac migration about a month too soon...
-- Forwarded message --
From: Damon McDougall
Date: Fri, Dec 7, 2012 at 8:15 PM
Subject: [matplotlib-devel] GitHub attachments
To: matplotlib-de...@lists.sourceforge.net
Did everyone see that GitHub now allows a
Oh, never mind, I guess they *only* allow image files. So, uh, no test
data files, but if we have any lolcats in the trac attachments, we can
migrate those.
On Fri, Dec 7, 2012 at 9:00 PM, Nathaniel Smith wrote:
> Heh, looks like we did the trac migration about a month too s
On Wed, Dec 12, 2012 at 8:20 PM, Ralf Gommers wrote:
>
> On Tue, Dec 11, 2012 at 5:44 PM, Neal Becker wrote:
>>
>> I think it's a misfeature that a floating point is silently accepted as an
>> index. I would prefer a warning for:
>>
>> bins = np.arange (...)
>>
>> for b in bins:
>> ...
>> w[b]
On Wed, Dec 12, 2012 at 9:09 PM, David Warde-Farley
wrote:
> On Wed, Dec 12, 2012 at 3:20 PM, Ralf Gommers wrote:
>> For numpy indexing this may not be appropriate though; checking every index
>> value used could slow things down and/or be quite disruptive.
>
> For array fancy indices, a dtype ch
On 14 Dec 2012 04:14, "Raul Cota" wrote:
>
>
> +1 from me
>
> For what is worth, we are just moving forward from Python 2.2 / Numeric
> and are going to 2.6 and it has been rather painful because of the
> several little details of extensions and other subtleties. I believe we
> will settle there f
I only checked this build:
https://secure.travis-ci.org/#!/certik/numpy/jobs/3656960
But that log clearly shows 'python setup.py install' being used instead of
'pip install'. How certain are you that your branch actually has my fix?
-n
On 14 Dec 2012 03:49, "Ondřej Čertík" wrote:
> On Thu, Dec 13
ually
says. And if it's wrong poke around in the git history to figure out why.
-n
On 14 Dec 2012 17:20, "Ondřej Čertík" wrote:
> On Fri, Dec 14, 2012 at 12:32 AM, Nathaniel Smith wrote:
> > I only checked this build:
> > https://secure.travis-ci.org/#!/certik/
#294 is a regression, so probably should be considered release critical. I
can't tell if #2750 is a real problem or not. #378 looks serious, but
afaict has actually been fixed even though the bug is still marked open? At
least fixed in 1.7.x?
On 15 Dec 2012 23:52, "Ondřej Čertík" wrote:
> Hi,
>
>
On 16 Dec 2012 13:38, "Ralf Gommers" wrote:
>
> On Thu, Dec 13, 2012 at 5:35 PM, Travis Oliphant
wrote:
>>
>> For people interested in the www.numpy.org home page:
>>
>> Jon Turner has officially transferred the www.numpy.org domain to
NumFOCUS. Thank you, Jon for this donation and for being
On 16 Dec 2012 23:01, "Charles R Harris" wrote:
>
>
>
> On Sun, Dec 16, 2012 at 3:50 PM, Ondřej Čertík
wrote:
>>
>> Thanks Ralf and Nathan,
>>
>> I have put high priority on the issues that need to be fixed before the
rc1.
>> There are now 4 issues:
>>
>>
https://github.com/numpy/numpy/issues?lab
On Wed, Dec 19, 2012 at 8:40 AM, Henry Gomersall wrote:
> I've written a few simple cython routines for assisting in creating
> byte-aligned numpy arrays. The point being for the arrays to work with
> SSE/AVX code.
>
> https://github.com/hgomersall/pyFFTW/blob/master/pyfftw/utils.pxi
>
> The chang
On Wed, Dec 19, 2012 at 2:57 PM, Charles R Harris
wrote:
>
>
> On Wed, Dec 19, 2012 at 7:43 AM, Nathaniel Smith wrote:
>>
>> On Wed, Dec 19, 2012 at 8:40 AM, Henry Gomersall wrote:
>> > I've written a few simple cython routines for assisting in creating
>&g
On Wed, Dec 19, 2012 at 3:27 PM, Charles R Harris
wrote:
>
>
> On Wed, Dec 19, 2012 at 8:10 AM, Nathaniel Smith wrote:
>> Right, my intuition is that it's like order="C" -- if you make a new
>> array by, say, indexing, then it may or may not have order=&qu
On Wed, Dec 19, 2012 at 6:25 PM, Henry Gomersall wrote:
> On Wed, 2012-12-19 at 19:03 +0100, Francesc Alted wrote:
>
>> > Finally, I think there is significant value in auto-aligning the
>> array
>> > based on an appropriate inspection of the cpu capabilities (or
>> > alternatively, a function th
On Thu, Dec 20, 2012 at 8:12 AM, Henry Gomersall wrote:
> On Wed, 2012-12-19 at 15:10 +0000, Nathaniel Smith wrote:
>
>> >> > Is this something that can be rolled into Numpy (the feature, not
>> my
>> >> > particular implementation or interface - thou
On Thu, Dec 20, 2012 at 11:46 PM, Matthew Brett wrote:
> Travis - I think you are suggesting that there should be no one
> person in charge of numpy, and I think this is very unlikely to work
> well. Perhaps there are good examples of well-led projects where
> there is not a clear leader, but I
On Fri, Dec 21, 2012 at 1:23 AM, Ondřej Čertík wrote:
> Hi,
>
> I noticed that the 3.1 tests are now failing. After clarification with
> the Travis guys:
>
> https://groups.google.com/d/topic/travis-ci/02iRu6kmwY8/discussion
>
> I've submitted a fix to our .travis.yml (and backported to 1.7):
>
>
On Sat, Dec 22, 2012 at 5:36 PM, Matthew Brett wrote:
> Hi,
>
> On Thu, Dec 20, 2012 at 5:39 PM, Nathaniel Smith wrote:
>> On Thu, Dec 20, 2012 at 11:46 PM, Matthew Brett
>> wrote:
>>> Travis - I think you are suggesting that there should be no one
>>>
On Wed, Dec 26, 2012 at 8:09 PM, Nicolas Rougier
wrote:
>
>
> Hi all,
>
>
> I'm looking for a way to "reduce" dtype1 into dtype2 (when it is possible of
> course).
> Is there some easy way to do that by any chance ?
>
>
> dtype1 = np.dtype( [ ('vertex', [('x', 'f4'),
>
On Sat, Dec 29, 2012 at 7:07 AM, Charles R Harris
wrote:
> Hi All,
>
> I propose a challenge: express the dtype grammar in EBNF. That's all.
Not sure I understand. Do you mean just the little string-parsing DSL
for specifying dtypes ("i4,datetime64[ms]"), or is there some way to
write EBNF for de
This discussion seems to have petered out without reaching consensus
one way or another. This seems like an important issue, so I've opened
a bug:
https://github.com/numpy/numpy/issues/2878
Hopefully this way we'll at least not forget about it; also I tried to
summarize the main issues there and
On Fri, Dec 21, 2012 at 7:20 PM, Raul Cota wrote:
> Hello,
>
>
> On Dec/2/2012 I sent an email about some meaningful speed problems I was
> facing when porting our core program from Numeric (Python 2.2) to Numpy
> (Python 2.6). Some of our tests went from 30 seconds to 90 seconds for
> example.
H
On Wed, Jan 2, 2013 at 2:56 PM, Nathaniel Smith wrote:
> On Fri, Dec 21, 2012 at 7:20 PM, Raul Cota wrote:
>> b.1)
>> I noticed that PyFloat * Float64 resulted in an unnecessary "on the fly"
>> conversion of the PyFloat into a Float64 to extract its underlying C
&g
On Wed, Jan 2, 2013 at 11:24 AM, Nathaniel Smith wrote:
> This discussion seems to have petered out without reaching consensus
> one way or another. This seems like an important issue, so I've opened
> a bug:
> https://github.com/numpy/numpy/issues/2878
> Hopefully this wa
On 3 Jan 2013 23:39, "Andrew Collette" wrote:
>
> > Consensus in that bug report seems to be that for array/scalar
operations like:
> > np.array([1], dtype=np.int8) + 1000 # can't be represented as an int8!
> > we should raise an error, rather than either silently upcasting the
> > result (as in
On 4 Jan 2013 00:39, "Peter Cock" wrote:
> I agree with Dag rather than Andrew, "Explicit is better than implicit".
> i.e. What Nathaniel described earlier as the apparent consensus.
>
> Since I've actually used NumPy arrays with specific low memory
> types, I thought I should comment about my use
On Fri, Jan 4, 2013 at 11:09 AM, Matthew Brett wrote:
> Hi,
>
> Reading the discussion on the scalar casting rule change I realized I
> was hazy on the use-cases that led to the rule that scalars cast
> differently from arrays.
>
> My impression was that the primary use-case was for lower-precisio
On Fri, Jan 4, 2013 at 4:01 PM, Andrew Collette
wrote:
> Hi Olivier,
>
>> A key difference is that with arrays, the dtype is not chosen "just
>> big enough" for your data to fit. Either you set the dtype yourself,
>> or you're using the default inferred dtype (int/float). In both cases
>> you shou
On Fri, Jan 4, 2013 at 11:09 AM, Matthew Brett wrote:
> In any case, can anyone remember the original use-cases well enough to
> record them for future decision making?
Heh. Everything new is old again. Here's a discussion from 2002 which
quotes the rationale:
http://mail.scipy.org/pipermail/nu
On Fri, Jan 4, 2013 at 6:50 AM, Raul Cota wrote:
>
> On 02/01/2013 7:56 AM, Nathaniel Smith wrote:
>> But, it's almost certainly possible to optimize numpy's float64 (and
>> friends), so that they are themselves (almost) as fast as the native
>> python objects
On Fri, Jan 4, 2013 at 11:36 PM, Raul Cota wrote:
> On 04/01/2013 2:33 PM, Nathaniel Smith wrote:
>> On Fri, Jan 4, 2013 at 6:50 AM, Raul Cota wrote:
>>> On 02/01/2013 7:56 AM, Nathaniel Smith wrote:
>>>> But, it's almost certainly possible to optimize numpy&#x
201 - 300 of 1338 matches
Mail list logo
