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] 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

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

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

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] 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

[Numpy-discussion] unique return_index order?

The documentation of numpy.unique http://docs.scipy.org/doc/numpy/reference/generated/numpy.unique.html does not seem to promise that return_index=True will always index the *first* occurrence of each unique item, which I believe is the current behavior. A promise would be nice. Is it intended? A

Re: [Numpy-discussion] [RFC] should we argue for a matrix power operator, @@?

On 3/15/2014 10:12 PM, Nathaniel Smith wrote: > So to be clear, even if numpy.matrix is going away, and even if > ndarray isn't getting a .I attribute, then you're just as happy > typing/teaching inv(X) as X @@ -1? Yes, that is correct. I am somewhat more unhappy with having to use npla.matrix

Re: [Numpy-discussion] [RFC] should we argue for a matrix power operator, @@?

On 3/15/2014 12:32 AM, Nathaniel Smith wrote: > I know you were worried > about losing the .I attribute on matrices if switching to ndarrays for > teaching -- given that ndarray will probably not get a .I attribute, > how much would the existence of @@ -1 affect you? Not much. Positive integer p

Re: [Numpy-discussion] Matrix multiplication infix operator PEP nearly ready to go

On 3/12/2014 6:04 PM, Nathaniel Smith wrote: >https://github.com/numpy/numpy/pull/4351 The Semantics section still begins with 0d, then 2d, then 1d, then nd. Given the context of the proposal, the order should be: 2d (the core need expressed in the proposal) nd (which generalizes via broadca

[Numpy-discussion] invert bincounts?

I have a bincount array `cts`. I'd like to produce any one array `a` such that `cts==np.bincounts(a)`. Easy to do in a loop, but does NumPy offer a better (i.e., faster) way? Thanks, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org

[Numpy-discussion] shortcut nonzero?

Is there a shortcut version for finding the first (k) instance(s) of nonzero entries? I'm thinking of Matlab's `find(X,k)`: http://www.mathworks.com/help/matlab/ref/find.html Easy enough to write of course. I thought `flatnonzero` would be the obvious place for this, but it does not have a `first

[Numpy-discussion] numpy.random.geometric is shifted

Just got momentarily snagged by not checking the excellent documentation, which clearly says that numpy provides the shifted geometric. I'm wondering why? Who else does? (Not Mathematica, Matlab, Maple, or Octave.) Thanks, Alan Isaac ___ NumPy-Discussi

[Numpy-discussion] flatnonzero fails with lists

I was surprised that `flatnonzero` fails with lists because it calls the `ravel` method, which they do not have, instead of using the `ravel` function. I do not know that there is any policy that NumPy functions should always work on lists, but I have gotten used to them doing so. So I'm just aski

Re: [Numpy-discussion] How exactly ought 'dot' to work?

>> 23.02.2014 00:03, Nathaniel Smith kirjoitti: >>> Currently numpy's 'dot' acts a bit weird for ndim>2 or ndim<1. In >>> practice this doesn't usually matter much, because these are very >>> rarely used. But, I would like to nail down the behaviour so we can >>> say something precise in the matrix

Re: [Numpy-discussion] How exactly ought 'dot' to work?

It would help me follow this discussion if it were broken up into pieces: - what is being asserted as first principles for `dot` (e.g., what mathematical understanding)? - to what extent do other important implementations (e.g., Mathematica and Julia) deviate from the proposed mathematica

Re: [Numpy-discussion] Proposal to make power return float, and other such things.

On 2/17/2014 8:13 PM, Charles R Harris wrote: > This is apropos issue #899 , where > it is suggested that power promote integers to float. Even when base and exponent are both positive integers? Alan Isaac __

Re: [Numpy-discussion] deprecate numpy.matrix

On 2/11/2014 5:25 AM, Pauli Virtanen wrote: > the ndarray is also lacking some useful things, as > you point out. But I think the right solution would be to stuff > the required additions into ndarray, rather than retaining the > otherwise incompatible np.matrix as a crutch. Given that we now h

Re: [Numpy-discussion] deprecate numpy.matrix

On 2/10/2014 7:39 PM, Pauli Virtanen wrote: > The issue here is semantics for basic linear algebra operations, such as > matrix multiplication, that work for different matrix objects, including > ndarrays. I'll see if I can restate my suggestion in another way, because I do not feel you are respo

Re: [Numpy-discussion] deprecate numpy.matrix

On 2/10/2014 5:11 PM, Pauli Virtanen wrote: > The existence of np.matrix messes up the general agreement on ndarray > semantics in Python. The meaning of very basic code such as > > A * B > A.sum(0) > A[0] > > where A and B are NxN matrices of some sort now depends on the types >

Re: [Numpy-discussion] deprecate numpy.matrix

On 2/10/2014 4:40 PM, alex wrote: > I really want to remove it Can you articulate the problem created by its existence that leads you to this view? Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/l

Re: [Numpy-discussion] deprecate numpy.matrix

On 2/10/2014 4:28 PM, Pauli Virtanen wrote: > Starting with asarray won't work: sparse matrices are not subclasses > of ndarray. I was focused on the `matrix` object. For this object, an initial asarray is all it takes to use array code. (Or ... not?) And it is a view, not a copy. I don't have

