[Numpy-discussion] Really strange result

[Neal Becker]

Charles R Harris wrote:

> On Fri, May 1, 2009 at 7:39 PM, Charles R Harris
> <charlesr.harris at gmail.com>wrote:
> 
>>
>>
>> On Fri, May 1, 2009 at 7:24 PM, Neal Becker <ndbecker2 at gmail.com> wrote:
>>
>>> Charles R Harris wrote:
>>>
>>> > On Fri, May 1, 2009 at 1:02 PM, Neal Becker <ndbecker2 at gmail.com>
>>> wrote:
>>> >
>>> >> In [16]: (np.linspace (0, len (x)-1, len(x)).astype
>>> (np.uint64)*2).dtype
>>> >> Out[16]: dtype('uint64')
>>> >>
>>> >> In [17]: (np.linspace (0, len (x)-1, len(x)).astype
>>> (np.uint64)*n).dtype
>>> >> Out[17]: dtype('float64')
>>> >>
>>> >> In [18]: type(n)
>>> >> Out[18]: <type 'int'>
>>> >>
>>> >> Now that's just strange.  What's going on?
>>> >>
>>> >>
>>> > The  n is signed, uint64 is unsigned. So a signed type that can hold
>>> > uint64 is needed. There ain't no such integer, so float64 is used. I
>>> think
>>> > the logic here is a bit goofy myself since float64 doesn't have the
>>> needed
>>> > 64 bit precision and the conversion from int kind to float kind is
>>> > confusing. I think it would be better to raise a NotAvailable error or
>>> > some such. Lest you think this is an isolated oddity, sometimes
>>> > numeric arrays can be converted to object arrays.
>>> >
>>> > Chuck
>>>
>>> I don't think that any type of integer arithmetic should ever be
>>> automatically promoted to float.
>>>
>>> Besides that, what about the first example?  There, I used '2' rather
>>> than
>>> 'n'.  Is not '2' also an int?
>>
>>
>> What version of numpy are you using?
>>
> 
> And what is the value of n?
> 

> Chuck 

np.version.version
Out[5]: '1.3.0'
(I think the previous test was on 1.2.0 and did the same thing)

(np.linspace (0, 1023,1024).astype(np.uint64)*2).dtype
Out[2]: dtype('uint64')

In [3]: n=-7

In [4]: (np.linspace (0, 1023,1024).astype(np.uint64)*n).dtype
Out[4]: dtype('float64')