Re: [Numpy-discussion] axis parameter for count_nonzero

for help as *@juliantaylor* pointed out. The *scipy* library has dealt with this problem as well in its *sparse* modules, so that is also a useful resource. Feedback on this issue would be much appreciated! Thanks! On Sun, May 22, 2016 at 1:36 PM, G Young wrote: > After some discussion with *

Re: [Numpy-discussion] broadcasting for randint

maintainers* so as to help get this merged! Thanks! On Tue, Jun 7, 2016 at 1:23 PM, G Young wrote: > There seems to be a push in my PR now for using Tempita as a way to solve > this issue with the ad-hoc templating. However, before I go about > attempting this, it would be great to receive

Re: [Numpy-discussion] broadcasting for randint

, 2016 at 3:04 AM, G Young wrote: > Just wanted to ping the mailing list again in case this email (see below) > got lost in your inboxes. Would be great to get some feedback on this! > Thanks! > > On Sun, May 22, 2016 at 2:15 AM, G Young wrote: > >> Hi, >> >>

Re: [Numpy-discussion] broadcasting for randint

Just wanted to ping the mailing list again in case this email (see below) got lost in your inboxes. Would be great to get some feedback on this! Thanks! On Sun, May 22, 2016 at 2:15 AM, G Young wrote: > Hi, > > I have had a PR <https://github.com/numpy/numpy/pull/6938> open f

Re: [Numpy-discussion] axis parameter for count_nonzero

@juliantaylor* pointed out. The *scipy* library has dealt with this problem as well in its *sparse* modules, so that is also a useful resource. On Sun, May 22, 2016 at 1:35 PM, G Young wrote: > 1) Correction: The PR was not written with small arrays in mind. I ran > some new timing tes

Re: [Numpy-discussion] axis parameter for count_nonzero

be a large technical brick wall up against such an implementation. So suggestions about how to move the code into C would be welcome too! On Sun, May 22, 2016 at 10:32 AM, Ralf Gommers wrote: > > > On Sun, May 22, 2016 at 3:05 AM, G Young wrote: > >> Hi, >> &

Re: [Numpy-discussion] broadcasting for randint

Hi, I have had a PR open for quite some time now that allows arguments to broadcast in *randint*. While the functionality is fully in-place and very robust, the obstacle at this point is the implementation. When the *dtype* parameter was added to *randi

Re: [Numpy-discussion] axis parameter for count_nonzero

Hi, I have had a PR open (first draft can be found here ) for quite some time now that adds an 'axis' parameter to *count_nonzero*. While the functionality is fully in-place, very robust, and actually higher-perfo

Re: [Numpy-discussion] linux wheels coming soon

Actually, conda pip will install the wheels that you put up. The good news is: they all (by which I mean *numpy* and *scipy* both on 2.7 and 3.5) pass! On Thu, Apr 14, 2016 at 7:26 PM, Matthew Brett wrote: > Hi, > > On Thu, Apr 14, 2016 at 11:11 AM, Benjamin Root > wrote: > > Are we going to h

Re: [Numpy-discussion] linux wheels coming soon

Matthew, you are correct. A lot of things happened with random integer generation recently (including deprecating random_integers), but I believe those warnings should be squashed in the up and coming version of SciPy from what I remember. On Mon, Apr 4, 2016 at 6:47 PM, Matthew Brett wrote: >

Re: [Numpy-discussion] fromnumeric.py internal calls

worth testing this change against third party array libraries > that implement their own array like classes? Off the top of my head, maybe > scipy, pandas, dask, astropy, pint, xarray? > On Wed, Feb 24, 2016 at 3:40 AM G Young wrote: > >> Hello all, >> >> I have PR #73

Re: [Numpy-discussion] fromnumeric.py internal calls

Hello all, I have PR #7325 up that changes the internal calls for functions in *fromnumeric.py* from positional arguments to keyword arguments. I made this change for two reasons: 1) It is consistent with the external function signature 2) The in

Re: [Numpy-discussion] making "low" optional in numpy.randint

Your statement is a little self-contradictory, but in any case, you shouldn't worry about random_integers getting removed from the code-base. However, it has been deprecated in favor of randint. On Wed, Feb 17, 2016 at 11:48 PM, Juan Nunez-Iglesias wrote: > Also fwiw, I think the 0-based, half-o

