On Fri, 10 Jun 2016 20:28:30 -0400
Allan Haldane wrote:
>
> Also, I like to think of numpy as having quite C-like behavior, allowing
> you to play with the lowlevel bits and bytes. (I actually wish its
> casting behavior was more C-like). I suspect that people working with
> uint8 arrays might be
On 11/06/2016 02:28, Allan Haldane wrote:
So as an extra twist in this discussion, this means numpy actually
*does* return a float value for an integer power in a few cases:
>>> type( np.uint64(2) ** np.int8(3) )
numpy.float64
Shouldn't that example end up the discussion? I find th
On 6/13/2016 4:47 AM, Antoine Pitrou wrote:
Currently, the choice is simple: if you want an int output,
have an int input; if you want a float output, have a float output.
That is a misunderstanding, which may be influencing the discussion.
Examples of complications:
>>> type(np.int8(2)**2)
On Mon, 13 Jun 2016 10:05:08 -0400
Alan Isaac wrote:
>
> That is a misunderstanding, which may be influencing the discussion.
> Examples of complications:
>
> >>> type(np.int8(2)**2)
>
> >>> type(np.uint64(2)**np.int8(2))
>
The `uint64 x int8 -> float64` is IMHO an abberration in Numpy's
ty
On Mon, Jun 13, 2016 at 10:05 AM, Alan Isaac wrote:
> On 6/13/2016 4:47 AM, Antoine Pitrou wrote:
>
>> Currently, the choice is simple: if you want an int output,
>> have an int input; if you want a float output, have a float output.
>>
>
>
> That is a misunderstanding, which may be influencing t
On Mon, 13 Jun 2016 10:49:44 -0400
josef.p...@gmail.com wrote:
>
> My argument is that `**` is like integer division and sqrt where the domain
> where integer return are the correct numbers is too small to avoid
> headaches by users.
float64 has less integer precision than int64:
>>> math.pow(3,
On Mon, Jun 13, 2016 at 11:25 AM, Antoine Pitrou
wrote:
> On Mon, 13 Jun 2016 10:49:44 -0400
> josef.p...@gmail.com wrote:
> >
> > My argument is that `**` is like integer division and sqrt where the
> domain
> > where integer return are the correct numbers is too small to avoid
> > headaches by
On Mon, Jun 13, 2016 at 11:51 AM, wrote:
>
>
> On Mon, Jun 13, 2016 at 11:25 AM, Antoine Pitrou
> wrote:
>
>> On Mon, 13 Jun 2016 10:49:44 -0400
>> josef.p...@gmail.com wrote:
>> >
>> > My argument is that `**` is like integer division and sqrt where the
>> domain
>> > where integer return are t
On Mon, Jun 13, 2016 at 12:07 PM, wrote:
>
>
> On Mon, Jun 13, 2016 at 11:51 AM, wrote:
>
>>
>>
>> On Mon, Jun 13, 2016 at 11:25 AM, Antoine Pitrou
>> wrote:
>>
>>> On Mon, 13 Jun 2016 10:49:44 -0400
>>> josef.p...@gmail.com wrote:
>>> >
>>> > My argument is that `**` is like integer division a
On 06/13/2016 05:05 AM, V. Armando Solé wrote:
> On 11/06/2016 02:28, Allan Haldane wrote:
>>
>> So as an extra twist in this discussion, this means numpy actually
>> *does* return a float value for an integer power in a few cases:
>>
>> >>> type( np.uint64(2) ** np.int8(3) )
>> numpy.flo
Hi All,
I think we're getting a little off the rails, perhaps because two
questions are being conflated:
1. What in principle is the best return type for int ** int (which Josef I
think most properly rephrased as whether `**` should be thought of as a
float operator, like `/` in python3 and `sqr
On Jun 13, 2016 10:54 AM, "Marten van Kerkwijk"
wrote:
>
> Hi All,
>
> I think we're getting a little off the rails, perhaps because two
questions are being conflated:
>
> 1. What in principle is the best return type for int ** int (which Josef
I think most properly rephrased as whether `**` shou
It was recently pointed out:
https://github.com/numpy/numpy/issues/7730
that this code silently truncates floats:
In [1]: a = np.arange(10)
In [2]: a.dtype
Out[2]: dtype('int64')
In [3]: a[3] = 1.5
In [4]: a[3]
Out[4]: 1
The proposal is that we should deprecate this, and eventually turn it
Personally, I think this is a great idea. +1 to more informative errors.
Best,
Ian Henriksen
On Mon, Jun 13, 2016 at 2:11 PM Nathaniel Smith wrote:
> It was recently pointed out:
>
> https://github.com/numpy/numpy/issues/7730
>
> that this code silently truncates floats:
>
> In [1]: a = np.ara
Hi All,
I'm working on a threaded pipeline where we want the end user to be able
to code up Python functions to do numerical work. Threading is all done
in C++11 and in each thread we've acquired gill before we invoke the
user provided Python callback and release it only when the callback
ret
Hi Burlen,
On Jun 13, 2016 5:24 PM, "Burlen Loring" wrote:
>
> Hi All,
>
> I'm working on a threaded pipeline where we want the end user to be able to
> code up Python functions to do numerical work. Threading is all done in C++11
> and in each thread we've acquired gill before we invoke the us
16 matches
Mail list logo
