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
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/numpy
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
,
Alan Isaac
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/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
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
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
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
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.
Alan
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
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".
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
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 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
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
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 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
?
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: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
("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
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
of 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,
Alan Isaac
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
NumPy
there is a
perceived need ...
Cheers,
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
`, 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
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
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
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 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
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 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
(after `randint` deprecation): `randints`.
Cheers,
Alan Isaac
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
On Wed, 23 Apr 2008, Stéfan van der Walt wrote:
Done in r5072.
Much appreciated.
I have updated URL:http://www.scipy.org/MatrixIndexing
to reflect this change (and its provisional status).
Alan
___
Numpy-discussion mailing list
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
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
. 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
___
Numpy-discussion
)) / 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
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?
Cheers,
Alan Isaac
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/listinfo/numpy
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
x = N.array([1,2,3],dtype='float
!!!
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
URL:http://www.sephiroth.it/weblog/archives/2006/06/installing_python_msi_on_windo.php
but as I do not have access
, 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 behavior, that is lost too.)
Cheers,
Alan Isaac
___
Numpy
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://projects.scipy.org/mailman/listinfo
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://projects.scipy.org/mailman/listinfo/numpy
[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 Isaac
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 = mat(rand(100,2)) # 100 two-d points
for pt
': 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, just strip out what you do not like.
Cheers,
Alan Isaac
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman
49 matches
Mail list logo
