I have created a PR for the first two (and got np.nanvar() for free).
https://github.com/numpy/numpy/pull/3297
Cheers!
Ben Root
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Thu, May 2, 2013 at 5:25 AM, Arink Verma wrote:
> @Raul
> I will pull new version, and try to include that also.
> What is wrong with macros for inline function?
> Yes, time for ufunc is reduced to almost half, for lookup table, I am
> generating key from argument type and returning the appropr
@Raul
I will pull new version, and try to include that also.
What is wrong with macros for inline function?
Yes, time for ufunc is reduced to almost half, for lookup table, I
am generating key from argument type and returning
the appropriated value.[1]
@Chuck
Yes I did some profiling with oprofile
On Tue, Apr 30, 2013 at 8:26 PM, Arink Verma wrote:
> Hi all!
> I have written my application[1] for *Performance parity between numpy
> arrays and Python scalars[2]. *It would be a great help if you view it.
> Does it look achievable and deliverable according to the project.
>
> [1]
> http://www.
On Wed, May 1, 2013 at 7:10 PM, Benjamin Root wrote:
> So, to summarize the thread so far:
>
> Consensus:
> np.nanmean()
> np.nanstd()
> np.minmax()
> np.argminmax()
>
> Vague Consensus:
> np.sincos()
>
>
If the return of sincos (cossin?) is an array, then it could be reshaped to
be exp(1j*x), wh
Oh! I imported numpy and that worked. I probably should have mentioned
I'm working through the 2005 "*Numerical Methods in Engineering with Python*"
textbook from the school library. The examples are still good, but the
Import statement used in the book is obsolete. Thanks for the quick reply.
Mark,
Numpy is not numarray. Numarray is an older package that has long since
been replaced by numpy. You should only use numpy in any development from
now on.
Chris
On Wednesday, May 1, 2013, Mark Micklich wrote:
> Hello -- After installing numPy, I'm getting the following error message
> whe
Hello -- After installing numPy, I'm getting the following error message
when attempting to import numarray:
ImportError: No module named numarray
I do have numPy installed. I'm running under Lubuntu 12.10 and the Spyder
2.1.10 IDE. I'm fairly new to developing Python on Linux. I assume
So, to summarize the thread so far:
Consensus:
np.nanmean()
np.nanstd()
np.minmax()
np.argminmax()
Vague Consensus:
np.sincos()
No Consensus (possibly out of scope for this topic):
Better constructors for complex types
I can probably whip up the PR for the nanmean() and nanstd(), and can
certai
On Wed, 2013-05-01 at 16:37 -0400, Yaroslav Halchenko wrote:
> On Wed, 01 May 2013, Sebastian Berg wrote:
>
> > There really is no point discussing here, this has to do with numpy
> > doing iteration order optimization, and you actually *want* this. Lets
> > for a second assume that the old behavi
On Wed, 01 May 2013, Sebastian Berg wrote:
> There really is no point discussing here, this has to do with numpy
> doing iteration order optimization, and you actually *want* this. Lets
> for a second assume that the old behavior was better, then the next guy
> is going to ask: "Why is np.add.red
On Wed, 01 May 2013, Matthew Brett wrote:
> > There really is no point discussing here, this has to do with numpy
> > doing iteration order optimization, and you actually *want* this. Lets
> > for a second assume that the old behavior was better, then the next guy
> > is going to ask: "Why is np.
Hi,
On Wed, May 1, 2013 at 1:01 PM, Sebastian Berg
wrote:
> On Wed, 2013-05-01 at 15:29 -0400, Yaroslav Halchenko wrote:
>> just for completeness... I haven't yet double checked if I have done it
>> correctly but here is the bisected commit:
>>
>> aed9925a9d5fe9a407d0ca2c65cb577116c4d0f1 is the f
On Wed, 2013-05-01 at 15:29 -0400, Yaroslav Halchenko wrote:
> just for completeness... I haven't yet double checked if I have done it
> correctly but here is the bisected commit:
>
> aed9925a9d5fe9a407d0ca2c65cb577116c4d0f1 is the first bad commit
> commit aed9925a9d5fe9a407d0ca2c65cb577116c4d0f1
On Wed, May 1, 2013 at 1:24 PM, Matthew Brett wrote:
> HI,
>
> On Wed, May 1, 2013 at 9:09 AM, Yaroslav Halchenko
> wrote:
>>
>> On Wed, 01 May 2013, Nathaniel Smith wrote:
>>> > not sure there is anything to fix here. Third-party code relying on a
>>> > certain outcome of rounding error is like
just for completeness... I haven't yet double checked if I have done it
correctly but here is the bisected commit:
aed9925a9d5fe9a407d0ca2c65cb577116c4d0f1 is the first bad commit
commit aed9925a9d5fe9a407d0ca2c65cb577116c4d0f1
Author: Mark Wiebe
Date: Tue Aug 2 13:34:13 2011 -0500
ENH: uf
There are several situations where that comes up (Like comparing two sparse
matrices A == B) There is a SparseEfficiancyWarning that can be thrown, but
the way this should be implemented still needs to be discussed. I will be
writing a specification on how ufuncs and ndarrays are handled by the
spa
It is great that you are looking into this !! We are currently
running on a fork of numpy because we really need these
performance improvements .
I noticed that, as suggested, you took from the pull request I
posted a while ago for the
On 1 May 2013 20:12, Blake Griffith wrote:
> However, it would still be useful to have ufuncs working well with the
> sparse package.
How are you planning to deal with ufunc(0) != 0? cos(sparse) is actually dense.
___
NumPy-Discussion mailing list
NumPy
Oh wow, I just assumed that `dot` was a ufunc... However, it would still be
useful to have ufuncs working well with the sparse package. I don't
understand everything that is going on in
https://github.com/numpy/numpy/blob/master/numpy/core/src/umath/ufunc_object.c
But I assumed that I would be abl
On Wed, May 1, 2013 at 6:24 PM, Matthew Brett wrote:
> HI,
>
> On Wed, May 1, 2013 at 9:09 AM, Yaroslav Halchenko
> wrote:
>> 3. they are identical on other architectures (e.g. amd64)
>
> To me that is surprising. I would have guessed that the order is the
> same on 32 and 64 bit, but somethin
On Mon, Apr 29, 2013 at 2:10 PM, Andrew Giessel <
andrew_gies...@hms.harvard.edu> wrote:
> Matthew: Thanks for the link to array order discussion.
>
> Any more thoughts on Phil's slice() function?
>
>
>
I rather like Phil's solution. Just some caveats. Will it always return
views or copies? It
HI,
On Wed, May 1, 2013 at 9:09 AM, Yaroslav Halchenko wrote:
>
> On Wed, 01 May 2013, Nathaniel Smith wrote:
>> > not sure there is anything to fix here. Third-party code relying on a
>> > certain outcome of rounding error is likely incorrect anyway.
>
>> Yeah, seems to just be the standard floa
On Wed, May 1, 2013 at 6:52 AM, Benjamin Root wrote:
> How about a tuple: (min, max)?
>
>>
>>
> I am not familiar enough with numpy internals to know which is the better
> approach to implement. I kind of feel that the 2xN array approach would be
> more flexible in case a user wants all of this
On Wed, May 1, 2013 at 10:14 AM, Daπid wrote:
> On 1 May 2013 03:36, Benjamin Root wrote:
> > Are there any other functions that others feel are "missing" from numpy
> and
> > would like to see for v1.8? Let's discuss them here.
>
> I would like to have sincos, to compute sin and cos of the sam
On Wed, 01 May 2013, Nathaniel Smith wrote:
> > not sure there is anything to fix here. Third-party code relying on a
> > certain outcome of rounding error is likely incorrect anyway.
> Yeah, seems to just be the standard floating point indeterminism.
> Using Matthew's numbers and pure Python flo
On Wed, May 1, 2013 at 4:22 PM, Daπid wrote:
> On 1 May 2013 17:13, Todd wrote:
>> Speaking of which, I think there should be a function to construct a complex
>> array out of two identically-shaped floating-point arrays, as well as
>> perhaps an np.i class that converts a real array to an imagin
On Wed, May 1, 2013 at 5:22 PM, Daπid wrote:
> On 1 May 2013 17:13, Todd wrote:
> > Speaking of which, I think there should be a function to construct a
> complex
> > array out of two identically-shaped floating-point arrays, as well as
> > perhaps an np.i class that converts a real array to an
On 1 May 2013 17:13, Todd wrote:
> Speaking of which, I think there should be a function to construct a complex
> array out of two identically-shaped floating-point arrays, as well as
> perhaps an np.i class that converts a real array to an imaginary one (using
> __mul__ and such).
np.i would be
Hi all,
I'm wondering if you think the following behavior in numpy.clip is a bug
(it certainly confused me for a while):
>>> x = np.arange(5.)
>>> xx = x.clip(None,3.)
>>> xx
array([0.0, 1.0, 2.0, 3.0, 3.0], dtype=object)
Since xx now has the dtype of object, doing things like
>>> np.exp(xx)
Attri
On Wed, May 1, 2013 at 4:06 PM, Zachary Ploskey wrote:
> The sincos function is in the c standard library in math.h.
I don't think it's part of the C99 standard. It appears to be provided
in glibc as a non-standard extension. We would have to provide our own
copy, but one is available in the Ceph
On Wed, May 1, 2013 at 3:36 AM, Benjamin Root wrote:
>
> Are there any other functions that others feel are "missing" from numpy
> and would like to see for v1.8? Let's discuss them here.
>
As I mentioned before, I think numpy should have some equations for dealing
with n-dimensional vectors (b
The sincos function is in the c standard library in math.h.
On May 1, 2013 7:56 AM, "Juan Luis Cano" wrote:
> On 05/01/2013 04:14 PM, Daπid wrote:
> > On 1 May 2013 03:36, Benjamin Root wrote:
> >> Are there any other functions that others feel are "missing" from numpy
> and
> >> would like to s
On 05/01/2013 04:14 PM, Daπid wrote:
> On 1 May 2013 03:36, Benjamin Root wrote:
>> Are there any other functions that others feel are "missing" from numpy and
>> would like to see for v1.8? Let's discuss them here.
> I would like to have sincos, to compute sin and cos of the same number
> faster
On 1 May 2013 03:36, Benjamin Root wrote:
> Are there any other functions that others feel are "missing" from numpy and
> would like to see for v1.8? Let's discuss them here.
I would like to have sincos, to compute sin and cos of the same number
faster. According to some benchmarks, it is barely
On Wed, May 1, 2013 at 9:12 AM, Pauli Virtanen wrote:
> 01.05.2013 16:01, Yaroslav Halchenko kirjoitti:
> [clip]
>> to ignorant me, even without considering 'correctness', it is just
>> a typical regression -- results changed from one release to another (and
>> not to the better side).
>
> To me t
On Wed, May 1, 2013 at 1:13 AM, Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:
> > Of course, the documentation for discussed before: np.minmax(). My
> thinking is that it would return a 2xN array
>
> How about a tuple: (min, max)?
>
>
I am not familiar enough with numpy internals to
01.05.2013 16:01, Yaroslav Halchenko kirjoitti:
[clip]
> to ignorant me, even without considering 'correctness', it is just
> a typical regression -- results changed from one release to another (and
> not to the better side).
To me this seems to be a consequence of performing additions in a
differ
On Wed, 01 May 2013, Nathaniel Smith wrote:
>> Thanks everyone for the feedback.
>> Is it worth me starting a bisection to catch where it was introduced?
>Is it a bug, or just typical fp rounding issues? Do we know which answer
>is correct?
to ignorant me, even without considerin
On 1 May 2013 08:49, "Yaroslav Halchenko" wrote:
>
> Thanks everyone for the feedback.
>
> Is it worth me starting a bisection to catch where it was introduced?
Is it a bug, or just typical fp rounding issues? Do we know which answer is
correct?
-n
___
Thanks everyone for the feedback.
Is it worth me starting a bisection to catch where it was introduced?
On Wed, 01 May 2013, Sebastian Berg wrote:
> > so might be wrong). One simple try hinting that this may be going on
> > would be to data fortran order.
> Well I guess it is optimized and the
On Wed, 2013-05-01 at 11:00 +0200, Sebastian Berg wrote:
> On Tue, 2013-04-30 at 22:20 -0700, Matthew Brett wrote:
> > Hi,
> >
> > On Tue, Apr 30, 2013 at 9:16 PM, Matthew Brett
> > wrote:
> > > Hi,
> > >
> > > On Tue, Apr 30, 2013 at 8:08 PM, Yaroslav Halchenko
> > > wrote:
> > >> could anyone
On Tue, 2013-04-30 at 22:20 -0700, Matthew Brett wrote:
> Hi,
>
> On Tue, Apr 30, 2013 at 9:16 PM, Matthew Brett
> wrote:
> > Hi,
> >
> > On Tue, Apr 30, 2013 at 8:08 PM, Yaroslav Halchenko
> > wrote:
> >> could anyone on 32bit system with fresh numpy (1.7.1) test following:
> >>
> >>> wget -nc
43 matches
Mail list logo
