headers
Matthew Brett | 1 Nov 06:45
Picon
Gravatar

Re: Recarray comparison and byte order

Hi,

>> c = a.byteswap().newbyteorder()
>> c == a
>
> In the last two lines, a variable "c" is assigned to a modified "a".  The
> next line tests (==) to see if "c" is the same as (==) the unmodified "a".
> It isn't, because "c" is the modified "a".  Hence, "False".

Sorry, I wasn't very clear - the stuff in brackets is what gets echoed
to the terminal, and '==' was deliberate.

The field values in 'a' and 'c' are all equal, so I was expecting what
I got for comparing - for example 'a' to a copy of itself.  Non-record
arrays also behave as I expected after byteswapping:

In [2]: a = np.arange(3, dtype='u2')

In [3]: c = a.byteswap().newbyteorder()

In [4]: a == c
Out[4]: array([ True,  True,  True], dtype=bool)

Best,

Matthew
Permalink | Reply | 0 comments |
headers
Amenity Applewhite | 1 Nov 14:59

November 6 EPD Webinar: How do I... use Envisage for GUIs?


Having trouble viewing this email? Click here

Friday, November 6:
How do I... use Envisage for GUIs?
Dear Leah,

Envisage is a Python-based framework for building extensible applications. The Envisage Core and corresponding Envisage Plugins are components of the Enthought Tool Suite. We've found that Envisage grants us a degree of immediate functionality in our custom applications and have come to rely on the framework in much of our development.

For November's EPD webinar, Corran Webster will show how you can hook together existing Envisage plugins to quickly create a new GUI. We'll also look at how you can easily turn an existing Traits UI interface into an Envisage plugin.

New: Linux-ready webinars!

In order to better serve the Linux-users among our subscribers, we've decided to begin hosting our EPD webinars on WebEx instead of GoToMeeting. This means that our original limit of 35 attendees will be scaled back to 30. As usual, EPD subscribers at a Basic level or above will be guaranteed seats for the event while the general public may add their name to the wait list here. 

EPD Webinar: How do I... use Envisage for GUIs?
Friday, November 6
1pm CDT/6pm UTC
Wait list
We look forward to seeing you Friday! As always, feel free to contact us with questions, concerns, or suggestions for future webinar topics. 

Thanks,

The Enthought Team
QUICK LINKS :::

Enthought, Inc. | 515 Congress Ave. | Suite 2100 | Austin | TX | 78701

_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion <at> scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Permalink | Reply | 0 comments |
headers
Bill Blinn | 1 Nov 19:50
Picon

Single view on multiple arrays

What is the best way to create a view that is composed of sections of many different arrays?

For example, imagine I had
a = np.array(range(0, 12)).reshape(3, 4)
b = np.array(range(12, 24)).reshape(3, 4)
c = np.array(range(24, 36)).reshape(3, 4)

v = multiview((3, 4))
#the idea of the following lines is that the 0th row of v is
#a view on the first row of a. the same would hold true for
#the 1st and 2nd row of v and the 0th rows of b and c, respectively
v[0] = a[0]
v[1] = b[0]
v[2] = c[0]

#change the underlying arrays
a[0, 0] = 50
b[0, 0] = 51
c[0, 0] = 52

#I would want all these assertions to pass because the view
#refers to the rows of a, b and c
assert v[0, 0] == 50
assert v[1, 0] == 51
assert v[2, 0] == 52

Is there any way to do this?

Thanks,
bill

_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion <at> scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Permalink | Reply | 3 comments |
headers
Anne Archibald | 1 Nov 20:09
Picon

Re: Single view on multiple arrays

2009/11/1 Bill Blinn <bblinn <at> gmail.com>:
> What is the best way to create a view that is composed of sections of many
> different arrays?

The short answer is, you can't. Numpy arrays must be located
contiguous blocks of memory, and the elements along any dimension must
be equally spaced. A view is simply another array that references
(some of) the same underlying memory, possibly with different strides.

