Re: [Numpy-discussion] Numpy.dot segmentation fault

2010-01-18 Thread Robin
You can build numpy against Accelerate through macports by specifying
the +no_atlas variant.

Last time I tried I ran into this issue:
http://trac.macports.org/ticket/22201

but it looks like it should be fixed now.

Cheers

Robin


On Mon, Jan 18, 2010 at 8:15 PM, Mark Lescroart  wrote:
> Hi David (et al),
>
> Thanks for the reply. The version of ATLAS I was using was v3.8.3_1,
> installed via MacPorts, compiled and built on my machine with a gcc4.3
> compiler. I uninstalled numpy 1.4 and ATLAS, re-installed (i.e., re-
> compiled) the same version (3.8.3_1), re-installed numpy (for
> python2.6, version 1.4), and got the same bug.
>
> I don't know if this means that there's something fundamentally wrong
> with the version of ATLAS on MacPorts (probably less likely) or
> something wrong with the way my system is configured (probably more
> likely). If anyone can give me any more insight into how to test my
> installation of ATLAS, I would be much obliged (I read through a fair
> bit of the ATLAS installation notes on the ATLAS sourceforge page, and
> could not figure out how to "run the whole test suite" ).
>
> If possible, I would like to solve this problem within Macports (and
> thus not with the Accelerate framework). I am using numpy mostly
> through the pyMVPA package for fMRI multi-voxel analysis, and the
> pyMVPA package depends on a number of other libraries, and the mess of
> dependencies is most easily managed within the framework of Macports.
>
> Cheers,
>
> Mark
>
> On Jan 17, 2010, at 8:38 PM, David Cournapeau wrote:
>
>> Mark Lescroart wrote:
>>> Hello,
>>>
>>> I've encountered a segfault in numpy when trying to compute a dot
>>> product for two arrays - see code below. The problem only seems to
>>> occur
>>> when the arrays reach a certain size.
>>
>> Your atlas is most likely broken. You will have to double-check how
>> you
>> built it, and maybe run the whole test suite (as indicated in the
>> ATLAS
>> installation notes).
>>
>> Note that you can use the Accelerate framework on mac os x, this is
>> much
>> easier to get numpy working on mac,
>>
>> cheers,
>>
>> David
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] Numpy.dot segmentation fault

2010-01-18 Thread Mark Lescroart
Hi David (et al),

Thanks for the reply. The version of ATLAS I was using was v3.8.3_1,  
installed via MacPorts, compiled and built on my machine with a gcc4.3  
compiler. I uninstalled numpy 1.4 and ATLAS, re-installed (i.e., re- 
compiled) the same version (3.8.3_1), re-installed numpy (for  
python2.6, version 1.4), and got the same bug.

I don't know if this means that there's something fundamentally wrong  
with the version of ATLAS on MacPorts (probably less likely) or  
something wrong with the way my system is configured (probably more  
likely). If anyone can give me any more insight into how to test my  
installation of ATLAS, I would be much obliged (I read through a fair  
bit of the ATLAS installation notes on the ATLAS sourceforge page, and  
could not figure out how to "run the whole test suite" ).

If possible, I would like to solve this problem within Macports (and  
thus not with the Accelerate framework). I am using numpy mostly  
through the pyMVPA package for fMRI multi-voxel analysis, and the  
pyMVPA package depends on a number of other libraries, and the mess of  
dependencies is most easily managed within the framework of Macports.

Cheers,

Mark

On Jan 17, 2010, at 8:38 PM, David Cournapeau wrote:

> Mark Lescroart wrote:
>> Hello,
>>
>> I've encountered a segfault in numpy when trying to compute a dot
>> product for two arrays - see code below. The problem only seems to  
>> occur
>> when the arrays reach a certain size.
>
> Your atlas is most likely broken. You will have to double-check how  
> you
> built it, and maybe run the whole test suite (as indicated in the  
> ATLAS
> installation notes).
>
> Note that you can use the Accelerate framework on mac os x, this is  
> much
> easier to get numpy working on mac,
>
> cheers,
>
> David
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] Is this expected behavior?

2010-01-18 Thread Russel Howe
Oh, of course.  I can reverse it myself.  Thanks, I did not think of that.

Russel

Warren Weckesser wrote:
> Russel Howe wrote:
>> Since they are iterators, is it possible to check for the second 
>> condition and reverse both of them so the behavior I expect happens or 
>> does this  break something else?
>>   
> 
> You may already know this, but just in case...
> 
> In the second case, you can accomplish the shift by using reversed slices:
> 
> a[:, -1:0:-1] = a[:, -2::-1]
> 
> 
> Warren
> 
>> Russel
>> Robert Kern wrote:
>>   
>>> On Mon, Jan 18, 2010 at 13:41, Russel Howe  wrote:
>>> 
 This looks like the difference between memmove and memcpy to me, but I
 am not sure what the expected behavior of numpy should be.  The first
 shift behaves the way I expect, the second is surprising.
   
