headers
Neal Becker | 1 May 20:28
Picon

apply table lookup to each element

Suggestion for efficient way to apply a table lookup to each element of an 
integer array?

import numpy as np
_cos = np.empty ((2**rom_in_bits,), dtype=int)
_sin = np.empty ((2**rom_in_bits,), dtype=int)
for address in xrange (2**12):
    _cos[address] = nint ((2.0**(rom_out_bits-1)-1) * cos (2 * pi * address 
* (2.0**-rom_in_bits)))
    _sin[address] = nint ((2.0**(rom_out_bits-1)-1) * sin (2 * pi * address 
* (2.0**-rom_in_bits)))

Now _cos, _sin are arrays of integers (quantized sin, cos lookup tables)

How to apply _cos lookup to each element of an integer array:

phase = np.array (..., dtype =int)
cos_out = lookup (phase, _cos) ???
Permalink | Reply | 2 comments |
headers
Neal Becker | 1 May 21:02
Picon

Really strange result

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?
Permalink | Reply | 7 comments |
headers
Charles R Harris | 2 May 00:58
Picon

Re: Really strange result



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

_______________________________________________
Numpy-discussion mailing list
Numpy-discussion <at> scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Permalink | Reply | 6 comments |
headers
Neal Becker | 2 May 03:24
Picon

Re: Really strange result

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?
Permalink | Reply | 5 comments |
headers
Charles R Harris | 2 May 03:39
Picon

Re: Really strange result



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?

Chuck


_______________________________________________
Numpy-discussion mailing list
Numpy-discussion <at> scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Permalink | Reply | 4 comments |
headers
Charles R Harris | 2 May 03:40
Picon

Re: Really strange result



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 


_______________________________________________
Numpy-discussion mailing list
Numpy-discussion <at> scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Permalink | Reply | 3 comments |
headers
Neal Becker | 2 May 13:38
Picon

Re: Really strange result

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')
Permalink | Reply | 2 comments |
headers
Matthew Brett | 3 May 06:54
Picon
Gravatar

Structured array with no fields - possible?

Hello,

I'm trying to fix a bug in the scipy matlab loading routines, and this
requires me to somehow represent an empty structured array.

In matlab this is:

>> a = struct()

In numpy, you can do this:

In [1]: dt = np.dtype([])

but then you can't use it:

In [2]: np.zeros((),dtype=dt)
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)

/home/mb312/tmp/≤ipython console> in <module>()

ValueError: Empty data-type

Is there any way of representing a structured / record array, but with
no fields?

Thanks for any thoughts,

Matthew
Permalink | Reply | 503 comments |
headers
David Cournapeau | 3 May 08:22
Picon
Picon

Re: Structured array with no fields - possible?

Hi Matthew,

Matthew Brett wrote:
> Hello,
>
> I'm trying to fix a bug in the scipy matlab loading routines, and this
> requires me to somehow represent an empty structured array.
>   

Do you need the struct to be empty (size is 0) or to have no fields ?
What would you expect np.zeros((), dtype=np.dtype([])) to return, for
example ?

cheers,

David
Permalink | Reply | 502 comments |
headers
David Cournapeau | 3 May 08:49
Picon

Re: Porting strategy for py3k

On Fri, Apr 24, 2009 at 4:49 PM, Dag Sverre Seljebotn
<dagss <at> student.matnat.uio.no> wrote:
> David Cournapeau wrote:
>> Christopher Barker wrote:
>>> Though I'm a bit surprised that that's not how the print function is
>>> written in the first place (maybe it is in py3k -- I'm testing on 2.5)
>>>
>>
>> That's actually how it works as far as I can tell. The thing with
>> removing those print is that we can do it without too much trouble. As
>> long as we cannot actually test any py3k code, warnings from python 2.6
>> is all we can get.
>>
>> I think we should aim at getting "something" which builds and runs (even
>> if does not go further than import stage), so we can gradually port. For
>> now, porting py3k is this huge thing that nobody can work on for say one
>> hour. I would like to make sure we get at that stage, so that many
>> people can take part of it, instead of the currently quite few people
>> who are deeply intimate with numpy.
>
> One thing somebody *could* work on rather independently for some hours
> is proper PEP 3118 support, as that is available in Python 2.6+ as well
> and could be conditionally used on those systems.

Yes, this could be done independently. I am not familiar with PEP
3118; from the python-dev ML, it looks like the current buffer API has
some serious shortcomings, I don't whether this implies to numpy or
not. Do you have more on this ?

Another relatively independent thing is to be able to bootstrap our
build from py3k. At least, distutils and the code for bootstrapping,
so that we can then run 2to3 on the source code from distutils. Not
being able to bootstrap our build process under py3k from distutils
sounds too much of a pain. The only real alternative I could see is to
have two codebases, because 2to3 does not seem able to convert
numpy.distutils 100 % automatically.

David
Permalink | Reply | 3 comments |

Gmane