> For example, imagine I had
> a = np.array(range(0, 12)).reshape(3, 4)
> b = np.array(range(12, 24)).reshape(3, 4)
> c = np.array(range(24, 36)).reshape(3, 4)
>
> v = multiview((3, 4))
> #the idea of the following lines is that the 0th row of v is
> #a view on the first row of a. the same would hold true for
> #the 1st and 2nd row of v and the 0th rows of b and c, respectively
> v[0] = a[0]
> v[1] = b[0]
> v[2] = c[0]
>
> #change the underlying arrays
> a[0, 0] = 50
> b[0, 0] = 51
> c[0, 0] = 52
>
> #I would want all these assertions to pass because the view
> #refers to the rows of a, b and c
> assert v[0, 0] == 50
> assert v[1, 0] == 51
> assert v[2, 0] == 52
>
> Is there any way to do this?

If you need to be able to do this, you're going to have to rearrange
your code somewhat, so that your original arrays are views of parts of
an initial array.

It's worth noting that if what you're worried about is the time it
takes to copy data, you might well be surprised at how cheap data
copying and memory allocation really are. Given that numpy is written
in python, only for really enormous arrays will copying data be
expensive, and allocating memory is really a very cheap operation
(modern malloc()s average something like a few cycles). What's more,
since modern CPUs are so heavily cache-bound, using strided views can
be quite slow, since you end up loading whole 64-byte cache lines for
each 8-byte double you need.

In short, you probably need to rethink your design, but while you're
doing it, don't worry about copying data.

Anne
Permalink | Reply | 1 comment |
headers
Sturla Molden | 1 Nov 22:38
Picon

Re: Single view on multiple arrays

Anne Archibald skrev:
> The short answer is, you can't. 
Not really true. It is possible create an array (sub)class that stores 
memory addresses (pointers) instead of values. It is doable, but I am 
not wasting my time implementing it.

Sturla
Permalink | Reply | 0 comments |
headers
Sturla Molden | 1 Nov 22:56
Picon

Re: Single view on multiple arrays

Bill Blinn skrev:
> v = multiview((3, 4))
> #the idea of the following lines is that the 0th row of v is
> #a view on the first row of a. the same would hold true for
> #the 1st and 2nd row of v and the 0th rows of b and c, respectively
> v[0] = a[0]
This would not even work, becuase a[0] does not return a view array but 
a scalar arrays, which is a different type of numpy objects. To get a 
view,  you will need to:

v = a[0:1] # view of element 0 in a

Also you cannot assign to v[0], as that would trigger a copy as well.

 > v[1] = b[0]
 > v[2] = c[0]

As I mentioned in the answer to Anne, it would take a completely 
different array object. It would need to internally store an array with 
memory addresses. I have not made up my mind if ndarray can be 
subclassed for this, or if it takes a completely different object (e.g. 
similar to numpy.memmap). What it would require is __setitem__ to store 
pointers and __getitem__ to dereference (return an ndarray with values). 
Good look hacking, it is not even difficult, just tedious.

Sturla
Permalink | Reply | 0 comments |
headers
Thomas Robitaille | 2 Nov 02:57
Picon
Gravatar

Random int64 and float64 numbers

Hi,

I'm trying to generate random 64-bit integer values for integers and  
floats using Numpy, within the entire range of valid values for that  
type. To generate random 32-bit floats, I can use:

np.random.uniform(low=np.finfo(np.float32).min,high=np.finfo 
(np.float32).max,size=10)

which gives for example

array([  1.47351436e+37,   9.93620693e+37,   2.22893053e+38,
         -3.33828977e+38,   1.08247781e+37,  -8.37481260e+37,
          2.64176554e+38,  -2.72207226e+37,   2.54790459e+38,
         -2.47883866e+38])

but if I try and use this for 64-bit numbers, i.e.

np.random.uniform(low=np.finfo(np.float64).min,high=np.finfo 
(np.float64).max,size=10)

I get

array([ Inf,  Inf,  Inf,  Inf,  Inf,  Inf,  Inf,  Inf,  Inf,  Inf])

Similarly, for integers, I can successfully generate random 32-bit  
integers:

np.random.random_integers(np.iinfo(np.int32).min,high=np.iinfo 
(np.int32).max,size=10)

which gives