>>> memmove() and memcpy() are not used for these operations (and in
>>> general, they can't be). Rather, iterators are created and looped over
>>> to do the assignments. Because you are not making copies on the
>>> right-hand-side, you are modifying the RHS as the iterators assign to
>>> the LHS.
>>>
>>> 
 In [3]: a[:, :-1] = a[:, 1:]

 In [4]: a
 Out[4]:
 array([[0, 5, 4, 8, 2, 7, 8, 7, 6, 6],
[6, 3, 3, 9, 8, 0, 8, 9, 5, 5],
[0, 1, 1, 2, 5, 8, 2, 5, 3, 3],
[0, 0, 2, 8, 2, 0, 7, 7, 0, 0],
[8, 6, 9, 6, 3, 9, 4, 4, 5, 5],
[7, 6, 9, 3, 8, 9, 9, 6, 9, 9],
[8, 8, 4, 0, 3, 7, 6, 7, 6, 6],
[4, 9, 2, 4, 7, 3, 6, 7, 4, 4],
[2, 0, 7, 0, 7, 6, 6, 1, 6, 6],
[3, 8, 8, 9, 6, 7, 2, 5, 0, 0]], dtype=uint8)
   
>>> The first one works because the RHS pointer is always one step ahead
>>> of the LHS pointer, thus it always reads pristine data.
>>>
>>> 
 In [5]: a[:, 1:] = a[:, :-1]

 In [6]: a
 Out[6]:
 array([[0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[6, 6, 6, 6, 6, 6, 6, 6, 6, 6],
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[8, 8, 8, 8, 8, 8, 8, 8, 8, 8],
[7, 7, 7, 7, 7, 7, 7, 7, 7, 7],
[8, 8, 8, 8, 8, 8, 8, 8, 8, 8],
[4, 4, 4, 4, 4, 4, 4, 4, 4, 4],
[2, 2, 2, 2, 2, 2, 2, 2, 2, 2],
[3, 3, 3, 3, 3, 3, 3, 3, 3, 3]], dtype=uint8)
   
>>> The second one fails to work as you expect because the RHS pointer is
>>> always one step behind the LHS pointer, thus it always reads the data
>>> that just got modified in the previous step. The data you expected it
>>> to read has already been wiped out.
>>>
>>> 
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>   
> 
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] Is this expected behavior?

2010-01-18 Thread Warren Weckesser
Russel Howe wrote:
> Since they are iterators, is it possible to check for the second 
> condition and reverse both of them so the behavior I expect happens or 
> does this  break something else?
>   

You may already know this, but just in case...

In the second case, you can accomplish the shift by using reversed slices:

a[:, -1:0:-1] = a[:, -2::-1]


Warren

> Russel
> Robert Kern wrote:
>   
>> On Mon, Jan 18, 2010 at 13:41, Russel Howe  wrote:
>> 
>>> This looks like the difference between memmove and memcpy to me, but I
>>> am not sure what the expected behavior of numpy should be.  The first
>>> shift behaves the way I expect, the second is surprising.
>>>   
>> memmove() and memcpy() are not used for these operations (and in
>> general, they can't be). Rather, iterators are created and looped over
>> to do the assignments. Because you are not making copies on the
>> right-hand-side, you are modifying the RHS as the iterators assign to
>> the LHS.
>>
>> 
>>> In [3]: a[:, :-1] = a[:, 1:]
>>>
>>> In [4]: a
>>> Out[4]:
>>> array([[0, 5, 4, 8, 2, 7, 8, 7, 6, 6],
>>>[6, 3, 3, 9, 8, 0, 8, 9, 5, 5],
>>>[0, 1, 1, 2, 5, 8, 2, 5, 3, 3],
>>>[0, 0, 2, 8, 2, 0, 7, 7, 0, 0],
>>>[8, 6, 9, 6, 3, 9, 4, 4, 5, 5],
>>>[7, 6, 9, 3, 8, 9, 9, 6, 9, 9],
>>>[8, 8, 4, 0, 3, 7, 6, 7, 6, 6],
>>>[4, 9, 2, 4, 7, 3, 6, 7, 4, 4],
>>>[2, 0, 7, 0, 7, 6, 6, 1, 6, 6],
>>>[3, 8, 8, 9, 6, 7, 2, 5, 0, 0]], dtype=uint8)
>>>   
>> The first one works because the RHS pointer is always one step ahead
>> of the LHS pointer, thus it always reads pristine data.
>>
>> 
>>> In [5]: a[:, 1:] = a[:, :-1]
>>>
>>> In [6]: a
>>> Out[6]:
>>> array([[0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
>>>[6, 6, 6, 6, 6, 6, 6, 6, 6, 6],
>>>[0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
>>>[0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
>>>[8, 8, 8, 8, 8, 8, 8, 8, 8, 8],
>>>[7, 7, 7, 7, 7, 7, 7, 7, 7, 7],
>>>[8, 8, 8, 8, 8, 8, 8, 8, 8, 8],
>>>[4, 4, 4, 4, 4, 4, 4, 4, 4, 4],
>>>[2, 2, 2, 2, 2, 2, 2, 2, 2, 2],
>>>[3, 3, 3, 3, 3, 3, 3, 3, 3, 3]], dtype=uint8)
>>>   
>> The second one fails to work as you expect because the RHS pointer is
>> always one step behind the LHS pointer, thus it always reads the data
>> that just got modified in the previous step. The data you expected it
>> to read has already been wiped out.
>>
>> 
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>   

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] Is this expected behavior?

2010-01-18 Thread Robert Kern
On Mon, Jan 18, 2010 at 13:51, Russel Howe  wrote:
> Since they are iterators, is it possible to check for the second
> condition and reverse both of them so the behavior I expect happens or
> does this  break something else?

In general, no I don't think it would be possible. It would create a
weird special case in the semantics, and slow down common assignments
that don't have the issue.

It would be nice to have a fast in-place roll(), though this is not
how one should implement it.

-- 
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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] Is this expected behavior?

2010-01-18 Thread Russel Howe
Since they are iterators, is it possible to check for the second 
condition and reverse both of them so the behavior I expect happens or 
does this  break something else?

Russel
Robert Kern wrote:
> On Mon, Jan 18, 2010 at 13:41, Russel Howe  wrote:
>> This looks like the difference between memmove and memcpy to me, but I
>> am not sure what the expected behavior of numpy should be.  The first
>> shift behaves the way I expect, the second is surprising.
> 
> memmove() and memcpy() are not used for these operations (and in
> general, they can't be). Rather, iterators are created and looped over
> to do the assignments. Because you are not making copies on the
> right-hand-side, you are modifying the RHS as the iterators assign to
> the LHS.
> 
>> In [3]: a[:, :-1] = a[:, 1:]
>>
>> In [4]: a
>> Out[4]:
>> array([[0, 5, 4, 8, 2, 7, 8, 7, 6, 6],
>>[6, 3, 3, 9, 8, 0, 8, 9, 5, 5],
>>[0, 1, 1, 2, 5, 8, 2, 5, 3, 3],
>>[0, 0, 2, 8, 2, 0, 7, 7, 0, 0],
>>[8, 6, 9, 6, 3, 9, 4, 4, 5, 5],
>>[7, 6, 9, 3, 8, 9, 9, 6, 9, 9],
>>[8, 8, 4, 0, 3, 7, 6, 7, 6, 6],
>>[4, 9, 2, 4, 7, 3, 6, 7, 4, 4],
>>[2, 0, 7, 0, 7, 6, 6, 1, 6, 6],
>>[3, 8, 8, 9, 6, 7, 2, 5, 0, 0]], dtype=uint8)
> 
> The first one works because the RHS pointer is always one step ahead
> of the LHS pointer, thus it always reads pristine data.
> 
>> In [5]: a[:, 1:] = a[:, :-1]
>>
>> In [6]: a
>> Out[6]:
>> array([[0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
>>[6, 6, 6, 6, 6, 6, 6, 6, 6, 6],
>>[0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
>>[0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
>>[8, 8, 8, 8, 8, 8, 8, 8, 8, 8],
>>[7, 7, 7, 7, 7, 7, 7, 7, 7, 7],
>>[8, 8, 8, 8, 8, 8, 8, 8, 8, 8],
>>[4, 4, 4, 4, 4, 4, 4, 4, 4, 4],
>>[2, 2, 2, 2, 2, 2, 2, 2, 2, 2],
>>[3, 3, 3, 3, 3, 3, 3, 3, 3, 3]], dtype=uint8)
> 
> The second one fails to work as you expect because the RHS pointer is
> always one step behind the LHS pointer, thus it always reads the data
> that just got modified in the previous step. The data you expected it
> to read has already been wiped out.
> 

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] logic problem

2010-01-18 Thread Ernest Adrogué
18/01/10 @ 13:18 (-0600), thus spake Warren Weckesser:
> Ernest Adrogué wrote:
> > Hi,
> >
> > This is hard to explain. In this code:
> >
> > reduce(np.logical_or, [m1 & m2, m1 & m3, m2 & m3])
> >
> > where m1, m2 and m3 are boolean arrays, I'm trying to figure
> > out an expression that works with an arbitrary number of
> > arrays, not just 3. Any idea??
> >
> >   
> 
> If I understand the problem correctly, you want the result to be True
> whenever any pair of the corresponding elements of the arrays are True.

Exactly.

> This could work:
> 
> reduce(np.add, [m.astype(int) for m in mlist]) > 1
> 
> where mlist is a list of the boolean array (e.g. mlist = [m1, m2, m3] in
> your example).

Very clever. Thanks a lot!

> Warren
> > Bye.
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Discussion@scipy.org
> > http://mail.scipy.org/mailman/listinfo/numpy-discussion
> >   
> 
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] Is this expected behavior?

2010-01-18 Thread Robert Kern
On Mon, Jan 18, 2010 at 13:41, Russel Howe  wrote:
> This looks like the difference between memmove and memcpy to me, but I
> am not sure what the expected behavior of numpy should be.  The first
> shift behaves the way I expect, the second is surprising.

memmove() and memcpy() are not used for these operations (and in
general, they can't be). Rather, iterators are created and looped over
to do the assignments. Because you are not making copies on the
right-hand-side, you are modifying the RHS as the iterators assign to
the LHS.

> In [3]: a[:, :-1] = a[:, 1:]
>
> In [4]: a
> Out[4]:
> array([[0, 5, 4, 8, 2, 7, 8, 7, 6, 6],
>        [6, 3, 3, 9, 8, 0, 8, 9, 5, 5],
>        [0, 1, 1, 2, 5, 8, 2, 5, 3, 3],
>        [0, 0, 2, 8, 2, 0, 7, 7, 0, 0],
>        [8, 6, 9, 6, 3, 9, 4, 4, 5, 5],
>        [7, 6, 9, 3, 8, 9, 9, 6, 9, 9],
>        [8, 8, 4, 0, 3, 7, 6, 7, 6, 6],
>        [4, 9, 2, 4, 7, 3, 6, 7, 4, 4],
>        [2, 0, 7, 0, 7, 6, 6, 1, 6, 6],
>        [3, 8, 8, 9, 6, 7, 2, 5, 0, 0]], dtype=uint8)

The first one works because the RHS pointer is always one step ahead
of the LHS pointer, thus it always reads pristine data.

> In [5]: a[:, 1:] = a[:, :-1]
>
> In [6]: a
> Out[6]:
> array([[0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
>        [6, 6, 6, 6, 6, 6, 6, 6, 6, 6],
>        [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
>        [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
>        [8, 8, 8, 8, 8, 8, 8, 8, 8, 8],
>        [7, 7, 7, 7, 7, 7, 7, 7, 7, 7],
>        [8, 8, 8, 8, 8, 8, 8, 8, 8, 8],
>        [4, 4, 4, 4, 4, 4, 4, 4, 4, 4],
>        [2, 2, 2, 2, 2, 2, 2, 2, 2, 2],
>        [3, 3, 3, 3, 3, 3, 3, 3, 3, 3]], dtype=uint8)

The second one fails to work as you expect because the RHS pointer is
always one step behind the LHS pointer, thus it always reads the data
that just got modified in the previous step. The data you expected it
to read has already been wiped out.

-- 
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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] logic problem

2010-01-18 Thread Ernest Adrogué
18/01/10 @ 14:17 (-0500), thus spake josef.p...@gmail.com:
> 2010/1/18 Ernest Adrogué :
> > Hi,
> >
> > This is hard to explain. In this code:
> >
> > reduce(np.logical_or, [m1 & m2, m1 & m3, m2 & m3])
> >
> > where m1, m2 and m3 are boolean arrays, I'm trying to figure
> > out an expression that works with an arbitrary number of
> > arrays, not just 3. Any idea??
> 
> What's the shape of mi (dimension)? fixed or arbitrary number of dimension?
> a loop is the most memory efficient

I forgot to mention, mi are 1-dimensional, all the same length
of course.

> array broadcasting builds large arrays (and maybe has redundant
> calculations), but might be a one-liner
> 
> or something like list comprehension
> 
> m = [m1, m2, ... mn]
> reduce(np.logical_or, [mi & mj for (i, mi) in enumerate(m) for (j, mj)
> in enumerate(m) if i 
> >>> m = [np.arange(10)<5, np.arange(10)>3, np.arange(10)>8]
> >>> m
> [array([ True,  True,  True,  True,  True, False, False, False, False,
> False], dtype=bool), array([False, False, False, False,  True,  True,
> True,  True,  True,  True], dtype=bool), array([False, False, False,
> False, False, False, False, False, False,  True], dtype=bool)]
> 
> >>> reduce(np.logical_or, [mi & mj for (i, mi) in enumerate(m) for (j, mj) in 
> >>> enumerate(m) if i array([False, False, False, False,  True, False, False, False, False,
> True], dtype=bool)
> 
> Josef
> 
> 
> >
> > Bye.
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Discussion@scipy.org
> > http://mail.scipy.org/mailman/listinfo/numpy-discussion
> >
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


[Numpy-discussion] Is this expected behavior?

2010-01-18 Thread Russel Howe
This looks like the difference between memmove and memcpy to me, but I 
am not sure what the expected behavior of numpy should be.  The first 
shift behaves the way I expect, the second is surprising.

I know about numpy.roll.  I was hoping for something faster, which this 
would be if it worked.

In [1]: a = (np.random.random((10,10))*10).astype('u1')

In [2]: a
Out[2]:
array([[8, 0, 5, 4, 8, 2, 7, 8, 7, 6],
[6, 6, 3, 3, 9, 8, 0, 8, 9, 5],
[5, 0, 1, 1, 2, 5, 8, 2, 5, 3],
[9, 0, 0, 2, 8, 2, 0, 7, 7, 0],
[9, 8, 6, 9, 6, 3, 9, 4, 4, 5],
[2, 7, 6, 9, 3, 8, 9, 9, 6, 9],
[2, 8, 8, 4, 0, 3, 7, 6, 7, 6],
[2, 4, 9, 2, 4, 7, 3, 6, 7, 4],
[3, 2, 0, 7, 0, 7, 6, 6, 1, 6],
[2, 3, 8, 8, 9, 6, 7, 2, 5, 0]], dtype=uint8)

In [3]: a[:, :-1] = a[:, 1:]

In [4]: a
Out[4]:
array([[0, 5, 4, 8, 2, 7, 8, 7, 6, 6],
[6, 3, 3, 9, 8, 0, 8, 9, 5, 5],
[0, 1, 1, 2, 5, 8, 2, 5, 3, 3],
[0, 0, 2, 8, 2, 0, 7, 7, 0, 0],
[8, 6, 9, 6, 3, 9, 4, 4, 5, 5],
[7, 6, 9, 3, 8, 9, 9, 6, 9, 9],
[8, 8, 4, 0, 3, 7, 6, 7, 6, 6],
[4, 9, 2, 4, 7, 3, 6, 7, 4, 4],
[2, 0, 7, 0, 7, 6, 6, 1, 6, 6],
[3, 8, 8, 9, 6, 7, 2, 5, 0, 0]], dtype=uint8)

In [5]: a[:, 1:] = a[:, :-1]

In [6]: a
Out[6]:
array([[0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[6, 6, 6, 6, 6, 6, 6, 6, 6, 6],
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[8, 8, 8, 8, 8, 8, 8, 8, 8, 8],
[7, 7, 7, 7, 7, 7, 7, 7, 7, 7],
[8, 8, 8, 8, 8, 8, 8, 8, 8, 8],
[4, 4, 4, 4, 4, 4, 4, 4, 4, 4],
[2, 2, 2, 2, 2, 2, 2, 2, 2, 2],
[3, 3, 3, 3, 3, 3, 3, 3, 3, 3]], dtype=uint8)

In [7]: np.__version__
Out[7]: '1.3.0'
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] performance matrix multiplication vs. matlab

2010-01-18 Thread Robert Kern
On Mon, Jan 18, 2010 at 13:34, Vicente Sole  wrote:

> You are taking point 4.d)0 while I am taking 4.d)1:
>
> """
> 1) Use a suitable shared library mechanism for linking with the
> Library. A suitable mechanism is one that (a) uses at run time a copy
> of the Library already present on the user's computer system, and (b)
> will operate properly with a modified version of the Library that is
> interface-compatible with the Linked Version.
> """
>
> If you are using the library as a shared library (what you do most of
> the times in Python), you are quite free.

numpy would not be using Eigen2 as a shared library. It is true that
numpy would act as a shared library with respect to some downstream
application, but incorporating Eigen2 into numpy would make those
numpy binaries be effectively under the LGPL license with respect to
the downstream application.

> In any case, it seems I am not the only one seeing it like that:
>
> http://qt.nokia.com/downloads
>
> The key point is if you use the library "as is" or you have modified it.

With respect to numpy and the way that Eigen2 was proposed as being
used, no, it is not the key point. We will not incorporate Eigen2 code
into numpy, particularly not as the default linear algebra
implementation, because we wish to keep numpy's source as being only
BSD. This is a policy decision of the numpy team, not a legal
incompatibility.

-- 
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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] logic problem

2010-01-18 Thread Warren Weckesser
josef.p...@gmail.com wrote:
> On Mon, Jan 18, 2010 at 2:18 PM, Warren Weckesser
>  wrote:
>   
>> Ernest Adrogué wrote:
>> 
>>> Hi,
>>>
>>> This is hard to explain. In this code:
>>>
>>> reduce(np.logical_or, [m1 & m2, m1 & m3, m2 & m3])
>>>
>>> where m1, m2 and m3 are boolean arrays, I'm trying to figure
>>> out an expression that works with an arbitrary number of
>>> arrays, not just 3. Any idea??
>>>
>>>
>>>   
>> If I understand the problem correctly, you want the result to be True
>> whenever any pair of the corresponding elements of the arrays are True.
>>
>> This could work:
>>
>> reduce(np.add, [m.astype(int) for m in mlist]) > 1
>>
>> where mlist is a list of the boolean array (e.g. mlist = [m1, m2, m3] in
>> your example).
>> 
>
> much nicer than what I came up with. Does iterator instead of
> intermediate list work (same for my list comprehension)?
>
>  reduce(np.add, (m.astype(int) for m in mlist)) > 1
>
>   

Yes, that works and is preferable, especially if the arrays are large or 
the list is long.

Warren

> Josef
>
>   
>

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] performance matrix multiplication vs. matlab

2010-01-18 Thread Vicente Sole
Quoting Bruce Southey :

> On 01/18/2010 12:47 PM, Vicente Sole wrote:
>> Quoting Bruce Southey :
>>
>>>
>>> If you obtain the code from any package then you are bound by the terms
>>> of that code. So while a user might not be 'inconvenienced' by the LGPL,
>>> they are required to meet the terms as required. For some licenses (like
>>> the LGPL) these terms do not really apply until you distribute the code
>>> but that does not mean that the user is exempt from the licensing terms
>>> of that code because they have not distributed their code (yet).
>>>
>>> Furthermore there are a number of numpy users that download the numpy
>>> project for further distribution such as Enthought, packagers for Linux
>>> distributions and developers of projects like Python(x,y). Some of these
>>> users would be inconvenienced because binary-only distributions would
>>> not be permitted in any form.
>>>
>>
>> I think people are confusing LGPL and GPL...
> Not at all.
>
>>
>> I can distribute my code in binary form without any restriction   
>> when using an LGPL library UNLESS I have modified the library itself.
>
> I do not interpret the LGPL version 3 in this way:
> A "Combined Work" is a work produced by combining or linking an
> Application with the Library.
> So you must apply section 4, in particular, provide the "Minimal
> Corresponding Source":
> The "Minimal Corresponding Source" for a Combined Work means the
> Corresponding Source for the Combined Work, excluding any source code
> for portions of the Combined Work that, considered in isolation, are
> based on the Application, and not on the Linked Version.
>
> So a binary-only is usually not appropriate.
>

You are taking point 4.d)0 while I am taking 4.d)1:

"""
1) Use a suitable shared library mechanism for linking with the  
Library. A suitable mechanism is one that (a) uses at run time a copy  
of the Library already present on the user's computer system, and (b)  
will operate properly with a modified version of the Library that is  
interface-compatible with the Linked Version.
"""

If you are using the library as a shared library (what you do most of  
the times in Python), you are quite free.

In any case, it seems I am not the only one seeing it like that:

http://qt.nokia.com/downloads

The key point is if you use the library "as is" or you have modified it.

Armando
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] logic problem

2010-01-18 Thread josef . pktd
On Mon, Jan 18, 2010 at 2:18 PM, Warren Weckesser
 wrote:
> Ernest Adrogué wrote:
>> Hi,
>>
>> This is hard to explain. In this code:
>>
>> reduce(np.logical_or, [m1 & m2, m1 & m3, m2 & m3])
>>
>> where m1, m2 and m3 are boolean arrays, I'm trying to figure
>> out an expression that works with an arbitrary number of
>> arrays, not just 3. Any idea??
>>
>>
>
> If I understand the problem correctly, you want the result to be True
> whenever any pair of the corresponding elements of the arrays are True.
>
> This could work:
>
> reduce(np.add, [m.astype(int) for m in mlist]) > 1
>
> where mlist is a list of the boolean array (e.g. mlist = [m1, m2, m3] in
> your example).

much nicer than what I came up with. Does iterator instead of
intermediate list work (same for my list comprehension)?

 reduce(np.add, (m.astype(int) for m in mlist)) > 1

Josef

>
> Warren
>> Bye.
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] logic problem

2010-01-18 Thread Warren Weckesser
Ernest Adrogué wrote:
> Hi,
>
> This is hard to explain. In this code:
>
> reduce(np.logical_or, [m1 & m2, m1 & m3, m2 & m3])
>
> where m1, m2 and m3 are boolean arrays, I'm trying to figure
> out an expression that works with an arbitrary number of
> arrays, not just 3. Any idea??
>
>   

If I understand the problem correctly, you want the result to be True
whenever any pair of the corresponding elements of the arrays are True.

This could work:

reduce(np.add, [m.astype(int) for m in mlist]) > 1

where mlist is a list of the boolean array (e.g. mlist = [m1, m2, m3] in
your example).

Warren
> Bye.
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>   

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] logic problem

2010-01-18 Thread josef . pktd
2010/1/18 Ernest Adrogué :
> Hi,
>
> This is hard to explain. In this code:
>
> reduce(np.logical_or, [m1 & m2, m1 & m3, m2 & m3])
>
> where m1, m2 and m3 are boolean arrays, I'm trying to figure
> out an expression that works with an arbitrary number of
> arrays, not just 3. Any idea??

What's the shape of mi (dimension)? fixed or arbitrary number of dimension?
a loop is the most memory efficient
array broadcasting builds large arrays (and maybe has redundant
calculations), but might be a one-liner

or something like list comprehension

m = [m1, m2, ... mn]
reduce(np.logical_or, [mi & mj for (i, mi) in enumerate(m) for (j, mj)
in enumerate(m) if i>> m = [np.arange(10)<5, np.arange(10)>3, np.arange(10)>8]
>>> m
[array([ True,  True,  True,  True,  True, False, False, False, False,
False], dtype=bool), array([False, False, False, False,  True,  True,
True,  True,  True,  True], dtype=bool), array([False, False, False,
False, False, False, False, False, False,  True], dtype=bool)]

>>> reduce(np.logical_or, [mi & mj for (i, mi) in enumerate(m) for (j, mj) in 
>>> enumerate(m) if i
> Bye.
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] performance matrix multiplication vs. matlab

2010-01-18 Thread Bruce Southey

On 01/18/2010 12:47 PM, Vicente Sole wrote:

Quoting Bruce Southey :



If you obtain the code from any package then you are bound by the terms
of that code. So while a user might not be 'inconvenienced' by the LGPL,
they are required to meet the terms as required. For some licenses (like
the LGPL) these terms do not really apply until you distribute the code
but that does not mean that the user is exempt from the licensing terms
of that code because they have not distributed their code (yet).

Furthermore there are a number of numpy users that download the numpy
project for further distribution such as Enthought, packagers for Linux
distributions and developers of projects like Python(x,y). Some of these
users would be inconvenienced because binary-only distributions would
not be permitted in any form.



I think people are confusing LGPL and GPL...

Not at all.



I can distribute my code in binary form without any restriction when 
using an LGPL library UNLESS I have modified the library itself. 


I do not interpret the LGPL version 3 in this way:
A "Combined Work" is a work produced by combining or linking an 
Application with the Library.
So you must apply section 4, in particular, provide the "Minimal 
Corresponding Source":
The "Minimal Corresponding Source" for a Combined Work means the 
Corresponding Source for the Combined Work, excluding any source code 
for portions of the Combined Work that, considered in isolation, are 
based on the Application, and not on the Linked Version.


So a binary-only is usually not appropriate.

Bruce

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


[Numpy-discussion] logic problem

2010-01-18 Thread Ernest Adrogué
Hi,

This is hard to explain. In this code:

reduce(np.logical_or, [m1 & m2, m1 & m3, m2 & m3])

where m1, m2 and m3 are boolean arrays, I'm trying to figure
out an expression that works with an arbitrary number of
arrays, not just 3. Any idea??

Bye.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] performance matrix multiplication vs. matlab

2010-01-18 Thread Bruce Southey
On 01/18/2010 10:46 AM, Benoit Jacob wrote:
> 2010/1/18 Robert Kern:
>
>> On Mon, Jan 18, 2010 at 10:26, Benoit Jacob  wrote:
>>  
>>> 2010/1/18 Robert Kern:
>>>
 On Mon, Jan 18, 2010 at 09:35, Benoit Jacob  
 wrote:

  
> Sorry for continuing the licensing noise on your list --- I though
> that now that I've started, I should let you know that I think I
> understand things more clearly now ;)
>
 No worries.

  
> First, Section 5 of the LGPL is horrible indeed, so let's forget about 
> that.
>
 I don't think it's that horrible, honestly. It just applies to a
 different deployment use case and a different set of technologies.

  
> If you were using a LGPL-licensed binary library, Section 4 would
> rather be what you want. It would require you to:
>   4a) say somewhere ("prominently" is vague, the bottom of a README is
> OK) that you use the library
>   4b) distribute copies of the GPL and LGPL licenses text. Pointless,
> but not a big issue.
>
> the rest doesn't matter:
>   4c) not applicable to you
>   4d1) this is what you would be doing anyway
>
 Possibly, but shared libraries are not easy for a variety of boring,
 Python-specific, technical reasons.
  
