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
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
___
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
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
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
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
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
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
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;
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
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
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
___
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
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:
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,
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
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
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
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
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
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
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
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.
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
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
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
___
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
___
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
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
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
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
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?
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
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
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
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
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
___
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
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
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
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
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
___
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
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
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
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.
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
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
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
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
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
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
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:
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:
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
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
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
___
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
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
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
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
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
___
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
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
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
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
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,
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
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
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
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
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
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
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,
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
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)
-
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
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
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
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
1 - 100 of 624 matches
Mail list logo