Re: [Numpy-discussion] deprecate numpy.matrix

On 2/10/2014 4:08 PM, Matthew Brett wrote: > I think the active questions here are: > * Should we collect the discussion in coherent form somewhere? > * Should we add something to the np.matrix docstring and if so what? > * (Pauli's point): to what extent should we try to emulate the np.matrix API.

Re: [Numpy-discussion] deprecate numpy.matrix

On 2/10/2014 4:03 PM, Pauli Virtanen wrote: > What sparked this discussion (on Github) is that it is not possible to > write duck-typed code that works correctly for: Do you mean one must start out with an 'asarray'? Or more than that? As I detailed in past discussion, the one thing I really do n

Re: [Numpy-discussion] deprecate numpy.matrix

On 2/10/2014 3:04 PM, Matthew Brett wrote: > I teach psychologists and neuroscientists mainly I must suspect that notebook was not for **undergraduate** psychology students. At least, not the ones I usually meet. SymPy is great but for those without background it is at best awkward. It certainl

Re: [Numpy-discussion] deprecate numpy.matrix

On 2/9/2014 5:55 PM, alex wrote: > I'm working on the same kinds of problems in scipy development > (functions involving sparse matrices and abstract linear operators) And how is numpy's matrix object getting in your way? Your initial post simply treated the desirability of deprecation as a given

Re: [Numpy-discussion] deprecate numpy.matrix

On 2/9/2014 4:59 PM, alex wrote: > """ > The ``numpy.matrix`` API provides a low barrier to using Python > for linear algebra, just as the pre-3 Python ``input`` function > and ``print`` statement provided low barriers to using Python for > automatically evaluating input and for printing output. >

Re: [Numpy-discussion] create numerical arrays from strings

On 2/6/2014 6:03 PM, David Goldsmith wrote: > So the substance of the utility function Stefan suggests is one line: It's even easier than that: np.mat('1 2;3 4').A However the context is the introduction of the language to students who have no programming experience, not my personal convenience (

[Numpy-discussion] create numerical arrays from strings

NumPy matrix construction includes as a convenience feature the construction of matrices with a Matlab-like syntax. E.g., np.mat('1 2;3 4'). Is it correct that this syntax is not supported for direct (i.e., not using `mat`) ndarray creation? You may ask, where would this possibly matter? The answ

Re: [Numpy-discussion] Numpy Enhancement Proposal: group_by functionality

My comment is just on the name. I'd expect something named `groupby` to behave essentially like Mathematica's `GatherBy` command. http://reference.wolfram.com/mathematica/ref/GatherBy.html I think you are after something more like Matlab's grpstats: http://www.mathworks.com/help/stats/grpstats.htm

Re: [Numpy-discussion] Numpy Enhancement Proposal: group_by functionality

On 1/26/2014 12:02 PM, Stéfan van der Walt wrote: > what would the output of > > ``group_by((key1, key2))`` I'd expect something named "groupby" to behave as below. Alan def groupby(seq, key): from collections import defaultdict groups = defaultdict(list) for item in seq: groups[

[Numpy-discussion] polyfit

For teaching it is certainly nice to have numpy.polynomial.polynomial.polyfit providing modern (vs. traditional) parameter order, but - it is rather buried - np.polyfit uses traditional order and has the same name I recall there was some controversy (?) over all of this, but might it not be appro

Re: [Numpy-discussion] Deprecate boolean math operators?

On 12/6/2013 3:50 PM, Sebastian Berg wrote: > Both of these are currently not defined, they will just cause upcast to > int8. What does currently mean? `**` works fine for boolean arrays in 1.7.1. (It's useless, but it works.) Alan Isaac ___ NumPy-Dis

Re: [Numpy-discussion] Deprecate boolean math operators?

On 12/6/2013 3:30 PM, josef.p...@gmail.com wrote: > 6 `**` follows from 1. Yes, but what really matters is that linalg.matrix_power give the correct (boolean) result. Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.

Re: [Numpy-discussion] Deprecate boolean math operators?

On 12/6/2013 1:35 PM, josef.p...@gmail.com wrote: > unary versus binary minus Oh right; I consider binary `-` broken for Boolean arrays. (Sorry Alexander; I did not see your entire issue.) > I'd rather write ~ than unary - if that's what it is. I agree. So I have no objection to elimination of

Re: [Numpy-discussion] Deprecate boolean math operators?

>> On 12/5/2013 11:14 PM, Alexander Belopolsky wrote: >>> did you find minus to be as useful? > On Fri, Dec 6, 2013 at 11:13 AM, Alan G Isaac >> It is also a correct usage. On 12/6/2013 12:23 PM, Alexander Belopolsky wrote: > Can you provide a reference? For use

Re: [Numpy-discussion] Deprecate boolean math operators?

On 12/6/2013 12:23 PM, Alexander Belopolsky wrote: > What is the rationale for this: > > >>> -array(True) + array(True) > True The minus is complementation. So you are just writing False or True Alan Isaac ___ NumPy-Discussion mailing list Nu

Re: [Numpy-discussion] Deprecate boolean math operators?

On 12/5/2013 11:14 PM, Alexander Belopolsky wrote: > did you find minus to be as useful? It is also a correct usage. I think a good approach to this is to first realize that there were good reasons for the current behavior. Alan Isaac ___ NumPy-Discu

Re: [Numpy-discussion] Deprecate boolean math operators?

> On Thu, Dec 5, 2013 at 8:05 PM, Alan G Isaac > wrote: >> For + and * (and thus `dot`), this will "fix" something that is not broken. >> It is in fact in conformance with a large literature on boolean arrays >> and boolean matrices. On 12/6/2013 3:24 AM, Na

Re: [Numpy-discussion] Deprecate boolean math operators?

For + and * (and thus `dot`), this will "fix" something that is not broken. It is in fact in conformance with a large literature on boolean arrays and boolean matrices. That not everyone pays attention to this literature does not constitute a reason to break the extant, correct behavior. I'm sure

Re: [Numpy-discussion] Numpy newbie question: matrix creation

On 9/25/2013 3:06 AM, Edmondo Porcu wrote: > advice on how to create a matrix with certain characteristics : > - Every entry should be minimum 0 maximum 1 with a step of 0.1 (legal > values are 0,0.1,0.2,0.3 etc) > - The number of columns of the matrix is a parameter of this matrix creation > a

Re: [Numpy-discussion] Relative speed

On 8/29/2013 3:48 PM, Ralf Gommers wrote: > Some context would have helped. http://www.youtube.com/watch?v=y2R3FvS4xr4 fwiw, Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Warnings not raised by np.log in 32 bit build on Windows

On 8/22/2013 10:32 PM, Warren Weckesser wrote: > Christoph > reported that this code: > > ``` > import numpy as np > > data = np.array([-0.375, -0.25, 0.0]) > s = np.log(data) > ``` > > does not generate two RuntimeWarnings when it is run with numpy 1.7.1 > in a 32 bit Windows 8 environment (numpy

Re: [Numpy-discussion] Deprecation of financial routines

On 8/19/2013 2:37 AM, Juan Luis Cano wrote: > https://github.com/numpy/numpy/issues/2880 > > it was suggested that we deprecate and eventually remove the financial > functions in NumPy It seems that this summary is a bit one-sided. There was also a suggestion to move these into numpy.financial,

Re: [Numpy-discussion] Python PEP 450

Hi Colin, I'm just the messenger. I thought this list might be interested. Feedback should go to Steven D'Aprano on comp.lang.python I think the PEP makes it clear that the target is not secondary students but rather users who want numerically robust versions of some basic statistical procedures

[Numpy-discussion] PEP 450 (stats module for standard library)

http://www.python.org/dev/peps/pep-0450/ https://groups.google.com/forum/#!topic/comp.lang.python/IV-3mobU7L0 Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] add .H attribute?

On 7/24/2013 3:15 AM, Sebastian Haase wrote: > I feel that adding a method > .H() > would be the compromise ! > > Alan, could you live with that ? I feel .H() now would get in the way of a .H attribute later, which some have indicated could be added as an iterative view in a future numpy. I'd ra

Re: [Numpy-discussion] add .H attribute?

On 7/23/2013 6:45 PM, Dag Sverre Seljebotn wrote: > It'd be great if you could try to incorporate it to create a more balanced > overview Attempt 2: I believe that propoents of adding a .H attribute have primarily emphasized - readability (and general ease of use, including in teaching) - cons

Re: [Numpy-discussion] add .H attribute?

On 7/23/2013 5:32 PM, josef.p...@gmail.com wrote: > Do we really need a one letter shorthand for `a.conj().T` ? One way to assess this would be to propose removing it from matrix and masked array objects. If the yelping is loud enough, there is apparently need. I suspect the yelping would be pre

Re: [Numpy-discussion] add .H attribute?

On 7/23/2013 5:08 PM, Dag Sverre Seljebotn wrote: > I disagree with this being forward looking, as it explicitly creates a > situation where code will break if .H becomes a view Well yes, we cannot have everything. Just like it is taking a while for ``diagonal`` to transition to providing a view,

Re: [Numpy-discussion] add .H attribute?

I'm trying to understand the state of this discussion. I believe that propoents of adding a .H attribute have primarily emphasized - readability (and general ease of use) - consistency with matrix and masked array - forward looking (to a future when .H can be a view) The opponents have primarily

Re: [Numpy-discussion] .flat (was: add .H attribute?)

On 7/23/2013 9:09 AM, Pauli Virtanen wrote: > .flat which I think > is rarely used Until ``diagonal`` completes its transition, use of ``flat`` seems the best way to reset the diagonal on an array. Am I wrong? I use it that way all the time. Alan Isaac _

Re: [Numpy-discussion] add .H attribute?

On 7/23/2013 4:36 AM, Dag Sverre Seljebotn wrote: > I'm +1 on another name for a method that does a copy. Which can > eventually be made redundant with A.H.copy(), if somebody ever takes on > the work to make that happen...but at least I think the path to that > should be kept open. If that is th

  1   2   3   4   5   6   7   8   >