>>> Ah, that I didn't know.
>>>
>>>
>   4e) not applicable to you
>
 Yes, it is. The exception where Installation Information is not
 required is only when installation is impossible, such as embedded
 devices where the code is in a ROM chip.
  
>>> OK, I didn't understand that.
>>>
>>>
  
> Finally and this is the important point: you would not be passing any
> requirement to your own users. Indeed, the LGPL license, contrary to
> the GPL license, does not propagate through dependency chains. So if
> NumPy used a LGPL-licensed lib Foo, the conditions of the LGPL must be
> met when distributing NumPy, but NumPy itself isn't LGPL at all and an
> application using NumPy does not have to care at all about the LGPL.
> So there should be no concern at all of "passing on LGPL requirements
> to users"
>
 No, not at all. The GPL "propagates" by requiring that the rest of the
 code be licensed compatibly with the GPL. This is an unusual and
 particular feature of the GPL. The LGPL does not require that rest of
 the code be licensed in a particular way. However, that doesn't mean
 that the license of the "outer layer" insulates the downstream user
 from the LGPL license of the wrapped component. It just means that
 there is BSD code and LGPL code in the total product. The downstream
 user must accept and deal with the licenses of *all* of the components
 simultaneously. This is how most licenses work. I think that the fact
 that the GPL is particularly "viral" may be obscuring the normal way
 that licenses work when combined with other licenses.

 If I had a proprietary application that used an LGPL library, and I
 gave my customers some limited rights to modify and resell my
 application, they would still be bound by the LGPL with respect to the
 library. They could not modify the LGPLed library and sell it under a
 proprietary license even if I allow them to do that with the
 application as a whole. For us to use Eigen2 in numpy such that our
 users could use, modify and redistribute numpy+Eigen2, in its
 entirety, under the terms of the BSD license, we would have to get
 permission from you to distribute Eigen2 under the BSD license. It's
 only polite.
  