array([-1506183689,   662982379, -1616890435, -1519456789,  1489753527,
         -604311122,  2034533014,   449680073,  -444302414,  
-1924170329])

but am unsuccessful for 64-bit integers, i.e.

np.random.random_integers(np.iinfo(np.int64).min,high=np.iinfo 
(np.int64).max,size=10)

which produces the following error:

OverflowError: long int too large to convert to int

Is this expected behavior, or are these bugs?

Thanks for any help,

Thomas
Permalink | Reply | 34 comments |
headers
David Goldsmith | 2 Nov 02:58
Picon

Ignorance question

I Googled scipy brownian and the top hit was the doc for numpy.random.wald, but said doc has a "tone" that suggests there are more "sophisticated" ways to generate a random Brownian signal? Or is wald indeed SotA?  Thanks!
 
DG
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion <at> scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Permalink | Reply | 5 comments |
headers
Benjamin Deschamps | 2 Nov 03:09
Picon

odd behaviour with basic operations

I am getting strange behaviour with the following code:

Pd = ((numpy.sign(C_02) == 1) * Pd_pos) + ((numpy.sign(C_02) == -1) * Pd_neg)
Ps = ((numpy.sign(C_02) == 1) * Ps_pos) + ((numpy.sign(C_02) == -1) * Ps_neg)

where Pd, Ps, C_02, Pd_pos, Pd_neg, Ps_pos and Ps_neg are all Float32 numpy arrays of the same shape.

The problem is that the first line evaluates correctly (Pd is what it should be), but the second line does not. However, if I run the same line of code manually in IDLE, then it evaluates correctly! In other words, Ps as returned by the function does not match the value that I should get and obtain when entering the exact same code in IDLE.

Basically, (numpy.sign(C_02) == 1) evaluates to either True or False, and multiplying with another array will give either 0 (when false) or the value of the array. The purpose of this code is to compute Pd and Ps without loops, and to take the value from Pd_pos or Ps_pos when C_02 is positive or of Pd_neg and Ps_neg when C_02 is negative. 

Using loops, it looks like this:

for index in numpy.ndindex(ysize, xsize):
    if numpy.sign(C_02[index]) == 1:
        Pd[index] = Pd_pos[index]
        Ps[index] = Ps_pos[index]
    elif numpy.sign(C_02[index]) == -1:
        Pd[index] = Pd_neg[index]
        Ps[index] = Ps_neg[index]

which also works fine, but takes much longer.

Python 2.6.3, IDLE 2.6.1, Numpy 1.3.0, Snow Leopard, the script also uses some GDAL, matplotlib and scipy functions...

Ideas?

Benjamin
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion <at> scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Permalink | Reply | 1 comment |
headers
Robert Kern | 2 Nov 03:19
Picon
Gravatar

Re: odd behaviour with basic operations

On Sun, Nov 1, 2009 at 21:09, Benjamin Deschamps <bdesc100 <at> gmail.com> wrote:
> I am getting strange behaviour with the following code:
> Pd = ((numpy.sign(C_02) == 1) * Pd_pos) + ((numpy.sign(C_02) == -1) *
> Pd_neg)
> Ps = ((numpy.sign(C_02) == 1) * Ps_pos) + ((numpy.sign(C_02) == -1) *
> Ps_neg)
> where Pd, Ps, C_02, Pd_pos, Pd_neg, Ps_pos and Ps_neg are all Float32 numpy
> arrays of the same shape.
> The problem is that the first line evaluates correctly (Pd is what it should
> be), but the second line does not. However, if I run the same line of code
> manually in IDLE, then it evaluates correctly! In other words, Ps as
> returned by the function does not match the value that I should get and
> obtain when entering the exact same code in IDLE.

Please provide a self-contained example that demonstrates the problem.

Also, be aware that where C_02==0, sign(C_02)==0. You will need to
consider what should happen then.

A better way to do what you want is to use where():

Pd = numpy.where(C_02 > 0.0, Pd_pos, Pd_neg)
Ps = numpy.where(C_02 > 0.0, Ps_pos, Ps_neg)

Change the > to >= if you want C_02==0 to use the pos values.

--

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco
Permalink | Reply | 0 comments |

Gmane