On Sat, Apr 7, 2012 at 8:07 PM, Travis Oliphant wrote:
> If we just announce that there has been some code changes that alter
> corner-case casting rules, I think we can move forward.
>
Sounds good to me.
> We could use a script to document the changes and create a test case which
> would help
If we just announce that there has been some code changes that alter
corner-case casting rules, I think we can move forward.
We could use a script to document the changes and create a test case which
would help people figure out their code.
Please speak up if you have another point of view?
On Fri, Apr 6, 2012 at 3:50 PM, Charles R Harris
wrote:
>
>
> On Fri, Apr 6, 2012 at 3:57 AM, Nathaniel Smith wrote:
>
>> On Fri, Apr 6, 2012 at 7:19 AM, Travis Oliphant
>> wrote:
>> > That is an interesting point of view. I could see that point of
>> view.
>> > But, was this discussed as a
Good morning all-- didn't realize this would generate quite such a buzz.
To answer a direct question, I'm using the github master. A few thoughts (from
a fairly heavy numpy user for numerical simulations and analysis):
The current behavior is confusing and (as far as i can tell) undocumented.
S
On Fri, Apr 6, 2012 at 3:57 AM, Nathaniel Smith wrote:
> On Fri, Apr 6, 2012 at 7:19 AM, Travis Oliphant
> wrote:
> > That is an interesting point of view. I could see that point of view.
> > But, was this discussed as a bug prior to this change occurring?
> >
> > I just heard from a very h
On Fri, Apr 6, 2012 at 7:19 AM, Travis Oliphant wrote:
> That is an interesting point of view. I could see that point of view.
> But, was this discussed as a bug prior to this change occurring?
>
> I just heard from a very heavy user of NumPy that they are nervous about
> upgrading because of
On Fri, Apr 6, 2012 at 12:19 AM, Travis Oliphant wrote:
>
> On Apr 6, 2012, at 1:01 AM, Charles R Harris wrote:
>
>
>
> On Thu, Apr 5, 2012 at 11:57 PM, Travis Oliphant wrote:
>
>> As of 1.5.1 this worked:
>>
>> >>> numpy.__version__
>> 1.5.1
>> >>> numpy.uint64(5) & 3
>> 1L
>>
>>
>> So, this is a
>
> Although 1.5.1 also gives
>
> >>> np.uint(3) + 4
> 7.0
>
> i.e., a float, which certainly doesn't look right either. Whereas
>
> >>> np.int(3) + 4
> 7
>
> The float promotion is still there in 1.6.1
>
> In [4]: uint64(1) + 2
> Out[4]: 3.0
>
> So I suppose there is the larger question is
On Fri, Apr 6, 2012 at 12:01 AM, Charles R Harris wrote:
>
>
> On Thu, Apr 5, 2012 at 11:57 PM, Travis Oliphant wrote:
>
>> As of 1.5.1 this worked:
>>
>> >>> numpy.__version__
>> 1.5.1
>> >>> numpy.uint64(5) & 3
>> 1L
>>
>>
>> So, this is a regression and a bug. It should be fixed so that it
>
On Apr 6, 2012, at 1:01 AM, Charles R Harris wrote:
>
>
> On Thu, Apr 5, 2012 at 11:57 PM, Travis Oliphant wrote:
> As of 1.5.1 this worked:
>
> >>> numpy.__version__
> 1.5.1
> >>> numpy.uint64(5) & 3
> 1L
>
>
> So, this is a regression and a bug. It should be fixed so that it doesn't
>
On Thu, Apr 5, 2012 at 11:57 PM, Travis Oliphant wrote:
> As of 1.5.1 this worked:
>
> >>> numpy.__version__
> 1.5.1
> >>> numpy.uint64(5) & 3
> 1L
>
>
> So, this is a regression and a bug. It should be fixed so that it
> doesn't raise an error. I believe the scalars were special cased so that
As of 1.5.1 this worked:
>>> numpy.__version__
1.5.1
>>> numpy.uint64(5) & 3
1L
So, this is a regression and a bug. It should be fixed so that it doesn't
raise an error. I believe the scalars were special cased so that a raw 3 would
not be interpreted as a signed int when it is clearly uns
On Thu, Apr 5, 2012 at 11:39 PM, Charles R Harris wrote:
>
>
> On Thu, Apr 5, 2012 at 11:16 PM, Travis Oliphant wrote:
>
>> Which version of NumPy are you using. This could be an artefact of the
>> new casting rules.
>>
>> This used to work. So, yes, this is definitely a bug.
>>
>>
> It's beca
On Thu, Apr 5, 2012 at 11:16 PM, Travis Oliphant wrote:
> Which version of NumPy are you using. This could be an artefact of the
> new casting rules.
>
> This used to work. So, yes, this is definitely a bug.
>
>
It's because the '3' is treated as signed, so the uint64 needs to be cast
to someth
Which version of NumPy are you using. This could be an artefact of the new
casting rules.
This used to work. So, yes, this is definitely a bug.
-Travis
On Apr 5, 2012, at 10:54 PM, Chris Laumann wrote:
> Hi all-
>
> I've been trying to use numpy arrays of ints as arrays of bit fields
Hi all-
I've been trying to use numpy arrays of ints as arrays of bit fields and mostly
this works fine. However, it seems that the bitwise_* ufuncs do not support
unsigned integer dtypes:
In [142]: np.uint64(5)&3
---
Type
16 matches
Mail list logo