>>> OK, so the Eigen code inside of NumPy would still be protected by the
>>> LGPL. But what I meant when I said that the LGPL requirements don't
>>> propagate to your users, was that, for example, they don't have to
>>> distribute copies of the LGPL text, installation information for
>>> Eigen, or links to Eigen's website.
>>>
>> Yes, they do. They are redistributing Eigen; they must abide by its
>> license in all respects. It doesn't matter how much it is wrapped.
>>  
> Well this is where I'm not sure if I agree, I am asking the FSF right
> now as, if this were the case, I too would find such a clause very
> inconvenient for users.
>
>

If you obtain the code from any package then you are bound by the terms 
of that code. So while a user might not be 'inconvenienced' by the LGPL, 
they are required to meet the terms as required. For some licenses (like 
the LGPL) these terms do not really apply until you distribute the code 
but that does not mean that the user is exempt from the licensing terms 
of that code because they have not distributed their code (yet).

Furthermore there are a number of numpy users that download the numpy 
project for further distribution suc

[Numpy-discussion] EPD 6.0 and IPython Webinar Friday

2010-01-18 Thread Amenity Applewhite


Email not displaying correctly? View it in your browser.

Happy 2010! To start the year off, we've released a new version of EPD  
and lined up a solid set of training options.


Scientific Computing with Python Webinar
This Friday, Travis Oliphant  will then provide an introduction to  
multiprocessing and iPython.kernal.


