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 *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/. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
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-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
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 think this is just a bug in the description of the proposal here, not in the proposal itself. So, is the correct phrasing the global RandomState object should use the latest implementation of the methods, unless explicitly seeded? Thanks, Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 version number. This will allow everyone who wants to to change now, without requiring that users attend to minor numpy version numbers if they want replicability. I think this is what is required by semantic versioning. Alan Isaac On 5/24/2015 4:59 AM, Ralf Gommers wrote: the reasoning on this point is shaky. np.random.seed() is *very* widely used, and works fine for a test suite where each test that needs random numbers calls seed(...) and is run with nose. Can you explain why you need to touch the behavior of the global methods in order to make RandomState(version=) work? ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 sets of semantics, and the PEP semantics are better (that's why we chose them), so we should at a minimum warn people who are getting the old behavior I would have to dig around, but I am pretty sure there were explicit statements that `@` would neither be bound by the behavior of `dot` nor expected to be reconciled with it. I agree that where `@` and `dot` differ in behavior, this should be clearly documented. I would hope that the behavior of `dot` would not change. Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 case should be an error). Do I recall incorrectly: I thought that reconciliation of `@` and `dot` was explicitly not part of the project on getting a `@` operator? I do not mean this to speak for or against the change above, which I only moderately oppose, but rather to the argument offered. As for the logic of the current behavior, can it not be given a tensor product motivation? (Otoh, it conflicts with the current behavior of `vdot`.) Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 the plus side, this also means that even if pigs started doing barrel-rolls through hell's winter-vortex-chilled air tomorrow and we simply removed integer fancy indexing, your students would be unaffected:-) Except that they do use statsmodels, which I believe (?) does make use of integer fancy-indexing. Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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; this too will fade away. It is very reasonable to worry that some users will start at the same place but them move in a different direction, and that worry should affect how such proposals are floated and discussed. I am personally grateful that the idea's reception has been so chilly; it's very reassuring. fwiw, Alan On 4/7/2015 9:06 PM, Nathaniel Smith wrote: If a grad student or junior colleague comes to you with an idea where you see some potentially critical flaw, do you yell THAT WILL NEVER WORK and kick them out of your office? Or, do you maybe ask a few leading questions and see where they go? ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/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 non-boolen fancy indexing on multidimensional arrays. (As far as I know.) Are yours? Cheers, Alan On 4/8/2015 3:05 PM, Eric Firing wrote: What sequence of steps might reduce the disconnect between numpy and the rest of the array-handling world? And make it a little friendlier for students? ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 help: http://docs.scipy.org/doc/numpy/reference/generated/numpy.random.uniform.html#numpy.random.uniform Thanks, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[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-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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] 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.linalg.svd.html A lot of core linear algebra is in `numpy.linalg`, and SciPy has much more. Remember for matrix `M` you can always apply any numpy function to `M.A`. I think gains could be in lazy evaluation structures (e.g., a KroneckerProduct object that never actually produces the product unless forced to.) Cheers, Alan ___ 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, I cannot find any way to say MATLAB is nicer. Cheers, Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 operations vs matrix operations? Personally I am puzzled by preserving subtype of `diagonal` and very especially of `ravel`. Has anyone requested this? (I can see the argument for `diag`.) On 1/3/2015 10:32 AM, Charles R Harris wrote: In [1]: from astropy import units as u In [2]: a = eye(2) * u.m In [3]: a Out[3]: Quantity [[ 1., 0.], [ 0., 1.]] m In [4]: diagonal(a) Out[4]: Quantity [ 1., 1.] m In [5]: diag(a) Out[5]: Quantity [ 1., 1.] m In [6]: ravel(a) Out[6]: Quantity [ 1., 0., 0., 1.] m None of those examples keep the units without the recent changes. Thanks for a nice example. It seems that the core principle you are proposing is that design considerations generally require that subtypes determine the return types of numpy functions. If that is correct, then it seems matrices should then be subject to this; more special casing of the behavior of matrix objects seems highly undesirable. Cheers, Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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`. Has anyone requested this? (I can see the argument for `diag`.) Alan Isaac On 1/2/2015 9:04 PM, Charles R Harris wrote: The diag, diagonal, and ravel functions have recently been changed to preserve subtypes. However, this causes lots of backward compatibility problems for matrix users, in particular, scipy.sparse. One possibility for fixing this is to special case matrix and so that these functions continue to return 1-d arrays for matrix instances. This is kind of ugly as `a..ravel` will still return a matrix when a is a matrix, an ugly inconsistency. This may be a case where practicality beats beauty. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[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] 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. (These are square to that is inferrable, but for general binary relations even that is not true.) I'm wondering how others approach this. Thanks, 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.scipy.org/mailman/listinfo/numpy-discussion
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 call `t.__bool__()` it raised an attribute error -- unless one first called `t.__nonzero__()` and then called `t.__bool__()`, which was of course very weird and needed to be fixed. Maybe (?) not like this. In fact the oddity probably remains but moved. in 1.9.0 I see this: np.__version__ '1.9.0' t = np.array(None); t[()] = np.array([None, None]) t.__nonzero__() Traceback (most recent call last): File stdin, line 1, in module AttributeError: 'numpy.ndarray' object has no attribute '__nonzero__' t.__bool__() True t.__nonzero__() ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all() Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import numpy as np np.__version__ '1.9.0' t = np.array(None); t[()] = np.array([None, None]) t.__nonzero__() Traceback (most recent call last): File stdin, line 1, in module AttributeError: 'numpy.ndarray' object has no attribute '__nonzero__' t.__bool__() True t.__nonzero__() ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all() ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 just not understanding the question, but the initial answer I will give is, just like the proposal for `max_rows`. That is, skip_header and skip_footer are honored, and the remainder of the file is sliced. For the equivalent of say `max_rows=500`, one would say `slice_rows=slice(500)`. Perhaps you could provide an example illustrating the issues this reply overlooks. Cheers, Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 random selection for a quick and dirty look at large data sets. Setting maxrows can be very different if the data has been stored in some structured manner. I suppose my view is something like this. We are considering adding a keyword. If we can get greater functionality at about the same cost, why not? In that case, it is not really useful to speculate about use cases. If the costs are substantially greater, then that should be stated. Cost is a good reason not to do something. fwiw, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 be sliced.) I don't recall the specifics at the moment, but I've been happy to have it in the past. Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 much more elegant, and includes an automatic guarantee that the iterations will be in C-contiguous style. Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[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.org/mailman/listinfo/numpy-discussion
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 versatile than an `nrows` keyword for the number of rows would be a rows keyword for a slice argument. fwiw, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 col, and set them appropriately. On 8/6/2014 5:05 PM, Chris Barker wrote: I've thought for ages that if you want to naturally do linear algebra, you need to capture the concept of a row and column vector as distinct from each-other and from (1,n) and (n,1) shape arrays. So: It seems to me that although this it may sound trivial to add two flags, this is a fundamental conceptual change, and I hope it will not go forward without extensive discussion. To aid users like me who might want to think about this, can you please suggest for exploration a language that has adopted this approach. (Ideally, where the decision is considered a good one.) Thank you, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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? And obviously, for any float data type, the mean value of the values in the array is representable as a value of the same type. Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 reduction in float64 and still return a float32. There is nothing implicit in the name `mean` that says we have to just add everything up and divide by the count. My own view is that `mean` would behave enough better if computed as a running mean to justify the speed loss. Naturally similar issues arise for `var` and `std`, etc. See http://www.johndcook.com/standard_deviation.html for some discussion and references. Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 lot like a bug, even if we can readily understand how the algorithm currently used produces it. To say whether it is a bug or not, don't we have to ask about the intent of `mean`? If the intent is to sum and divide, then it is not a bug. If the intent is to produce the mean, then it is a bug. Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 that
the reason why such proposals miss the point is that
there are introductory settings where one would like
to explain as few complications as possible. In
particular, one might prefer *not* to discuss the
existence of a matrix type. As an additional downside,
this is only good for 2d, and there have been proposals
for the new array builder to handle other dimensions.
fwiw,
Alan Isaac
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 6;7 8' (two 2d arrays), but I'm just noting that, not urging that it be implemented. Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[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. The first exists as scipy.optimize.approx_fprime. `approx_fprime` seems to work fine, but I suggest it has the following drawbacks: - it is hard to find (e.g., try doing a Google search on scipy gradient or scipy numerical gradient - related, it is in the wrong location (scipy.optimize) - the signature is odd: (x,f,dx) instead of (f,x,dx) (This matters for ease of recall and for teaching.) In any case, as I understand it, the author's of numdifftools http://code.google.com/p/numdifftools/ expressed willingness to have their code moved into SciPy. This seems like an excellent way forward. There was talk of making this a summer of code project, but that seems to have sputtered. Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[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 with its absence is even better.) Thanks, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 advantage over a boolean mask. I take it that by a lack of a memory advantage you mean because boolean arrays are 8 bit representations. That makes sense. I find it rather more convenient to use boolean arrays, but I wonder if arrays of indexes might have other advantages (which would suggest using the set operations instead). In particular, might a[boolean_array] be slower that a[indexes]? (I'm just asking, not suggesting.) Thanks! Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[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: ab a*b logical_and(a,b) a|b a+b logical_or(a,b) ~aTrue-a logical_not(a) I somewhat expect the last column to be slowest as well as least convenient, since it is built to first convert non-booleans to booleans. Are there other differences? Also, is this made clear anywhere in the docs? Thanks, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[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(a0) and np.flatnonzero(a=0). Can I get them both in one go? Thanks, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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://eigen.tuxfamily.org/index.php?title=Licensing_FAQ If you are correct in your interpretation, it may be worth raising the issue and requesting the needed accommodation. Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[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 NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 call a key function on every element compared during the sort. See np.argsort and np.lexsort for faster alternatives. But the keys could be as in `lexsort`. I am currently using `argsort`, but I can do so because I don't need a lexicographically determined sort order for the indexes. To close with a related question: what is the preferred idiom for a descending sort? Thanks, Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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). Currently I'm just reversing the result of argsort with [::-1] but this changes the sort order (relative to a stable descending sort). Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[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? Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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_power(M,n) instead of M@@n in other teaching settings (e.g., graph theory and recurrence relations). I am certainly not objecting to making `@@` available. It just seems much less important than getting `@` asap. Thanks, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 powers would be useful (for illustrating e.g. graph theory and difference equations), but not enough to delay the PEP. I think NumPy should take the money and run. Getting `@` is great. Let's get experience with it before deciding whether it's worth asking for `@@`. Questions for `@@`: - would it just be `matrix_power`, with all the restrictions? - or would `a(10,2,2)@@-1` return an array of matrix inverses? - etc In the end, I'd like to see a functional implementation before deciding on `@@`, but I would not like to see `@` delayed at all. Congratulations, Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 broadcasting the 2d behavior) 1d (special casing) 0d (error) In this context I see one serious problem: is there a NumPy function that produces the proposed nd behavior? If not why not, and can it really be sold as a core need if the need to implement it has never been pressed to the point of an implementation? Unless this behavior is first implemented, the obvious question remains: why will `@` not just implement `dot`, for which there is a well tested and much used implementation? Note I am not taking a position on the semantics. I'm just pointing out a question that is sure to arise. Cheers, Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[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 http://mail.scipy.org/mailman/listinfo/numpy-discussion
[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-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[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=k` option. Is such an option worth suggesting? Thanks, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 ndim2 or ndim1. 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 multiplication PEP. On Sat, Feb 22, 2014 at 7:09 PM, Pauli Virtanen wrote: I'm not sure it's necessary to say much about this in the PEP. It should in my view concentrate on arguing why the new binop is needed in the Python language, and for that, restricting to 2D is good enough IMHO. How exactly Numpy makes use of the capability for 2-dim arrays is something that should definitely be discussed. But I think this is a problem mainly interesting for Numpy devs, and not for CPython devs. On 2/24/2014 12:21 AM, Nathaniel Smith wrote: I actually disagree strongly. I think it's very important to make clear that we have a clear, well thought through, and cross-project approach to what @ is supposed to mean I think Paul is right. We know `@` is supposed to mean matrix multiply when dealing with conformable 2d arrays. That is the real motivation of the PEP. I cannot see why the PEP itself would need to go beyond that. The behavior of `@` in other cases seems a discussion that should go *much* slower than that of the core of the PEP, which is to get an operator for matrix multiplication. Furthermore, I am not able to understand the principles behind the discussion of how `@` should behave in other cases. I do not think they are being clearly stated. (I have added a comment to the PEP asking for clarification.) To be concrete, if `@` is proposed to behave unlike Mathematica's `Dot` command, I would hope to hear a very clear mathematical motivation for this. (Specifically, I do not understand why `@` would do scalar product.) Otoh, if the proposal is just that `@` should behave just like NumPy's `dot` does, that should be simply stated. Cheers, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[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 asking, is this intentional? (version 1.7.1) Thanks, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 mathematical understanding? - were the motivations for any deviations adequate (e.g., supported by strong use cases)? An example is the discussion of whether scalar multiplication of a matrix should be represented by * or by a new operator (e.g., @). I am personally most comfortable with the idea that a new matrix multiplication operator would not handle scalar multiplication or violate tensor product rules (perhaps I am influenced by Mathematica), but I am not prepared to argue the principles of such choices, and would appreciate hearing from those who are. Thanks, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 https://github.com/numpy/numpy/issues/899, where it is suggested that power promote integers to float. Even when base and exponent are both positive integers? Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 and did not lay out reasons. A strong reason would be e.g. if the matrix object is creating a serious maintenance headache. Eliminating this should be a big enough gain to offset any lost interest in numpy from users of Matlab, GAUSS, IDL etc. from the disappearance of a user-friendly notation. I accept that a numpy matrix has some warts. In the past, I've proposed changes to address these. E.g., https://www.mail-archive.com/numpy-discussion@scipy.org/msg06780.html However these went nowhere, so effectively the status quo was defended. I can live with that. A bit of the notational advantage of the `matrix` object was undercut by the addition of the `dot` method to arrays. If `matrix` is deprecated, I would hope that a matrix-power method would be added. (One that works correctly with boolean arrays and has a short name.) I ideally an inverse method would be added as well (with a short name). I think adding the hermitian transpose as `.H()` already has some support, but I forget its current status. Right now, to give a simple example, students can write a simple projection matrix as `X * (X.T * X).I * X.T` instead of `X.dot(la.inv(X.T.dot(X))).dot(X.T)`. The advantage is obvious and even bigger with more complex expressions. If we were to get `.I` for matrix inverse of an array (which I expect to be vociferously resisted) it would be `X.dot(X.T.dot(X).I).dot(X.T)` which at the moment I'm inclined to see as acceptable for teaching. (Not sure.) Just to forestall the usual just start them with arrays, eventually they'll be grateful reply, I would want to hear that suggestion only from someone who has used it successfully with undergraduates in the social sciences. Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 certainly does not offer an equivalent to the notational convenience of numpy's matrix object. As far as I have been able to discern, the underlying motivation for eliminating the matrix class is that some developers want to stop supporting in any form the subclassing of numpy arrays. Do I have that right? So the real question is not about numpy's matrix class, but about whether subclassing will be supported. (If I'm correctly reading the tea leaves.) Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 not like about the `matrix` design is that indexing always returns a matrix. I speculate this is the primary problem you're running into? Thanks, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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. Somewhat related to that last point: could an array grow an `inv` method? (Perhaps returning a pinv for ill conditioned cases.) Here are the primary things that make matrices convenient (particular in a teaching setting): * (partly addressed when `dot` method added) ** (could be partly addressed with an `mpow` method) .I (could be partly addressed with an `inv` method) .H (currently too controversial for ndarray) Some might also add the behavior of indexing, but I could only give qualified agreement to that. Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 the background to know how scipy ended up with a sparse matrix object instead of a sparse array object. In any case, it seems like a different question. Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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/listinfo/numpy-discussion
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 of A and B. This makes writing duck typed code impossible when both semantics are in play. I'm just missing the point here; sorry. Why isn't the right approach to require that any object that wants to work with scipy can be called by `asarray` to guarantee the core semantics? (And the matrix object passes this test.) For some objects we can agree that `asarray` will coerce them. (E.g., lists.) I just do not see why scipy should care about the semantics an object uses for interacting with other objects of the same type. Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 responding to it. (I might be wrong.) What is a duck? If you ask it to quack, it quacks. OK, but what is it to quack? Here, quacking is behaving like an ndarray (in your view, as I understand it) when asked. But how do we ask? Your view (if I understand) is we ask via the operations supported by ndarrays. But maybe that is the wrong way for the library to ask this question. If so, then scipy libraries could ask an object to behave like an an ndarray by calling, e.g., __asarray__ on it. It becomes the responsibility of the object to return something appropriate when __asarray__ is called. Objects that know how to do this will provide __asarray__ and respond appropriately. Other types can be coerced if that is the documented behavior (e.g., lists). The libraries will then be written for a single type of behavior. What it means to quack is pretty easily documented, and a matrix object already knows how (e.g., m.A). Presumably in this scenario __asarray__ would return an object that behaves like an ndarray and a converter for turning the final result into the desired object type (e.g., into a `matrix` if necessary). Hope that clearer, even if it proves a terrible idea. Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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. On the other hand, it really needs to be deprecated. Let's deprecate ``numpy.matrix``. I understand that numpy.matrix will not be deprecated any time soon, but I hope this will register as a vote to help nudge its deprecation closer to the realm of acceptable discussion. I believe you will want to see the archived discussions of this controversial issue before broaching it again, and then when you do so, broach it in terms of the points that have been raised **in great detail** in the past. fwiw, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 (which this affects not at all).
Cheers,
Alan
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
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[key(item)].append(item) return groups print groupby(range(20), lambda x: x%2) ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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.html Perhaps the implicit reference to SQL justifies the name... Sorry if this seems off topic, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[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 appropriate to have a keyword argument to both specifying whether the parameter order is to be modern or traditional (in both polyfits and polyvals)? fwiw, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Deprecate boolean math operators?
On Thu, Dec 5, 2013 at 8:05 PM, Alan G Isaac alan.is...@gmail.com 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, Nathaniel Smith wrote: Interesting point! I had assumed that dot() just upcast! But what do you think about the inconsistency between sum() and dot() on bool arrays? I don't like the behavior of sum on bool arrays. (I.e., automatic upcasting.) But I do not suggest changing it, as much code is likely to depend on it. Cheers, Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 of the minus sign, I don't have one at hand, but a quick Google seach comes up with: http://www.csee.umbc.edu/~artola/fall02/BooleanAlgebra.ppt It is more common to use a superscript `c`, but that's just a notational issue. For multiplication, addition, and dot, you can see Ki Hang Kim's Boolean matrix Theory and Applications. Applications are endless and include graph theory and (then naturally) circuit design. Cheers, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 the `-`. I see it does the subtraction and then a boolean conversion, which is not helpful. Or rather, I do not see how it can be helpful. Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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.org/mailman/listinfo/numpy-discussion
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-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 I cannot be the only one who has for years taught students about Boolean matrices using NumPy, because of this correct behavior of this dtype. (By correct, I mean in conformance with the literature.) Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 algorithm - Only the rows where the sum is 1 must be kept This is not nearly enough information. But since it is all you offer, here is an answer for a square matrix with parameter n: np.identity(n) Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 1.7.1 compiled with Visual Studio compilers and Intel's MKL). Not sure if you want other (not Win 8) reports related to this, but ... I'm appending (no runtime errors) below. The OS is Win 7 (64bit). Alan Isaac Enthought Python Distribution -- www.enthought.com Version: 7.3-2 (32-bit) Python 2.7.3 |EPD 7.3-2 (32-bit)| (default, Apr 12 2012, 14:30:37) [MSC v.1500 3 2 bit (Intel)] on win32 Type credits, demo or enthought for more information. import numpy as np np.__version__ '1.7.1' data = np.array([-0.375, -0.25, 0.0]) s = np.log(data) ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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, which is much less disruptive. I'm not arguing for either of those choices, but it seems to me that the right way to bring this forward to to recall the original motivation for having them and ask if that motivation has fallen apart. I believe that the original motivation for providing the financial functions was to complete the sense that Python users could turn to NumPy whenever they might turn to a calculator: http://mail.scipy.org/pipermail/numpy-discussion/2008-April/032422.html Behind this, I believe, was a desire to draw new users to NumPy. The request for simple financial functions does arise, and people do get pointed to NumPy for this. This seems to me to be a benefit to the NumPy community, although a small one. I'm getting the feeling that some of the opposition to the financial functions is purely aesthetic. (What are *these* doing here??) It seems to me that a request for comments would be more useful if it tried to lay out the perceived costs and benefits to this change. One cost that has been clearly stated is namespace pollution. That seems pretty small to me, but in any case would be fully addressed by making these available as numpy.financial. Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[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] 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. Imo, a question arises: is there any way that NumPy (or the statsmodels gang, for that matter) should influence or participate in this PEP? Alan ___ 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 rather wait for that. My assessment of the conversation so far: there is not adequate support for a .H attribute until it can be an iterative view. I believe that almost everyone (possibly not Josef) would accept or want a .H attribute if it could provide an iterative view. (Is that correct?) So I'll drop out of the conversation, but I hope the user interest that has been displayed stimulates interest in that feature request. Thanks to everyone who shared their perspective on this issue. And my apologies to those (e.g., Dag) whom I annoyed by being too bullheaded. Cheers, Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 the decision, I would suggest A.ct(). But, it this really necessary? An obvious path is to introduce A.H now, document that it makes a copy, and document that it may eventually produce an iterative view. Think how much nicer things would be evolving if diagonal had been implemented as an attribute with documentation that it would eventually be a writable view. Isn't there some analogy with this situation? Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 emphasized - inconsistency with convention that for arrays instance attributes should return views Is this a correct summary? If it is correct, I believe the proponents' case is stronger. All the considerations are valid, so it is a matter of deciding how to weight them. The alternative of offering a new method seems inferior in terms of readability and consistency, and it is not adequately forward looking. If the alternative is nevertheless chosen, I suggest that it should definitely *not* be .H(), both because of the conflict with uses by matrix and masked array, and because I expect that eventually the desire for an attribute will win the day, and it would be a shame for the obvious notation to be lost. 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/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, this would be true for .H when the time comes. Naturally, this would be documented (that it may change to a view). Just as it is documented with ``diagonal``. But it is nevertheless forward looking in an obvious sense: it provides access to an extremely convenient and much more readable notation that will in any case eventually be available. Also, the current context is the matrices and masked arrays have this attribute, so this transitional issue already exists. Out of curiosity: do you use NumPy to work with complex arrays? Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 pretty loud. Indeed, the reason I started this thread is that I'm using the matrix object less and less, and I definitely miss the .H attribute it offers. In any case, need is the wrong criterion. The question is, do the gains in readability, consistency (across objects), convenience, and advertising appeal (e.g., to those used to other languages) outweigh the costs? It's a cost benefit analysis. Obviously some people think the costs outweigh the benefits and others say they do not. We should look for a ways to determine which group has the better case. This discussion has made me much more inclined to believe it is a good idea to add this attribute. I agree that it would be an even better idea to add it as an iterative view, but nobody seems to feel that can happen quickly. Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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) - consistency with matrix and masked array - forward looking (to a future when .H can be a view) in the following sense: it gives access now to the conjugate transpose via .H, which is likely to be implemented in the future, so as long as we document (as with ``diagonal``) that this may change, it gives a large chunk of the desired benefit now. The opponents have primarily emphasized - inconsistency with convention that for arrays instance attributes should return views - NOT forward looking (to a future when .H can be a view) in the following sense: it gives access now to the conjugate transpose via .H but NOT as a view, which is likely to be the preferred implementation in the future, and if the implementation changes in this preferred way then code that relied on behavior rather than documentation will break Finally, I think (?) everyone (proponents and opponents) would be happy if .H could provide access to an iterative view of the conjugate transpose. (Any objections?) Better? Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] add .H attribute?
On 7/22/2013 3:10 PM, Nathaniel Smith wrote: Having .T but not .H is an example of this split. Hate to do this but ... Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. How much is the split a rule or just a convention, and is there enough practicality here to beat the purity of the split? Note: this is not a rhetorical question. However: if you propose A.conjugate().transpose() as providing a teachable moment about why to use NumPy instead of A' in Matlab, I conclude you do not ever teach most of my students. The real world matters. Since practicality beats purity, we do have A.conj().T, which is better but still not as readable as A.H would be. Or even A.H(), should that satisfy your objections (and still provide a teachable moment). Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] azip
I'm floating this thought even though it is not fleshed out. On occasion, I run into the following problem: I have a rectangular array A to which I want to append a (probably) one dimensional vector b to make [A|b]. Of course this can be done as np.hstack((x,b[:,None])) (or obscurely np.r_['1,2,0',x,b]), but this has the following issues: - what if ``b`` turns out to be a list? - what if ``b`` turns out to be 2d (e.g., a column vector)? - it's a bit ugly - it is not obvious when read by others (e.g., students) (The last is a key motivation for me to talk about this.) All of which leads me to wonder if there might be profit in a numpy.azip function that takes as arguments - a tuple of arraylike iterables - an axis along which to concatenate (say, like r_ does) iterated items To make that a little clearer (but not to provide a suggested implementation), it might behave something like def azip(alst, axis=1): results = [] for tpl in zip(*alst): results.append(np.r_[tpl]) return np.rollaxis(np.array(results), axis-1) Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] azip
On 7/18/2013 1:03 PM, Robert Kern wrote: np.column_stack([x, b]) does everything you need. So it does. It's not referenced from the hstack or concatenate documentation. Thanks! Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] azip
On 7/18/2013 1:03 PM, Robert Kern wrote: np.column_stack([x, b]) does everything you need. I am curious: why is column_stack in numpy/lib/shape_base.py while hstack and vstack are in numpy/core/shape_base.py ? Thanks, Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