Re: [Numpy-discussion] making "low" optional in numpy.randint

-02-17 at 20:48 +, Robert Kern wrote: > > > On Wed, Feb 17, 2016 at 8:43 PM, G Young > > > wrote: > > > > > > > Josef: I don't think we are making people think more. They're > > > > all > > > keyword arguments, so if yo

Re: [Numpy-discussion] making "low" optional in numpy.randint

eb 17, 2016 at 8:48 PM, Robert Kern wrote: > On Wed, Feb 17, 2016 at 8:43 PM, G Young wrote: > > > Josef: I don't think we are making people think more. They're all > keyword arguments, so if you don't want to think about them, then you leave > them as the defaults,

Re: [Numpy-discussion] making "low" optional in numpy.randint

ead this issue here <https://github.com/numpy/numpy/issues/6790> and the PR's that followed so that you have a better understanding as to why this 'weird' behavior was chosen. On Wed, Feb 17, 2016 at 8:30 PM, Alan Isaac wrote: > On 2/17/2016 12:28 PM, G Young wrote: >

Re: [Numpy-discussion] making "low" optional in numpy.randint

binov...@gmail.com> wrote: > On Wed, Feb 17, 2016 at 1:37 PM, wrote: > > > > > > On Wed, Feb 17, 2016 at 10:01 AM, G Young wrote: > >> > >> Hello all, > >> > >> I have a PR open here that makes "low" an optional parameter in &

Re: [Numpy-discussion] making "low" optional in numpy.randint

Perhaps, but we are not coding in Haskell. We are coding in Python, and the standard is that the endpoint is excluded, which renders your point moot I'm afraid. On Wed, Feb 17, 2016 at 5:10 PM, Alan Isaac wrote: > On 2/17/2016 11:46 AM, Robert Kern wrote: > >> some at least are 1-based indexing

Re: [Numpy-discussion] making "low" optional in numpy.randint

Actually, it has already been deprecated because I did it myself. :) On Wed, Feb 17, 2016 at 4:46 PM, Robert Kern wrote: > On Wed, Feb 17, 2016 at 4:40 PM, Alan Isaac wrote: > > > > Behavior of random integer generation: > > Python randint[a,b] > > MATLAB randi [a,b] > > Mma RandomInte

Re: [Numpy-discussion] making "low" optional in numpy.randint