Scientific Computing with Python Webinar
Multiprocessing and iPython.kernal
Friday, January 22: 1pm CST/7pm UTC
Register


Enthought Live Training
Enthought's intensive training courses are offered in 3-5 day  
sessions. The Python skills you'll acquire will save you and your  
organization time and money in 2010.



Enthought Open Course
February 22-26, Austin, TX
 • Python for Scientists and Engineers
 • Interfacing with C / C++ and Fortran
 • Introduction to UIs and Visualization

Enjoy!
The Enthought Team
   EPD 6.0
   Released
  Now available in our repository, EPD 6.0 includes Python 2.6,  
PiCloud's cloud library, and NumPy 1.4... Not to mention 64-bit  
support for Windows, OSX, and Linux.

Details. Download now.

  New:
  Enthought channel
  on YouTube
Short instructional videos straight from the desktops of our  
developers. Get started with a 4-part series on interpolation with  
SciPy.



Our mailing address is:
Enthought, Inc. 515 Congress Ave. Austin, TX 78701
Copyright (C) 2009 Enthought, Inc. All rights reserved.

Forward this email to a friend
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] performance matrix multiplication vs. matlab

2010-01-18 Thread Benoit Jacob
2010/1/18 Robert Kern :
> On Mon, Jan 18, 2010 at 10:26, Benoit Jacob  wrote:
>> 2010/1/18 Robert Kern :
>>> On Mon, Jan 18, 2010 at 09:35, Benoit Jacob  
>>> wrote:
>>>
 Sorry for continuing the licensing noise on your list --- I though
 that now that I've started, I should let you know that I think I
 understand things more clearly now ;)
