Antoine Pitrou wrote:
> When writing C code to interact with buffer-providing objects, you
> usually don't bother with memoryviews at all. You just use a Py_buffer
> structure.
I was taking about "typed memoryviews" which is a Cython abstraction for a
Py_buffer struct. I was not taking about Py
At 01:15 PM 5/24/2016, you wrote:
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?
Interesting, one warning per instantiation (Py2.7):
>>> import numpy
>>> a=numpy.arange(100)**5
:1: Runtime
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/mailm
Yes, I'm fully aware of that. I'm speaking toward changing the default
result dtype. Raising an error for negative exponents is a fine idea.
Changing np.arange(10)**3 to have a non-integer dtype seems like a big
change.
Speaking of this, that some of the integer array operation errors can be
con
On Tue, May 24, 2016 at 10:36 AM, Eric Moore wrote:
> I'd say the most compelling case for it is that is how it has always
worked.
> How much code will break if we make that change? (Or if not break, at
least
> have a change in dtype?) Is that worth it?
The current behavior for arrays is:
# Ret
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 1:36 PM, Eric Moore wrote:
How much code will break if we make that change?
Since even arange(10)**10 is already broken,
there will probably not be much new breakage.
But under any of the new proposals, *something* will break.
So the question is, which shows the most foresight?
H
On Tue, May 24, 2016 at 1:31 PM, Alan Isaac wrote:
> 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
Right, but you'd have to know to change your code when numpy makes
this change. Your code will s
On Tue, May 24, 2016 at 10:31 AM, Alan Isaac wrote:
> Yes, but that one case is trivial: a*a
an_explicit_name ** 2 is much better than an_explicit_name *
an_explicit_name, though.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://ma
I'd say the most compelling case for it is that is how it has always
worked. How much code will break if we make that change? (Or if not break,
at least have a change in dtype?) Is that worth it?
Eric
On Tue, May 24, 2016 at 1:31 PM, Alan Isaac wrote:
> On 5/24/2016 1:19 PM, Stephan Hoyer wro
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
__
On Tue, May 24, 2016 at 9:41 AM, Alan Isaac wrote:
> What exactly is the argument against *always* returning float
> (even for positive integer exponents)?
>
If we were starting over from scratch, I would agree with you, but the int
** 2 example feels quite compelling to me. I would guess there
On 5/24/2016 10:03 AM, Marten van Kerkwijk wrote:
The error on int ** (-int) is OK with me too (even though I prefer just
returning floats).
What exactly is the argument against *always* returning float
(even for positive integer exponents)? Relevant context is:
- int ** int will often ("us
The error on int ** (-int) is OK with me too (even though I prefer just
returning floats).
Having a `floor_pow` function may still be good with this solution too.
-- Marten
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.or
On Thu, 19 May 2016 20:30:40 -0700
Nathaniel Smith wrote:
>
> Given these immutable and contradictory constraints, the last bad
> option IMHO would be that we make int ** (negative int) an error in
> all cases, and the error message can suggest that instead of writing
>
> np.array(2) ** -2
>
On Thu, 12 May 2016 23:14:36 + (UTC)
Sturla Molden wrote:
> Antoine Pitrou wrote:
>
> > Can you define "expensive"?
>
> Slow enough to cause complaints on the Cython mailing list.
What kind of complaints? Please be specific.
> > Buffer acquisition itself only calls a single C callback and
16 matches
Mail list logo