headers
Christopher Barker | 1 Jan 01:35
Picon
Favicon

Re: Empty strings not empty?

Matthew Brett wrote:
> I think the summary here is 'numpy strings are zero padded; therefore
> you may run into surprises with a string that has trailing zeros'.
> 
> I see why that is - the zero terminator is the only way for numpy
> arrays to see where the end of the string is...

almost -- it's not quite zero-terminated, you can have embedded zeros:

In [35]: np.array('aa\x00bb', dtype='S6')
Out[35]:
array('aa\x00bb',
       dtype='|S6')

-Chris

--

-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker <at> noaa.gov
Permalink | Reply | 0 comments |
headers
Keith Goodman | 1 Jan 21:23
Picon
Gravatar

arrays and __eq__

I have a class that stores some of its data in a numpy array. I can
check for equality when myclass is on the left and an array is on the
right:

>> m = myclass([1,2,3])
>> a = np.asarray([9,2,3])
>>
>> m == a
   myclass([False,  True,  True], dtype=bool)

But I get the wrong answer when an array is on the left and myclass is
on the right:

>> a == m
   array([ True,  True,  True], dtype=bool)

import numpy as np

class myclass(object):

    def __init__(self, arr):
        self.arr = np.asarray(arr)

    def __eq__(self, other):
        if np.isscalar(other) or isinstance(other, np.ndarray):
            x = myclass(self.arr.copy())
            x.arr = x.arr == other
        else:
            raise TypeError, 'This example just tests numpy arrays and
scalars.'
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ernest Adrogué | 2 Jan 00:42
Picon

is it safe to change the dtype without rebuilding the array?

Hi,

I find myself doing this:

In [244]: x
Out[244]: 
array([[0, 1, 2],
       [3, 4, 5],
       [6, 7, 8]])

In [245]: y=x.copy()

In [251]: y.dtype.char
Out[251]: 'l'

In [252]: dt=np.dtype([('a','l'),('b','l'),('c','l')])

In [254]: y.dtype=dt

Is it okay?
The problem is that it's not easy to rebuild the array.
I tried with:

y.astype(dt)
np.array(y, dt)
np.array(y.tolist(), dt)

None worked.

Bye.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Robert Kern | 2 Jan 00:49
Picon
Gravatar

Re: is it safe to change the dtype without rebuilding the array?

2010/1/1 Ernest Adrogué <eadrogue <at> gmx.net>:
> Hi,
>
> I find myself doing this:
>
> In [244]: x
> Out[244]:
> array([[0, 1, 2],
>       [3, 4, 5],
>       [6, 7, 8]])
>
> In [245]: y=x.copy()
>
> In [251]: y.dtype.char
> Out[251]: 'l'
>
> In [252]: dt=np.dtype([('a','l'),('b','l'),('c','l')])
>
> In [254]: y.dtype=dt
>
> Is it okay?
> The problem is that it's not easy to rebuild the array.
> I tried with:
>
> y.astype(dt)
> np.array(y, dt)
> np.array(y.tolist(), dt)
>
> None worked.
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Cournapeau | 2 Jan 08:51
Picon

Re: [SciPy-User] Announcing toydist, improving distribution and packaging situation

On Fri, Jan 1, 2010 at 10:43 PM, Pierre Raybaut <contact <at> pythonxy.com> wrote:
> Hi David,
>
> Following your announcement for the 'toydist' module, I think that
> your project is very promising: this is certainly a great idea and it
> will be very controversial but that's because people expectactions are
> great on this matter (distutils is so disappointing indeed).
>
> Anyway, if I may be useful, I'll gladly contribute to it.
> In time, I could change the whole Python(x,y) packaging system (which
> is currently quite ugly... but easy/quick to manage/maintain) to
> use/promote this new module.

That would be a good way to test toydist on a real, complex package. I
am not familiar at all with python(x,y) internals. Do you have some
explanation I could look at somewhere ?

In the meantime, I will try to clean-up the code to have a first
experimental release.

cheers,

David
Permalink | Reply | 1 comment |
headers
David Cournapeau | 2 Jan 11:18
Picon

Re: [SciPy-dev] Announcing toydist, improving distribution and packaging situation

On Sat, Jan 2, 2010 at 4:58 PM, Gael Varoquaux
<gael.varoquaux <at> normalesup.org> wrote:
> On Sat, Jan 02, 2010 at 11:32:00AM +0900, David Cournapeau wrote:
>> [snip]
>>   - supporting different variants of the same package in the
>> dependency graph at install time
>
>> [snip]
>
>> The second issue is more challenging. It complicates the dependency
>> handling quite a bit, and may cause difficult situations to happen at
>> dependency resolution time. This becomes particularly messy if you mix
>> packages you build yourself with packages grabbed from a repository. I
>> wonder if there is a simpler solution which would give a similar
>> feature set.
>
>
> AFAICT, in Debian, the same feature is given via virtual packages: you
> would have:

I don't think virtual-packages entirely fix the issue. AFAIK, virtual
packages have two uses:
 - handle dependencies where several packages may resolve one