>>>
>>> No worries.
>>>
 First, Section 5 of the LGPL is horrible indeed, so let's forget about 
 that.
>>>
>>> I don't think it's that horrible, honestly. It just applies to a
>>> different deployment use case and a different set of technologies.
>>>
 If you were using a LGPL-licensed binary library, Section 4 would
 rather be what you want. It would require you to:
  4a) say somewhere ("prominently" is vague, the bottom of a README is
 OK) that you use the library
  4b) distribute copies of the GPL and LGPL licenses text. Pointless,
 but not a big issue.

 the rest doesn't matter:
  4c) not applicable to you
  4d1) this is what you would be doing anyway
>>>
>>> Possibly, but shared libraries are not easy for a variety of boring,
>>> Python-specific, technical reasons.
>>
>> Ah, that I didn't know.
>>
  4e) not applicable to you
>>>
>>> Yes, it is. The exception where Installation Information is not
>>> required is only when installation is impossible, such as embedded
>>> devices where the code is in a ROM chip.
>>
>> OK, I didn't understand that.
>>
>>>
 Finally and this is the important point: you would not be passing any
 requirement to your own users. Indeed, the LGPL license, contrary to
 the GPL license, does not propagate through dependency chains. So if
 NumPy used a LGPL-licensed lib Foo, the conditions of the LGPL must be
 met when distributing NumPy, but NumPy itself isn't LGPL at all and an
 application using NumPy does not have to care at all about the LGPL.
 So there should be no concern at all of "passing on LGPL requirements
 to users"
>>>
>>> No, not at all. The GPL "propagates" by requiring that the rest of the
>>> code be licensed compatibly with the GPL. This is an unusual and
>>> particular feature of the GPL. The LGPL does not require that rest of
>>> the code be licensed in a particular way. However, that doesn't mean
>>> that the license of the "outer layer" insulates the downstream user
>>> from the LGPL license of the wrapped component. It just means that
>>> there is BSD code and LGPL code in the total product. The downstream
>>> user must accept and deal with the licenses of *all* of the components
>>> simultaneously. This is how most licenses work. I think that the fact
>>> that the GPL is particularly "viral" may be obscuring the normal way
>>> that licenses work when combined with other licenses.
>>>
>>> If I had a proprietary application that used an LGPL library, and I
>>> gave my customers some limited rights to modify and resell my
>>> application, they would still be bound by the LGPL with respect to the
>>> library. They could not modify the LGPLed library and sell it under a
>>> proprietary license even if I allow them to do that with the
>>> application as a whole. For us to use Eigen2 in numpy such that our
>>> users could use, modify and redistribute numpy+Eigen2, in its
>>> entirety, under the terms of the BSD license, we would have to get
>>> permission from you to distribute Eigen2 under the BSD license. It's
>>> only polite.
>>
>> OK, so the Eigen code inside of NumPy would still be protected by the
>> LGPL. But what I meant when I said that the LGPL requirements don't
>> propagate to your users, was that, for example, they don't have to
>> distribute copies of the LGPL text, installation information for
>> Eigen, or links to Eigen's website.
>
> Yes, they do. They are redistributing Eigen; they must abide by its
> license in all respects. It doesn't matter how much it is wrapped.

Well this is where I'm not sure if I agree, I am asking the FSF right
now as, if this were the case, I too would find such a clause very
inconvenient for users.

>
>> The only requirement, if I understand well, is that _if_ a NumPy user
>> wanted to make modifications to  Eigen itself, he would have to
>> conform to the LGPL requirements about sharing the modified source
>> code.
>>
>> But is it really a requirement of NumPy that all its dependencies must
>> be free to modify without redistributing the modified source code?
>
> For the default build and the official binaries, yes.

OK.

>
>> Don't you use MKL, for which the source code is not available at all?
>
> No, we don't. It is a build option. If you were to provide a BLAS
> interface to Eigen, Eigen would be another option.

OK, then I guess that this is what will happen once we release the BLAS library.

Thanks for your patience
Benoit
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] performance matrix multiplication vs. matlab