Hello all, I have a PR open here that makes "low" an optional parameter in numpy.randint and introduces new behavior into the API as follows: 1) `low == None` and `high == None` Numbers are generated over the range `[lowbnd, highbnd)`, where `lowbnd = n

Re: [Numpy-discussion] building NumPy with gcc if Python was built with icc?!?

I'm not sure about anyone else, but having been playing around with both gcc and icc, I'm afraid you might be out of luck. Is there any reason why you can't use a Python distribution built with gcc? On Tue, Feb 16, 2016 at 7:39 PM, BERGER Christian wrote: > Hi All, > > > > Here's a potentially

Re: [Numpy-discussion] Fwd: Windows wheels for testing

I've actually had test failures on occasion (i.e. when I run "numpy.test()") with his builds but overall, they are quite good. Speaking of MKL, for anyone who uses conda, does anyone know if it is possible to link the "mkl" package to the numpy source? My first guess is no since the description a

Re: [Numpy-discussion] Fwd: Windows wheels for testing

AFAIK the vcvarsall.bat error occurs when your MSVC directories aren't properly linked in your system registry, so Python cannot find the file. This is not a numpy-specific issue, so I certainly would agree that that failure is not blocking. Other than that, this build contains the mingw32.lib bug

Re: [Numpy-discussion] Building Numpy with OpenBLAS

with OpenBLAS. > > Carl > > 2016-01-27 16:01 GMT+01:00 Ralf Gommers : > >> >> >> On Wed, Jan 27, 2016 at 3:51 PM, G Young wrote: >> >>> I don't need it at this point. I'm just going through the exercise for >>> purposes of updat

Re: [Numpy-discussion] Building Numpy with OpenBLAS

I don't need it at this point. I'm just going through the exercise for purposes of updating building from source on Windows. But that's good to know though. Thanks! Greg On Wed, Jan 27, 2016 at 2:48 PM, Ralf Gommers wrote: > > > On Wed, Jan 27, 2016 at 3:19 PM, G

Re: [Numpy-discussion] Building Numpy with OpenBLAS

helpful tool in diagnosing dll problems is dependency walker: > http://www.dependencywalker.com/ > > It may be that your openblas has a dependency that it can't load for some > reason. Dependency walker works on .pyd files as well as .dll files. > > Hth, > Michael > >

Re: [Numpy-discussion] Building Numpy with OpenBLAS

import library. The .dll is used at > runtime, not at link time. This is different from *nix, where the .so > serves both purposes. The link you posted mentions import files, so I hope > this is helpful information. > > Best, > Michael > > On Wed, Jan 27, 2016, 03:39 G Youn

Re: [Numpy-discussion] Building Numpy with OpenBLAS

Hello all, I'm trying to update the documentation for building Numpy from source, and I've hit a brick wall in trying to build the library using OpenBLAS because I can't seem to link the libopenblas.dll file. I tried following the suggestion of placing the DLL in numpy/core as suggested here

Re: [Numpy-discussion] Appveyor Testing Changes

> On Tue, Jan 26, 2016 at 2:13 AM, G Young wrote: > >> Ah, yes, that is true. That point had completely escaped my mind. In >> light of this, it seems that it's not worth the while then to completely >> switch over to pip + virtualenv. It's might be better actual

Re: [Numpy-discussion] Appveyor Testing Changes

ite can be expanded, though I'm not sure how prudent that is given how slow Appveyor tests run. Greg On Tue, Jan 26, 2016 at 12:13 AM, Bryan Van de Ven wrote: > > > On Jan 25, 2016, at 5:21 PM, G Young wrote: > > > > With regards to testing numpy, both Conda and Pip + V

Re: [Numpy-discussion] Appveyor Testing Changes

16 at 10:50 PM, Nathaniel Smith wrote: > On Mon, Jan 25, 2016 at 2:37 PM, G Young wrote: > > Hello all, > > > > I currently have a branch on my fork (not PR) where I am experimenting > with > > running Appveyor CI via Virtualenv instead of Conda. I have build >

Re: [Numpy-discussion] Appveyor Testing Changes

Hello all, I currently have a branch on my fork (not PR) where I am experimenting with running Appveyor CI via Virtualenv instead of Conda. I have build running here . What do people think of using Virtualenv (as we do on Travis) i

Re: [Numpy-discussion] Behavior of np.random.uniform

In principle, if we are describing an *interval*, that is the right thing to do: https://en.wikipedia.org/wiki/Interval_(mathematics)#Including_or_excluding_endpoints Alan Isaac On 1/19/2016 9:21 AM, G Young wrote: Of the methods defined in *numpy/mtrand.pyx* (excluding helper functions and

Re: [Numpy-discussion] Behavior of np.random.uniform

; on both ends, so order doesn't matter, though if it raises for b that's a precedent we could follow. > > (Sorry, on a phone, can't check) > > CHB > > > > On Jan 19, 2016, at 6:21 AM, G Young wrote: > > Of the methods defined in *numpy/mtrand.pyx* (excl

Re: [Numpy-discussion] Behavior of np.random.uniform

Of the methods defined in *numpy/mtrand.pyx* (excluding helper functions and *random_integers*, as they are all related to *randint*), *randint* is the only other function with *low* and *high* parameters. However, it enforces *high* > *low*. Greg On Tue, Jan 19, 2016 at 1:36 PM, Benjamin Root

Re: [Numpy-discussion] Building master issues on Windows

Hello all, Turns out I needed to do a complete re-installation of essentially everything that was involved in my Numpy setup. Now everything is working just fine! Cheers, Greg On Tue, Jan 5, 2016 at 7:45 AM, G Young wrote: > Sure. I'm running Windows 7 with Python 2.7.11, gcc 4.

[Numpy-discussion] Building master issues on Windows

Hello all, I've recently encountered issues building numpy off master on Windows in which setup.py complains that it can't find the Advapi library in any directories (which is an empty list). I scanned the DLL under System32 and ran /sfc scannow as Administrator, and both came up clean. Is an

Re: [Numpy-discussion] dtype random.rand

Hello, Issue #6790 had requested the enhancement of adding the dtype argument to both random.randint and random.rand. With #6910 merged in, that addresses the first half of the request. What do people think o

Re: [Numpy-discussion] deprecate random.random_integers

Hello all, In light of the discussion in #6910 , I have gone ahead and deprecated random_integers in my most recent PR here . As this is an API change (sort of), what are people's thoughts on this deprecation? Th

[Numpy-discussion] Fwd: Python 3.3 i386 Build

I accidentally subscribed to the defunct discussion mailing list, so my email got rejected the first time I sent to the active mailing list. My question is in the forwarded email below: -- Forwarded message -- From: G Young Date: Mon, Dec 14, 2015 at 3:47 PM Subject: re: Python

Re: [Numpy-discussion] FeatureRequest: support for array construction from iterators

On 11/27/2015 5:37 AM, Stephan Sahm wrote: I like to request a generator/iterator support for np.array(...) as far as list(...) supports it. http://docs.scipy.org/doc/numpy/reference/generated/numpy.fromiter.html hth, Alan Isaac ___ NumPy-Discussio

[Numpy-discussion] record array performance issue / bug

Hi, Using the latest numpy from anaconda (1.10.1) on Python 2.7, I found that the following code works OK if npackets = 2, but acts bizarrely if npackets is large (2**12): --- npackets = 2**12 dlen=2048 PacketType = np.dtype([('timestamp','float64'), ('pkts',np.

Re: [Numpy-discussion] Backwards-incompatible improvements to numpy.random.RandomState

On 5/24/2015 8:47 AM, Ralf Gommers wrote: > Values only change if you leave out the call to seed() OK, but this claim seems to conflict with the following language: "the global RandomState object should use the latest implementation of the methods". I take it that this is what Nathan meant by "I

Re: [Numpy-discussion] Backwards-incompatible improvements to numpy.random.RandomState

I echo Ralf's question. For those who need replicability, the proposed upgrade path seems quite radical. Also, I would prefer to have the new functionality introduced beside the existing implementation of RandomState, with an announcement that RandomState will change in the next major numpy versi

Re: [Numpy-discussion] Proposed deprecations for 1.10: dot corner cases

On 5/11/2015 3:52 PM, Nathaniel Smith wrote: > Not sure what you mean. It's true that PEP 465 doesn't say anything about > np.dot, because it's out of scope. The argument here, though, is not "PEP > 465 says we have to do this". It's that it's confusing to have two different > subtly different se

Re: [Numpy-discussion] Proposed deprecations for 1.10: dot corner cases

On 5/9/2015 4:26 PM, Nathaniel Smith wrote: > dot(A, B) where one of the argument is a scalar: currently, this > does scalar multiplication. There is no logically consistent > motivation for this, it violates TOOWTDI, and again it is inconsistent > with the PEP semantics for @ (which are that this

Re: [Numpy-discussion] On responding to dubious ideas (was: Re: Advanced indexing: "fancy" vs. orthogonal)

> Alan wrote: >> 3. I admit, my students are NOT using non-boolen fancy indexing on >> >multidimensional arrays. (As far as I know.) Are yours? On 4/9/2015 2:22 AM, Nathaniel Smith wrote: > Well, okay, this would explain it, since integer fancy indexing is > exactly the confusing case:-) On th

Re: [Numpy-discussion] On responding to dubious ideas (was: Re: Advanced indexing: "fancy" vs. orthogonal)

On 4/9/2015 1:57 AM, Nathaniel Smith wrote: > Do you think there's anything we could be > doing to reduce this kind of adrenaline reaction while still allowing > for relaxed discussion about out-there ideas? numpy3...@scipy.org :-) ___ NumPy-Discussion

Re: [Numpy-discussion] On responding to dubious ideas (was: Re: Advanced indexing: "fancy" vs. orthogonal)

1. I use numpy in teaching. I have never heard a complaint about its indexing behavior. Have you heard such complaints? 2. One reason I use numpy in teaching is its indexing behavior. What specific language provides a better indexing model, in your opinion? 3. I admit, my students are NOT using n

Re: [Numpy-discussion] On responding to dubious ideas (was: Re: Advanced indexing: "fancy" vs. orthogonal)

That analogy fails because it suggests a private conversation. This list is extremely public. For example, I am just a user, and I am on it. I can tell you that as a long-time numpy user my reaction to the proposal to change indexing semantics was (i) OMG YMBFKM and then (ii) take a breath; thi

Re: [Numpy-discussion] argument handling by uniform

On 3/13/2015 12:01 PM, Robert Kern wrote: > Roughly equivalent to: > > uni = np.array([ >np.random.uniform(-0.5, 201), >np.random.uniform(0.5, 201), > ]) OK, broadcasting of `low` and `high` is reasonably fun. But is it documented? I was looking at the docstring, which matches the online

[Numpy-discussion] argument handling by uniform

Today I accidentally wrote `uni = np.random.uniform((-0.5,0.5),201)`, supply a tuple instead of separate low and high values. This gave me two draws (from [0..201] I think). My question: how were the arguments interpreted? Thanks, Alan Isaac ___ NumPy

Re: [Numpy-discussion] Matrix Class

On 2/11/2015 2:25 PM, cjw wrote: > I think of the matrix as a numeric object. What would the case be for having > a Boolean matrix? It's one of my primary uses: https://en.wikipedia.org/wiki/Adjacency_matrix Numpy alread provides SVD: http://docs.scipy.org/doc/numpy/reference/generated/numpy.l

Re: [Numpy-discussion] Matrix Class

Just recalling the one-year-ago discussion: http://comments.gmane.org/gmane.comp.python.numeric.general/56494 Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] The future of ndarray.diagonal()

On 1/5/2015 10:48 AM, josef.p...@gmail.com wrote: > Dtypes are a mess (in terms of code compatibility). Matlab is much nicer, > it's all just doubles. 1. Thank goodness for dtypes. 2. http://www.mathworks.com/help/matlab/numeric-types.html 3. After translating Matlab code to much nicer NumPy,

Re: [Numpy-discussion] diag, diagonal, ravel and all that

> On Sat, Jan 3, 2015 at 8:05 AM, Alan G Isaac wrote: >> Would this really be practicality beating purity? >> It would be nice to have know the principle governing this. >> For example, is there a way to convincingly group these as >> array oper

Re: [Numpy-discussion] diag, diagonal, ravel and all that

Would this really be practicality beating purity? It would be nice to have know the principle governing this. For example, is there a way to convincingly group these as array operations vs matrix operations? Personally I am puzzled by preserving subtype of `diagonal` and very especially of `ravel`

[Numpy-discussion] should unpackbits take a dtype?

As the question asks: should `unpackbits` add a dtype argument? At the moment I'm interest in unpacking as a boolean array. Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] divmod?

Just wondering why there is no `np.divmod` corresponding to `ndarray.__divmod__`? (I realize one can just use `divmod`.) Couldn't the `out` argument be useful? Thanks, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.

[Numpy-discussion] recover original array from unpackbits

I'm using `packbits` to store directed graphs. I save the packed arrays as .npy files for later use. (I had hoped that .npy files for boolean arrays might be packed, but this is not true -- not sure why.) Because of the zero padding, to recover them after `unpackbits`, I need the graph dimensions

Re: [Numpy-discussion] packbits / unpackbits bugs or misfeatures?

Six years ago Zachary Pincus wrote: > it would kind of make more sense, at least to me, for > unpackbits to return a boolean array, and packbits to take > boolean arrays. I could try to look into fixing the code > instead of the docs, if others agree. I agree with this. (Better late than never?

Re: [Numpy-discussion] truthiness of object arrays

On 11/13/2014 1:32 PM, Nathaniel Smith wrote: > I think you're being misled by buggy exception handling weirdness, > where the ValueError raised by calling __bool__ is getting delayed, > and then pre-empting the AttributeError that should be generated by > the call to __nonzero__. Aha! Thanks. _

Re: [Numpy-discussion] truthiness of object arrays

On 11/13/2014 12:37 PM, Antony Lee wrote: > On Python3, __nonzero__ is never defined (always raises an AttributeError), > even after calling __bool__. The example I posted was Python 3.4.1 with numpy 1.9.0. fwiw, Alan Isaac Python 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 10:38:22) [MSC v.1600

Re: [Numpy-discussion] truthiness of object arrays

On 11/13/2014 1:19 AM, Antony Lee wrote: > "t.__bool__()" also returns True But t.__nonzero__() is being called in the `if` test. The question is: is the difference between `__nonzero__` and `__bool__` intentional. By the way, there has been a change in behavior. For example, in 1.7.1 if you cal

Re: [Numpy-discussion] Add `nrows` to `genfromtxt`

On 11/1/2014 3:15 PM, Warren Weckesser wrote: > I intended the result of `genfromtxt(..., max_rows=n)` to produce the same > array as produced by `genfromtxt(...)[:n]`. I find that counterintuitive. I would first honor skip_header. Cheers, Alan ___ Num

Re: [Numpy-discussion] Add `nrows` to `genfromtxt`

On 11/1/2014 4:41 PM, Alexander Belopolsky wrote: > I cannot think of a situation where I would need more generality such as > reading every 3rd row or rows with the given numbers. Such processing is > normally done after the text data is loaded into an array. I have done this as cheaper than r

Re: [Numpy-discussion] Add `nrows` to `genfromtxt`

On 11/1/2014 10:31 AM, Warren Weckesser wrote: > Alan's suggestion to use a slice is interesting, but I'd like to > see a more concrete proposal for the API. For example, how does > it interact with `skip_header` and `skip_footer`? How would one > use it to read a file in batches? I'm probably

Re: [Numpy-discussion] Why ndarray provides four ways to flatten?

On 10/28/2014 1:42 PM, Stephan Hoyer wrote: > np.nditer is a reasonable alternative to .flat (and it's documented as such), > but it's a rather inelegant, kitchen-sink type function. I'm not sure what "reasonable" means here, other than "in principle, possible to use". In particular, `flat` is

Re: [Numpy-discussion] Why ndarray provides four ways to flatten?

On 10/28/2014 1:25 PM, Nathaniel Smith wrote: > I too would be curious to know why .flat exists (beyond "it seemed like a > good idea at the time" How else would you iterate over all items of a multidimensional array? As an example application, use it to assign to an arbitrary diagonal. (It can

[Numpy-discussion] fsin on Intel

This is not NumPy specific but may still interest list members: http://randomascii.wordpress.com/2014/10/09/intel-underestimates-error-bounds-by-1-3-quintillion/ Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.or

Re: [Numpy-discussion] Add `nrows` to `genfromtxt`

On 9/24/2014 2:52 PM, Jaime Fernández del Río wrote: > There is a PR in github that adds a new keyword to the genfromtxt function, > to limit the number of rows that actually get read in: > https://github.com/numpy/numpy/pull/5103 Sorry to come late to this party, but it seems to me that more ver

Re: [Numpy-discussion] SFMT (faster mersenne twister)

On 9/5/2014 1:19 PM, Neal Becker wrote: > I think it's somewhat debatable whether generating a different sequence of > random numbers counts as breaking backward compatibility. Please: it does. Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discuss

[Numpy-discussion] odd (?) behavior: negative integer scalar in exponent

What should be the value of `2**np.int_(-32)`? It is apparently currently computed as `1. / (2**np.int_(32))`, so the computation overflows (when a C long is 32 bits). I would have hoped for it to be computed as `1./(2.**np.int_(32))`. Cheers, Alan Isaac ___

Re: [Numpy-discussion] Preliminary thoughts on implementing __matmul__

> On Wed, Aug 6, 2014 at 8:32 AM, Charles R Harris wrote: >> Should also mention that we don't have the ability to >> operate on stacked vectors because they can't be >> identified by dimension info. One >> workaround is to add dummy dimensions where needed, >> another is to add two flags, row and

Re: [Numpy-discussion] numpy.mean still broken for largefloat32arrays

On 7/25/2014 1:40 PM, Eelco Hoogendoorn wrote: > At the risk of repeating myself: explicit is better than implicit This sounds like an argument for renaming the `mean` function `naivemean` rather than `mean`. Whatever numpy names `mean`, shouldn't it implement an algorithm that produces the mean

Re: [Numpy-discussion] numpy.mean still broken for large float32arrays

On 7/24/2014 4:42 PM, Eelco Hoogendoorn wrote: > This isn't a bug report, but rather a feature request. I'm not sure statement this is correct. The mean of a float32 array can certainly be computed as a float32. Currently this is not necessarily what happens, not even approximately. That feels a

Re: [Numpy-discussion] numpy.mean still broken for large float32 arrays

On 7/24/2014 5:59 AM, Eelco Hoogendoorn wrote to Thomas: > np.mean isn't broken; your understanding of floating point number is. This comment seems to conflate separate issues: the desirable return type, and the computational algorithm. It is certainly possible to compute a mean of float32 doing

Re: [Numpy-discussion] Short-hand array creation in `numpy.mat` style

Martinot-Lagarde wrote: > Le 18/07/2014 20:42, Charles G. Waldman a écrit : >> Well, if the goal is "shorthand", typing numpy.array(numpy.mat()) >> won't please many users. >> >> But the more I think about it, the less I think Numpy should support >>

Re: [Numpy-discussion] Short-hand array creation in `numpy.mat` style

ence in (non-whitespace) chars is 19 vs 25, so the "shorthand" doesn't seem to save that much. Just my €0.02, - C On Fri, Jul 18, 2014 at 10:05 AM, Alan G Isaac wrote: > On 7/18/2014 12:45 PM, Mark Miller wrote: >> If the true goal is to just allow quick entry of

Re: [Numpy-discussion] Short-hand array creation in `numpy.mat` style

On 7/18/2014 12:45 PM, Mark Miller wrote: > If the true goal is to just allow quick entry of a 2d array, why not just > advocate using > a = numpy.array(numpy.mat("1 2 3; 4 5 6; 7 8 9")) It's even simpler: a = np.mat(' 1 2 3;4 5 6;7 8 9').A I'm not putting a dog in this race. Still I would say

Re: [Numpy-discussion] Numpy BoF at SciPy 2014 - quick report

On 7/18/2014 4:03 AM, Sebastian Berg wrote: > Changing `.T` to promote to > 2-d (also maybe to actually only transpose the last two axes for higher > D arrays), could be nice, but getting there might take quite a long > FutureWarning or even Error -> new feature cycle. Considering the extent of i

Re: [Numpy-discussion] Short-hand array creation in `numpy.mat` style

I greatly prefer "np.mat" to "np.arr" for this, FWIW On Fri, Jul 18, 2014 at 3:37 AM, Nathaniel Smith wrote: > On Thu, Jul 17, 2014 at 11:10 PM, Charles G. Waldman > wrote: >> >> -1 on the 'arr' name. I think if we're going to support t

Re: [Numpy-discussion] Short-hand array creation in `numpy.mat` style

-1 on the 'arr' name. I think if we're going to support this function at all (which I'm not convinced is a good idea), it should be np.fromsomething like the other from* functions. Maybe frommatlab? I think that 'arr' is just too generic and too close to 'array'. On Tue, Jul 15, 2014 at 3:5

Re: [Numpy-discussion] Short-hand array creation in `numpy.mat` style

On 7/7/2014 7:17 AM, Daπid wrote: > How about a new one? np.matarray, for MATLAB array. How about `str2arr` or even `build`, since teaching appears to be a focus. Also, I agree '1 2 3' shd become 1d and '1 2 3;' shd become 2d. It seems unambiguous to allow '1 2 3;;' to be 3d, or even '1 2;3 4;;5

Re: [Numpy-discussion] Remove bento from numpy

On 7/5/2014 6:42 PM, Ralf Gommers wrote: > What next, we give Alan Isaac commit rights and then it's OK to break > numpy.matrix when that's convenient? I always wondered what I would do with commit rights ... Alan ___ NumPy-Discussion mailing list Nu

Re: [Numpy-discussion] should rint return int?

On 4/28/2014 3:29 PM, Neal Becker wrote: > Well I'd spell it nint, and it works like: Wouldn't it be simpler to add a dtype argument to `rint`? Or does that violate the "simple wrapper" intent? Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discuss

[Numpy-discussion] numerical gradient, Jacobian, and Hessian

Awhile back there were good signs that SciPy would end up with a `diff` module: https://github.com/scipy/scipy/issues/2035 Is this still moving forward? It would certainly be nice for SciPy to have intuitive numerical gradients, Jacobians, and Hessians. The last two are I think missing altogether

[Numpy-discussion] min depth to nonzero in 3d array

Given an array A of shape m x n x n (i.e., a stack of square matrices), I want an n x n array that gives the minimum "depth" to a nonzero element. E.g., the 0,0 element of the result is np.flatnonzero(A[:,0,0])[0] Can this be vectorized? (Assuming a nonzero element exists is ok, but dealing nicely

Re: [Numpy-discussion] index partition

On 4/12/2014 5:20 PM, Alexander Belopolsky wrote: > The "set routines" [1] are in this category and may help > you deal with partitions, but I would recommend using > boolean arrays instead. If you commonly deal with both > a subset and a complement, set representation does not > give you a memory

[Numpy-discussion] index partition

From a 1d array, I want two arrays of indexes: the first for elements that satisfy a criterion, and the second for elements that do not. Naturally there are many ways to do this. Is there a preferred way? As a simple example, suppose for array `a` I want np.flatnonzero(a>0) and np.flatnonzero(a

[Numpy-discussion] boolean operations on boolean arrays

This is a very basic question. Suppose `a` and `b` are boolean arrays with the same shape. Are there any considerations besides convenience in choosing between: a&b a*b logical_and(a,b) a|b a+b logical_or(a,b) ~aTrue-a logical_not(a) I somewhat

Re: [Numpy-discussion] Transparently reading complex arrays from netcdf4

. The later is generally a good practice when > writing library code, anyways, to catch unusual ndarray subclasses like > np.matrix. > > Stephan > > > On Sat, Mar 29, 2014 at 8:42 PM, G Jones wrote: > >> Hi Stephan, >> Thanks for the reply. I was thinking of somethin

Re: [Numpy-discussion] Transparently reading complex arrays from netcdf4

> need will be read from disk and converted on the fly. > > Hope this helps! > > Cheers, > Stephan > > > > > On Sat, Mar 29, 2014 at 6:13 PM, G Jones wrote: > >> Hi, >> I am using netCDF4 to store complex data using the recommended strategy >

[Numpy-discussion] Transparently reading complex arrays from netcdf4

Hi, I am using netCDF4 to store complex data using the recommended strategy of creating a compound data type with the real and imaginary parts. This all works well, but reading the data into a numpy array is a bit clumsy. Typically I do: nc = netCDF4.Dataset('my.nc') cplx_data = nc.groups['mygrou

Re: [Numpy-discussion] Default builds of OpenBLAS development branch are now fork safe

On 3/28/2014 10:54 AM, Sturla Molden wrote: > Eigen has a licensing issue as well, unfortunately, MPL2. > > E.g. it requires recipients to be informed of the MPL requirements (cf. > impossible with pip install numpy). Eigen chose MPL2 with the intent that Eigen be usable by "all projects". http:/

Re: [Numpy-discussion] NumPy-Discussion Digest, Vol 90, Issue 83

On 3/25/2014 5:13 PM, Colin J. Williams wrote: > avoid the use of an additional operator which would only be used with numpy. http://legacy.python.org/dev/peps/pep-0465/#but-isn-t-matrix-multiplication-a-pretty-niche-requirement Alan Isaac ___ NumPy-Di

Re: [Numpy-discussion] why sort does not accept a key?

On 3/24/2014 1:41 PM, Charles R Harris wrote: > For float types you would need to use the negative. Yes, that's all I could come up with. So ... shd `sort` have a `reverse` option, like Python's builtin? Alan ___ NumPy-Discussion mailing list NumPy-Di

Re: [Numpy-discussion] why sort does not accept a key?

> On Mon, Mar 24, 2014 at 12:08 PM, Alan G Isaac >> what is the preferred idiom for a descending sort? On 3/24/2014 12:13 PM, josef.p...@gmail.com wrote: > adding [::-1] just creates a new view, pretty low cost. I meant when you need to sort on a key (another vector). Curren

Re: [Numpy-discussion] why sort does not accept a key?

> On Mon, Mar 24, 2014 at 11:32 AM, Alan G Isaac wrote: >> I'm wondering if `sort` intentionally does not accept >> a `key` >> or if this is just a missing feature? On 3/24/2014 11:47 AM, Alexander Belopolsky wrote: > It would be very inefficient to c

[Numpy-discussion] why sort does not accept a key?

I'm wondering if `sort` intentially does not accept a `key` or if this is just a missing feature? (I suppose that if the `order` argument is specified it would have to accept a sequence of keys ...) Thanks, Alan Isaac ___ NumPy-Discussion mailing list Nu

  1   2   3   4   5   6   7   8   >