David Huard wrote:
> I don't know how far we can disgress from the reST syntax using
> those plugins, but it's probably something worth looking at.
Digression => maintenance burden.
Cheers,
Alan Isaac
___
Numpy-discussion
=4.0, a5=5.0)
>>> A
{'a1': 2.0, 'a3': 3.0, 'a2': 4.0, 'a5': 5.0, 'a4': 4.0}
>>> str(A)
"{'a1': 2.0, 'a3': 3.0, 'a2': 4.0, 'a5': 5.0, 'a4': 4.0}"
If not, ju
rough a matrix
is rows as matrices? That has never
been what I wanted.
Thank you,
Alan Isaac
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
ent".
And since nobody appears to agree, I should shut up.
This will be my last post on this subject.
Cheers,
Alan Isaac
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
> On 3/27/07, Alan Isaac <[EMAIL PROTECTED]> wrote:
>> May I see a use case where the desired
>> return when iterating through a matrix
>> is rows as matrices? That has never
>> been what I wanted.
On Tue, 27 Mar 2007, Bill Baxter wrote:
> AllMyPoints =
bitten by this long ago.
Now it feels natural enough, I confess.
But then, on reflection, it is an oddity. ;-)
Cheers,
Alan Isaac
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
ile M[i,:] is numpy indexing,
each with its own natural interpretation.
In any case, you may be spending too much
energy on this. I am not a developer, and
no developer has expressed a desire to make
such a change. The current behavior is
currently safe (if odd).
Cheers,
Alan Is
t win an "argument".
Anyway, I understand that I am being perceived as
bull-headed here, so I'll let this go. Thanks for your
attempt to help me see the virtues of the current design.
Cheers,
Alan Isaac
___
Numpy-discussion mailing lis
On Wed, 28 Mar 2007, Stefan van der Walt wrote:
> Matrices strike me as a bit of an anomaly. I would expect
> an N-dimensional container to contain (N-1)-dimensional
> objects.
Yes indeed.
Cheers,
Alan Isaac
___
Numpy-discussion mai
> argmin
Just a reminder that there exist a very useful example list
http://www.scipy.org/Numpy_Example_List#argmin
and a wonderful reference:
http://www.tramy.us/
Cheers,
Alan Isaac
___
Numpy-discussion mailing list
[EMAIL PROTECTED]
http://proje
nals too.
Would using language from the Scheme report be useful when
discussing this?
http://www-swiss.ai.mit.edu/projects/scheme/documentation/scheme_5.html
Cheers,
Alan Isaac
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://pro
"equivalent" 2-d arrays).
If I understand, unary complementation (using `-`) will be lost:
so there will be no operator for unary complementation.
(You might say, what about `~`, which currently works, but
if we are to match Python's be
RY HELPFUL!!!
Thanks!
Alan Isaac
PS Just a warning to others in my position:
students using VISTA are reporting install difficulties
for Python 2.5.1. It sounds like a fix is to proceed as at
http://www.sephiroth.it/weblog/archives/2006/06/installing_python_msi_on_windo.php>
but as I do not hav
On Fri, 05 Oct 2007, dmitrey wrote:
> I have an array like array([ 1., 0., 2., -10.])
> what is most efficient (i.e. fastest) way to convert the one to array of
> integers?
> array([ 1, 0, 2, -10])
Use ``astype``.
Cheers,
Alan Isaac
>>> import numpy as N
>>
posed name (after `randint` deprecation): `randints`.
Cheers,
Alan Isaac
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
On 2/17/2016 11:46 AM, Robert Kern wrote:
some at least are 1-based indexing, so closed intervals do make sense.
Haskell is 0-indexed.
And quite carefully thought out, imo.
Cheers,
Alan
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
On 2/17/2016 12:28 PM, G Young wrote:
Perhaps, but we are not coding in Haskell. We are coding in Python, and
the standard is that the endpoint is excluded, which renders your point
moot I'm afraid.
I am not sure what "standard" you are talking about.
I thought we were talking about the user
On 2/17/2016 3:42 PM, Robert Kern wrote:
random.randint() was the one big exception, and it was considered a
mistake for that very reason, soft-deprecated in favor of
random.randrange().
randrange also has its detractors:
https://code.activestate.com/lists/python-dev/138358/
and following.
I
e.
http://docs.scipy.org/doc/numpy-1.10.0/reference/generated
/numpy.random.choice.html
fwiw,
Alan Isaac
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
On 2/17/2016 7:01 PM, Juan Nunez-Iglesias wrote:
Notice the limitation "1D array-like".
http://docs.scipy.org/doc/numpy-1.10.0/reference/generated/numpy.random.choice.html
"If an int, the random sample is generated as if a was np.arange(n)&qu
On 2/18/2016 2:44 PM, Robert Kern wrote:
In a new function not named `linspace()`, I think that might be fine. I do
occasionally want to swap between linear and logarithmic/geometric spacing
based on a parameter, so this
doesn't violate the van Rossum Rule of Function Signatures.
Would such
`, would be
the same as `ndarray.transpose(True)`.
Use `dot`. E.g.,
m.dot(a)
hth,
Alan Isaac
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
more keystrokes.
(It's still horribly ugly, though, and I
hope this too is dismissed.)
Alan Isaac
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
is a
perceived need ...
Cheers,
Alan Isaac
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
On 4/8/2016 5:13 PM, Nathaniel Smith wrote:
he doesn't want 2d matrices, he wants
tools that make it easy to work with stacks of 2d matrices stored in
2-or-more-dimensional arrays.
Like `map`?
Alan Isaac
___
NumPy-Discussion mailing list
f the
possible input pairs overflow the type.
My core inclination would be to use (what I understand to be)
the C convention that integer exponentiation always produces
a double, but to support dtype-specific exponentiation with
a function. But this is just a user's perspective.
Cheers,
Yes, I was referring to `pow`,
but I had in mind the C++ version,
which is overloaded:
http://www.cplusplus.com/reference/cmath/pow/
Cheers,
Alan
On 5/20/2016 4:27 PM, Warren Weckesser wrote:
C doesn't have an exponentiation operator. The C math library has pow, powf
and powl, which (like an
("usually") overflow
- a numpy function cd meet specialized exponentiation needs
Thanks,
Alan Isaac
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
On 5/24/2016 1:19 PM, Stephan Hoyer wrote:
the int ** 2 example feels quite compelling to me
Yes, but that one case is trivial: a*a
And at least as compelling is not have a**-2 fail
and not being tricked by say np.arange(10)**10.
The latter is a promise of hidden errors.
Alan
__
?
Having (**) actually work seems worth quite a lot.
Alan Isaac
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
On 5/24/2016 1:41 PM, Matthew Brett wrote:
It's a well-understood promise though - you always have to be careful
of integer overflow.
Of course. But **almost all** cases overflow.
And "well understood" assume a certain sophistication
of the user, while `arange` will certainly be used
by begi
On 5/24/2016 3:57 PM, Eric Moore wrote:
Changing np.arange(10)**3 to have a non-integer dtype seems like a big change.
What about np.arange(100)**5?
Alan Isaac
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org
On 6/4/2016 10:23 PM, Charles R Harris wrote:
From my point of view, backwards compatibility is the main reason for
choosing 1, otherwise I'd pick 2. If it weren't so easy to get
floating point by using floating exponents I'd probably choose
differently.
As an interested user, I offer a summary
On 6/10/2016 2:42 AM, Nathaniel Smith wrote:
I dunno, with my user hat on I'd be incredibly surprised / confused /
annoyed if an innocent-looking expression like
np.arange(10) ** 2
started returning floats... having exact ints is a really nice feature
of Python/numpy as compared to R/Javascri
On 6/10/2016 1:20 PM, Ian Henriksen wrote:
forcing float output for people who actually want integers is not at all ideal
Yes, there definitely should be a function supporting this.
Alan
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
On 6/10/2016 1:20 PM, Allan Haldane wrote:
numpy users have to be aware of
overflow issues in lots of other (simple) cases anyway, eg plain
addition and multiplication.
This is not comparable because *almost all* integer combinations
overflow for exponentiation. See the discussion at
https://
On 6/10/2016 1:34 PM, Nathaniel Smith wrote:
You keep pounding on this example. It's a fine example, but, c'mon. **2 is
probably at least 100x more common in real source code. Maybe 1000x more
common. Why should we break the
common case for your edge case?
It is hardly an "edge case".
Again,
I guess I have one more question; sorry.
Suppose we stipulate that `np.int_(9)**np.int__(10)` should
just overflow, since that appears to be the clear intent of
the (informed) user.
When a Python 3 user writes `np.arange(10)**10`,
how are we to infer the intended type of the output?
(I specify P
nt8(2)**2)
>>> type(np.uint64(2)**np.int8(2))
I don't think anyone has proposed first principles
from which the desirable behavior could be deduced.
I do think reference to the reasoning used by other
languages in making this decision could be helpful.
in advance to anyone who can help me understand better
the issues in play.
Cheers,
Alan Isaac
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
ype('int8')
>>> (np.int64(2**7)*np.arange(5,dtype=np.int8)).dtype
dtype('int16')
fwiw,
Alan Isaac
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
On 6/20/2016 5:59 PM, Nathaniel Smith wrote:
If you have the time to check for existing bug reports about this, and
file a new bug if you don't find one, then it'd be appreciated.
https://github.com/numpy/numpy/issues/7770
Alan
___
NumPy-Discussion
])
if (k not in seen):
result.append(datum)
seen.add(k)
if invert: result.reverse()
return result
Cheers,
Alan Isaac
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy
heers,
Alan Isaac
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
On 8/16/2016 4:06 AM, Ralf Gommers wrote:
The whole enhancement request doesn't look very interesting imho.
Because the functionality is already in NumPy,
or because it is easily user-written?
Alan
___
NumPy-Discussion mailing list
NumPy-Discussion
Is there a numpy equivalent to Mma's CoordinateBounds command?
http://reference.wolfram.com/language/ref/CoordinateBounds.html
Thanks,
Alan Isaac
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/
On 10/7/2016 9:12 PM, Charles R Harris wrote:
*Always return a float *
/Pluses/
* Computational convenience
Is the behavior of C++11 of any relevance to the choice?
http://www.cplusplus.com/reference/cmath/pow/
Alan Isaac
___
NumPy-Discussion
processing module, thus indirectly linking to the data and techniques
(which the X instance may or may not store, as is convenient).
fwiw,
Alan Isaac
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/list
lus anything
that is pure Python.
Cheers,
Alan Isaac
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
On Wed, 27 Feb 2008, Christopher Barker wrote:
> The issue here is a result of what I consider a wart in python's string
> methods -- string.find() returns a valid index( -1 ) when
> it fails to find anything.
Use index instead?
Chee
t; ...
> c = (N.T.sin(b) + N.M.exp(d)) / N.S.mean(g)
I try to think of my students in such an environment.
Frightening.
Alan Isaac
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
t; there in the wild. Maybe we can put it on the list for
> 1.1. I'd like to change numpy polynomials also, but that
> is probably a mod too far.
How about tagging the coefficient order,
so everyone can use these the way they prefer.
Alan Isaac
___
On Wed, 16 Apr 2008, Gael Varoquaux wrote:
> let us pretend A[:, 1] returns a 1D array, as you seem to
> be wanting
Where did I say anything like that??
Please look at the proposal.
It affects **only** scalar indexing
(and thereby iteration).
Recall how emphatically I agreed with you:
Multiple
or "column vector",
this is just short hand for special matrices.
If I want these special matrices, I can have
them right now. Of course I cannot index the
elements with a scalar...
Cheers,
Alan Isaac
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
On Wed, 23 Apr 2008, Sebastian Haase wrote:
> What used to be referred to a the 1.1 version, that can
> break more stuff, to allow for a cleaner design, will now
> be 1.2
So ... fixing x[0][0] for matrices should wait
until 1.2. Is that correct?
Thank you,
A
On Wed, 23 Apr 2008, Stéfan van der Walt wrote:
> Done in r5072.
Much appreciated.
I have updated http://www.scipy.org/MatrixIndexing>
to reflect this change (and its provisional status).
Alan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.
ent.
If you truncate at zero but your mean is at 50 and your
standard deviation is 10, you will hardly notice the
truncation. If your mean is at 14 and the standard
deviation is 10, you will definitely see the truncation.
That's what I understood Rich to be se
57 matches
Mail list logo