2010-01-18 Thread Robert Kern
On Mon, Jan 18, 2010 at 10:26, Benoit Jacob  wrote:
> 2010/1/18 Robert Kern :
>> On Mon, Jan 18, 2010 at 09:35, Benoit Jacob  wrote:
>>
>>> Sorry for continuing the licensing noise on your list --- I though
>>> that now that I've started, I should let you know that I think I
>>> understand things more clearly now ;)
>>
>> No worries.
>>
>>> First, Section 5 of the LGPL is horrible indeed, so let's forget about that.
>>
>> I don't think it's that horrible, honestly. It just applies to a
>> different deployment use case and a different set of technologies.
>>
>>> If you were using a LGPL-licensed binary library, Section 4 would
>>> rather be what you want. It would require you to:
>>>  4a) say somewhere ("prominently" is vague, the bottom of a README is
>>> OK) that you use the library
>>>  4b) distribute copies of the GPL and LGPL licenses text. Pointless,
>>> but not a big issue.
>>>
>>> the rest doesn't matter:
>>>  4c) not applicable to you
>>>  4d1) this is what you would be doing anyway
>>
>> Possibly, but shared libraries are not easy for a variety of boring,
>> Python-specific, technical reasons.
>
> Ah, that I didn't know.
>
>>>  4e) not applicable to you
>>
>> Yes, it is. The exception where Installation Information is not
>> required is only when installation is impossible, such as embedded
>> devices where the code is in a ROM chip.
>
> OK, I didn't understand that.
>
>>
>>> Finally and this is the important point: you would not be passing any
>>> requirement to your own users. Indeed, the LGPL license, contrary to
>>> the GPL license, does not propagate through dependency chains. So if
>>> NumPy used a LGPL-licensed lib Foo, the conditions of the LGPL must be
>>> met when distributing NumPy, but NumPy itself isn't LGPL at all and an
>>> application using NumPy does not have to care at all about the LGPL.
>>> So there should be no concern at all of "passing on LGPL requirements
>>> to users"
>>
>> No, not at all. The GPL "propagates" by requiring that the rest of the
>> code be licensed compatibly with the GPL. This is an unusual and
>> particular feature of the GPL. The LGPL does not require that rest of
>> the code be licensed in a particular way. However, that doesn't mean
>> that the license of the "outer layer" insulates the downstream user
>> from the LGPL license of the wrapped component. It just means that
>> there is BSD code and LGPL code in the total product. The downstream
>> user must accept and deal with the licenses of *all* of the components
>> simultaneously. This is how most licenses work. I think that the fact
>> that the GPL is particularly "viral" may be obscuring the normal way
>> that licenses work when combined with other licenses.
>>
>> If I had a proprietary application that used an LGPL library, and I
>> gave my customers some limited rights to modify and resell my
>> application, they would still be bound by the LGPL with respect to the
>> library. They could not modify the LGPLed library and sell it under a
>> proprietary license even if I allow them to do that with the
>> application as a whole. For us to use Eigen2 in numpy such that our
>> users could use, modify and redistribute numpy+Eigen2, in its
>> entirety, under the terms of the BSD license, we would have to get
>> permission from you to distribute Eigen2 under the BSD license. It's
>> only polite.
>
> OK, so the Eigen code inside of NumPy would still be protected by the
> LGPL. But what I meant when I said that the LGPL requirements don't
> propagate to your users, was that, for example, they don't have to
> distribute copies of the LGPL text, installation information for
> Eigen, or links to Eigen's website.

Yes, they do. They are redistributing Eigen; they must abide by its
license in all respects. It doesn't matter how much it is wrapped.

> The only requirement, if I understand well, is that _if_ a NumPy user
> wanted to make modifications to  Eigen itself, he would have to
> conform to the LGPL requirements about sharing the modified source
> code.
>
> But is it really a requirement of NumPy that all its dependencies must
> be free to modify without redistributing the modified source code?

For the default build and the official binaries, yes.

> Don't you use MKL, for which the source code is not available at all?

No, we don't. It is a build option. If you were to provide a BLAS
interface to Eigen, Eigen would be another option.

-- 
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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] performance matrix multiplication vs. matlab

2010-01-18 Thread Benoit Jacob
2010/1/18 Robert Kern :
> On Mon, Jan 18, 2010 at 09:35, Benoit Jacob  wrote:
>
>> Sorry for continuing the licensing noise on your list --- I though
>> that now that I've started, I should let you know that I think I
>> understand things more clearly now ;)
>
> No worries.
>
>> First, Section 5 of the LGPL is horrible indeed, so let's forget about that.
>
> I don't think it's that horrible, honestly. It just applies to a
> different deployment use case and a different set of technologies.
>
>> If you were using a LGPL-licensed binary library, Section 4 would
>> rather be what you want. It would require you to:
>>  4a) say somewhere ("prominently" is vague, the bottom of a README is
>> OK) that you use the library
>>  4b) distribute copies of the GPL and LGPL licenses text. Pointless,
>> but not a big issue.
>>
>> the rest doesn't matter:
>>  4c) not applicable to you
>>  4d1) this is what you would be doing anyway
>
> Possibly, but shared libraries are not easy for a variety of boring,
> Python-specific, technical reasons.

Ah, that I didn't know.

>>  4e) not applicable to you
>
> Yes, it is. The exception where Installation Information is not
> required is only when installation is impossible, such as embedded
> devices where the code is in a ROM chip.

OK, I didn't understand that.

>
>> Finally and this is the important point: you would not be passing any
>> requirement to your own users. Indeed, the LGPL license, contrary to
>> the GPL license, does not propagate through dependency chains. So if
>> NumPy used a LGPL-licensed lib Foo, the conditions of the LGPL must be
>> met when distributing NumPy, but NumPy itself isn't LGPL at all and an
>> application using NumPy does not have to care at all about the LGPL.
>> So there should be no concern at all of "passing on LGPL requirements
>> to users"
>
> No, not at all. The GPL "propagates" by requiring that the rest of the
> code be licensed compatibly with the GPL. This is an unusual and
> particular feature of the GPL. The LGPL does not require that rest of
> the code be licensed in a particular way. However, that doesn't mean
> that the license of the "outer layer" insulates the downstream user
> from the LGPL license of the wrapped component. It just means that
> there is BSD code and LGPL code in the total product. The downstream
> user must accept and deal with the licenses of *all* of the components
> simultaneously. This is how most licenses work. I think that the fact
> that the GPL is particularly "viral" may be obscuring the normal way
> that licenses work when combined with other licenses.
>
> If I had a proprietary application that used an LGPL library, and I
> gave my customers some limited rights to modify and resell my
> application, they would still be bound by the LGPL with respect to the
> library. They could not modify the LGPLed library and sell it under a
> proprietary license even if I allow them to do that with the
> application as a whole. For us to use Eigen2 in numpy such that our
> users could use, modify and redistribute numpy+Eigen2, in its
> entirety, under the terms of the BSD license, we would have to get
> permission from you to distribute Eigen2 under the BSD license. It's
> only polite.

OK, so the Eigen code inside of NumPy would still be protected by the
LGPL. But what I meant when I said that the LGPL requirements don't
propagate to your users, was that, for example, they don't have to
distribute copies of the LGPL text, installation information for
Eigen, or links to Eigen's website.

The only requirement, if I understand well, is that _if_ a NumPy user
wanted to make modifications to  Eigen itself, he would have to
conform to the LGPL requirements about sharing the modified source
code.

But is it really a requirement of NumPy that all its dependencies must
be free to modify without redistributing the modified source code?
Don't you use MKL, for which the source code is not available at all?
I am not sure that I understand how that is better than having source
code subject to LGPL requirements.

Benoit
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] performance matrix multiplication vs. matlab

2010-01-18 Thread Robert Kern
On Mon, Jan 18, 2010 at 09:35, Benoit Jacob  wrote:

> Sorry for continuing the licensing noise on your list --- I though
> that now that I've started, I should let you know that I think I
> understand things more clearly now ;)

No worries.

> First, Section 5 of the LGPL is horrible indeed, so let's forget about that.

I don't think it's that horrible, honestly. It just applies to a
different deployment use case and a different set of technologies.

> If you were using a LGPL-licensed binary library, Section 4 would
> rather be what you want. It would require you to:
>  4a) say somewhere ("prominently" is vague, the bottom of a README is
> OK) that you use the library
>  4b) distribute copies of the GPL and LGPL licenses text. Pointless,
> but not a big issue.
>
> the rest doesn't matter:
>  4c) not applicable to you
>  4d1) this is what you would be doing anyway

Possibly, but shared libraries are not easy for a variety of boring,
Python-specific, technical reasons. 4d0 would be easier for the
official binaries (because we provide official source). But that would
still force people building a proprietary application using numpy to
rebuild a binary without Eigen2 or else make sure that they allow
users to rebuild numpy. For a number of deployment options (py2app,
py2exe, bbfreeze, etc.), this is annoying, particularly when combined
with the 4e requirement, as I explain below.