particular dependency in an equivalent way (one good example is
LAPACK: both liblapack and libatlas provides the lapack feature)
 - closer to this discussion, you can build several variants of the
same package, and each variant would resolve the dependency on a
virtual package handling the commonalities. For example, say we have
two numpy packages, one built with lapack (python-numpy-full), the
other without (python-numpy-core). What happens when a package foo
(Continue reading)

Permalink | Reply | 2 comments |
headers
Manuel Wittchen | 2 Jan 11:23
Picon

calculating the difference of an array

Hi,

I want to calculate the difference between the values of a
numpy-array. The formula is:

deltaT = t_(n+1) - t_(n)

My approach to calculate the difference looks like this:

for i in len(ARRAY):
	delta_t[i] = ARRAY[(i+1):] - ARRAY[:(len(ARRAY)-1)]

print "result:", delta_t

But I get a TypeError:
File "./test.py", line 19, in <module>
    for i in len(ARRAY):
TypeError: 'int' object is not iterable

Where is the mistake in the code?

Regards and a happy new year,
Manuel Wittchen
Permalink | Reply | 3 comments |
headers
David Cournapeau | 2 Jan 11:31
Picon

Re: calculating the difference of an array

On Sat, Jan 2, 2010 at 7:23 PM, Manuel Wittchen
<manuel.wittchen <at> gmail.com> wrote:
> Hi,
>
> I want to calculate the difference between the values of a
> numpy-array. The formula is:
>
> deltaT = t_(n+1) - t_(n)
>
> My approach to calculate the difference looks like this:
>
> for i in len(ARRAY):
>        delta_t[i] = ARRAY[(i+1):] - ARRAY[:(len(ARRAY)-1)]
>
> print "result:", delta_t
>
> But I get a TypeError:
> File "./test.py", line 19, in <module>
>    for i in len(ARRAY):
> TypeError: 'int' object is not iterable
>
> Where is the mistake in the code?

There are several mistakes :)

Assuming ARRAY is a numpy array, len(ARRAY) will return an int. You
would have the same error if ARRAY was any sequence: you should
iterate over range(len(ARRAY)).

Your formula within the loop is not very clear, and does not seem to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Emmanuelle Gouillart | 2 Jan 11:34
Favicon
Gravatar

Re: calculating the difference of an array

Hello Manuel,

the discrete difference of a numpy array can be written in a very
natural way, without loops. Below are two possible ways to do it:
>>> a = np.arange(10)**2
>>> a
array([ 0,  1,  4,  9, 16, 25, 36, 49, 64, 81])
>>> a[1:] - a[:-1] 
array([ 1,  3,  5,  7,  9, 11, 13, 15, 17])
>>> np.diff(a) # another way to calculate the difference
array([ 1,  3,  5,  7,  9, 11, 13, 15, 17])

The error in the example you give is due to the fact that you iterate
over len(ARRAY), which is an integer, hence not an iterable object. You
should write ``for i in range(len(ARRAY))`` instead.

Cheers,

Emmanuelle 

On Sat, Jan 02, 2010 at 11:23:13AM +0100, Manuel Wittchen wrote:
> Hi,

> I want to calculate the difference between the values of a
> numpy-array. The formula is:

> deltaT = t_(n+1) - t_(n)

> My approach to calculate the difference looks like this:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Pierre Raybaut | 2 Jan 11:40

Re: [SPAM] Re: [SciPy-User] Announcing toydist, improving distribution and packaging situation

2010/1/2 David Cournapeau <cournape <at> gmail.com>:
> On Fri, Jan 1, 2010 at 10:43 PM, Pierre Raybaut <contact <at> pythonxy.com> wrote:
>> Hi David,
>>
>> Following your announcement for the 'toydist' module, I think that
>> your project is very promising: this is certainly a great idea and it
>> will be very controversial but that's because people expectactions are
>> great on this matter (distutils is so disappointing indeed).
>>
>> Anyway, if I may be useful, I'll gladly contribute to it.
>> In time, I could change the whole Python(x,y) packaging system (which
>> is currently quite ugly... but easy/quick to manage/maintain) to
>> use/promote this new module.
>
> That would be a good way to test toydist on a real, complex package. I
> am not familiar at all with python(x,y) internals. Do you have some
> explanation I could look at somewhere ?

Honestly, let's assume that there is currently no packaging system...
it would not be very far from the truth. I did it when I was young and
naive regarding Python. Actually I almost did it without having
writing any code in Python (approx. two months after earing about the
Python language for the first time) : it's an ugly collection of
AutoIt, NSIS and PHP scripts -- most of the tasks are automated like
updating the generated website pages and so on.
So I'm not proud at all, but it was easy and very quick to do as it
is, and it's still quite easy to maintain. But, it's not satisfying in
terms of code "purity" -- I've been wanting to rewrite all this in
Python for a year and a half but since the features are there, there
is no real motivation to do the work (in other words, Python(x,y)
(Continue reading)

Permalink | Reply | 0 comments |

Gmane