>  4e) not applicable to you

Yes, it is. The exception where Installation Information is not
required is only when installation is impossible, such as embedded
devices where the code is in a ROM chip.

> Finally and this is the important point: you would not be passing any
> requirement to your own users. Indeed, the LGPL license, contrary to
> the GPL license, does not propagate through dependency chains. So if
> NumPy used a LGPL-licensed lib Foo, the conditions of the LGPL must be
> met when distributing NumPy, but NumPy itself isn't LGPL at all and an
> application using NumPy does not have to care at all about the LGPL.
> So there should be no concern at all of "passing on LGPL requirements
> to users"

No, not at all. The GPL "propagates" by requiring that the rest of the
code be licensed compatibly with the GPL. This is an unusual and
particular feature of the GPL. The LGPL does not require that rest of
the code be licensed in a particular way. However, that doesn't mean
that the license of the "outer layer" insulates the downstream user
from the LGPL license of the wrapped component. It just means that
there is BSD code and LGPL code in the total product. The downstream
user must accept and deal with the licenses of *all* of the components
simultaneously. This is how most licenses work. I think that the fact
that the GPL is particularly "viral" may be obscuring the normal way
that licenses work when combined with other licenses.

If I had a proprietary application that used an LGPL library, and I
gave my customers some limited rights to modify and resell my
application, they would still be bound by the LGPL with respect to the
library. They could not modify the LGPLed library and sell it under a
proprietary license even if I allow them to do that with the
application as a whole. For us to use Eigen2 in numpy such that our
users could use, modify and redistribute numpy+Eigen2, in its
entirety, under the terms of the BSD license, we would have to get
permission from you to distribute Eigen2 under the BSD license. It's
only polite.

-- 
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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] performance matrix multiplication vs. matlab

2010-01-18 Thread Benoit Jacob
2010/1/17 Benoit Jacob :
> 2010/1/17 Robert Kern :
>> On Sun, Jan 17, 2010 at 13:18, Benoit Jacob  wrote:
>>> 2010/1/17 Robert Kern :
 On Sun, Jan 17, 2010 at 12:11, Benoit Jacob  
 wrote:
> 2010/1/17 Robert Kern :
>> On Sun, Jan 17, 2010 at 08:52, Benoit Jacob  
>> wrote:
>>> 2010/1/17 David Cournapeau :
>>
 There are several issues with eigen2 for NumPy usage:
  - using it as a default implementation does not make much sense IMHO,
 as it would make distributed binaries non 100 % BSD.
>>>
>>> But the LGPL doesn't impose restrictions on the usage of binaries, so
>>> how does it matter? The LGPL and the BSD licenses are similar as far
>>> as the binaries are concerned (unless perhaps one starts disassembling
>>> them).
>>>
>>> The big difference between LGPL and BSD is at the level of source
>>> code, not binary code: one modifies LGPL-based source code and
>>> distributes a binary form of it, then one has to release the modified
>>> source code as well.
>>
>> This is not true. Binaries that contain LGPLed code must be able to be
>> relinked with a modified version of the LGPLed component.
>
> This doesn't apply to Eigen which is a header-only pure template
> library, hence can't be 'linked' to.
>
> Actually you seem to be referring to Section 4 of the LGPL3, we have
> already asked the FSF about this and their reply was that it just
> doesn't apply in the case of Eigen:
>
> http://listengine.tuxfamily.org/lists.tuxfamily.org/eigen/2009/01/msg00083.html
>
> In your case, what matters is Section 5.

 You mean Section 3. Good.
>>>
>>> Section 3 is for using Eigen directly in a C++ program, yes, but I got
>>> a bit ahead of myself there: see below
>>>
 I admit to being less up on the details of
 LGPLv3 than I was of LGPLv2 which had a problem with C++ header
 templates.
>>>
>>> Indeed, it did, that's why we don't use it.
>>>

 That said, we will not be using the C++ templates directly in numpy
 for technical reasons (not least that we do not want to require a C++
 compiler for the default build). At best, we would be using a BLAS
 interface which requires linking of objects, not just header
 templates. That *would* impose the Section 4 requirements.
>>>
>>> ... or rather Section 5: that is what I was having in mind:
>>>  " 5. Combined Libraries. "
>>>
>>> I have to admit that I don't understand what 5.a) means.
>>
>> I don't think it applies. Let's say I write some routines that use an
>> LGPLed Library (let's call them Routines A). I can include those
>> routines in a larger library with routines that do not use the LGPLed
>> library (Routines B). The Routines B can be under whatever license you
>> like. However, one must make a library containing only Routines A and
>> the LGPLed Library and release that under the LGPLv3, distribute it
>> along with the combined work, and give notice about how to obtain
>> Routines A+Library separate from Routines B. Basically, it's another
>> exception for needing to be able to relink object code in a particular
>> technical use case.
>>
>> This cannot apply to numpy because we cannot break out numpy.linalg
>> from the rest of numpy. Even if we could, we do not wish to make
>> numpy.linalg itself LGPLed.
>
> Indeed, that seems very cumbersome. I will ask the FSF about this, as
> this is definitely not something that we want to impose on Eigen
> users.
>

Sorry for continuing the licensing noise on your list --- I though
that now that I've started, I should let you know that I think I
understand things more clearly now ;)

First, Section 5 of the LGPL is horrible indeed, so let's forget about that.

If you were using a LGPL-licensed binary library, Section 4 would
rather be what you want. It would require you to:
 4a) say somewhere ("prominently" is vague, the bottom of a README is
OK) that you use the library
 4b) distribute copies of the GPL and LGPL licenses text. Pointless,
but not a big issue.

the rest doesn't matter:
 4c) not applicable to you
 4d1) this is what you would be doing anyway
 4e) not applicable to you

Finally and this is the important point: you would not be passing any
requirement to your own users. Indeed, the LGPL license, contrary to
the GPL license, does not propagate through dependency chains. So if
NumPy used a LGPL-licensed lib Foo, the conditions of the LGPL must be
met when distributing NumPy, but NumPy itself isn't LGPL at all and an
application using NumPy does not have to care at all about the LGPL.
So there should be no concern at all of "passing on LGPL requirements
to users"

Again, IANAL.

Benoit
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] Structured array sorting

2010-01-18 Thread Charles R Harris
On Mon, Jan 18, 2010 at 6:39 AM, Thomas Robitaille <
thomas.robitai...@gmail.com> wrote:

>
>
> Warren Weckesser-3 wrote:
> >
> > Looks like 'sort' is not handling endianess of the column data
> > correctly.  If you change the type of the floating point data to ' > the sort works.
> >
>
> Thanks for identifying the issue - should I submit a bug report?
>
>
Yes.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] Structured array sorting

2010-01-18 Thread Thomas Robitaille


Warren Weckesser-3 wrote:
> 
> Looks like 'sort' is not handling endianess of the column data 
> correctly.  If you change the type of the floating point data to ' the sort works.
> 

Thanks for identifying the issue - should I submit a bug report?

Thomas
-- 
View this message in context: 
http://old.nabble.com/Structured-array-sorting-tp27200785p27210615.html
Sent from the Numpy-discussion mailing list archive at Nabble.com.

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion