numpy-discussion — Discussion list for all users of Numerical Python

Re: [Numpy-discussion] A comparative test

[Francesc A. <fa...@ca...>]

A Dijous 06 Octubre 2005 20:55, Colin J. Williams va escriure:
> RESULTS:
>  >pythonw -u "NumericNumarrayTest.py"
>
> Timer-Numeric23.8: 0.179712784725
> Timer-numarray1.3.3: 0.21674933546
> Timer-Numeric3: 0.253077136899

Is that really true? From my original post:

>>> from timeit import Timer
>>> setup =3D "import Numeric; a =3D Numeric.arange(2000);a.shape=3D(1000,2=
)"
>>> Timer("for i in range(len(a)): row=3Da[i]", setup).timeit(number=3D100)
 0.12782907485961914
>>> setup =3D "import numarray; a =3D numarray.arange(2000);a.shape=3D(1000=
,2)"
>>> Timer("for i in range(len(a)): row=3Da[i]", setup).timeit(number=3D100)
 1.2013700008392334

My post was from January, so, in the interim numarray has improved *a
lot* it's object creation time. In that case, why the numarray team
hasn't publisized that more? Well, I think I should be missing
something. Time for nap.

Cheers,

=2D-=20
>0,0<   Francesc Altet =A0 =A0 http://www.carabos.com/
V   V   C=E1rabos Coop. V. =A0=A0Enjoy Data
 "-"

[Numpy-discussion] A comparative test

[Colin J. W. <cj...@sy...>]

# NumericNumarrayTest.py
''' A test, provided by Francesc Altet
    
http://sourceforge.net/mailarchive/forum.php?thread_id=6396059&forum_id=4890
    '''
from timeit import Timer
setup = "import Numeric; a = Numeric.arange(2000);a.shape=(1000,2)"
print 'Timer-Numeric23.8:', Timer("for i in range(len(a)): row=a[i]", 
setup).timeit(number=100)
 
#
setup = "import numarray; a = numarray.arange(2000);a.shape=(1000,2)"
print 'Timer-numarray1.3.3:', Timer("for i in range(len(a)): row=a[i]", 
setup).timeit(number=100)

# scipy/Numeric3 added
setup = "import scipy.base; a = scipy.base.arange(2000);a.shape=(1000,2)"
print 'Timer-Numeric3:', Timer("for i in range(len(a)): row=a[i]", 
setup).timeit(number=100)

RESULTS:
 >pythonw -u "NumericNumarrayTest.py"
Timer-Numeric23.8: 0.179712784725
Timer-numarray1.3.3: 0.21674933546
Timer-Numeric3: 0.253077136899
 >Exit code: 0
 
Colin W.

Re: [SciPy-user] Re: [SciPy-dev] Re: [Numpy-discussion] Purchasing Documentation

[Matthew B. <mat...@gm...>]

Hi,

> >So, just to clarify - does Fenando win his bet (was it dollars or
> >doughnuts)?  Are you happy for the community to write and release free
> >basic documentation for scipy.base?
>
> Yes, yes.  Fernando knows me pretty well in that regard. I'll probably
> contribute to it with useful selections from the book (once I have the
> book finished).    It really motivates me to produce more  (of
> everything) when I see people actually purchasing the documentation.

Excellent - thanks very much for that.  When my credit cards have
recovered from their address changes I will be early in line!

Best,

Matthew

Re: [Numpy-discussion] Re: [SciPy-user] Fwd: Scipy_core and numarray

[Jeff W. <js...@fa...>]

Travis Oliphant wrote:

> Andrew Jaffe wrote:
>
>> Hi All,
>>
>> I've tried to post via the newsgroup interface, but my messages have
>> never appeared, so here's another try!...
>>
>> I'm currently a numarray user from the astrophysics community and I
>> suppose I want to understand a bit more about the relationship between
>> the two projects. Do the two projects exist side-by-side? Will numarray
>> be superseded by scipy_core? I like the speed advantage of scipy_core,
>> but I there may be features of numarray I don't want to give up (or
>> legacy code I need to interfact with).
>>  
>>
> I'm interested in the "features" you don't want to give up.  SciPy 
> core should have all features of numarray.
> Also, scipy core, numarray, and Numeric can all live together.  If you 
> are using sufficient versions of each, you can exchange data via the 
> array interface. 


Will scipy_core have nd_image and memory mapping? 

-Jeff

-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/CDC  R/CDC1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

[Numpy-discussion] Re: [SciPy-user] Fwd: Scipy_core and numarray

[Travis O. <oli...@ee...>]

Andrew Jaffe wrote:

>Hi All,
>
>I've tried to post via the newsgroup interface, but my messages have
>never appeared, so here's another try!...
>
>I'm currently a numarray user from the astrophysics community and I
>suppose I want to understand a bit more about the relationship between
>the two projects. Do the two projects exist side-by-side? Will numarray
>be superseded by scipy_core? I like the speed advantage of scipy_core,
>but I there may be features of numarray I don't want to give up (or
>legacy code I need to interfact with).
>  
>
I'm interested in the "features" you don't want to give up.  SciPy core 
should have all features of numarray. 

Also, scipy core, numarray, and Numeric can all live together.  If you 
are using sufficient versions of each, you can exchange data via the 
array interface.

The ONLY reason I started scipy core was to unify Numeric and numarray 
users.   My selling documentation, should not be construed as anything 
else but trying to help people who can't find time to contribute in 
other ways to contribute to that goal.  

If I was "just trying to make money,"  I would be doing something far 
different than this...

>
>Along the latter lines, I have a more practical question: one
>numarray capability that I used a lot was the ability to create
>uninitialized arrays, such as
>
>     arr = numarray.array(shape=(3,5), type=Float64)
>  
>
It's actually there in Numeric (since 23.7 I think).

Numeric.empty((3,5),'d')

and also in (new) scipy

scipy.empty((3,5),scipy.float64)

In (new) scipy you can also create new arrays from buffers very easily.

-Travis

Re: [SciPy-user] Re: [SciPy-dev] Re: [Numpy-discussion] Purchasing Documentation

[Travis O. <oli...@ee...>]

Matthew Brett wrote:

>Hi Travis,
>
>So, can I summarize for my own benefit?
>
>I think we all agree that software without documentation is not
>usable, and therefore that free software requires that the basic
>documentation also be free.
>
>Obviously if the _basic_ documentation is not free, this will
>dramatically reduce software uptake.
>
>And I think we all also agree that there is no problem of any sort
>with not-free documentation that expands in a useful way on the basic
>documentation.
>
>So, just to clarify - does Fenando win his bet (was it dollars or
>doughnuts)?  Are you happy for the community to write and release free
>basic documentation for scipy.base?
>  
>

Yes, yes.  Fernando knows me pretty well in that regard. I'll probably 
contribute to it with useful selections from the book (once I have the 
book finished).    It really motivates me to produce more  (of 
everything) when I see people actually purchasing the documentation.

And I certainly don't want "lack of free documentation" to hamper 
adoption of scipy core.   So, it benefits everybody to have free version 
available.

It would be great if somebody could at least post the pydoc output for 
the core.  That is a good start.  I'll add basic C-API calls to free 
documentation and we'll be ready to go.

-Travis

Re: [Numpy-discussion] Re: Purchasing Documentation

[Francesc A. <fa...@ca...>]

A Dijous 06 Octubre 2005 11:52, Francesc Altet va escriure:
> Exactly, I'm wondering the same questions. Provided that numarray is
> an excellent and mature piece of code, I'd like to hear a declaration
> of principles on that subject.

Er, I think I'd better said "declaration of intentions", sorry.

Cheers,

=2D-=20
>0,0<   Francesc Altet =A0 =A0 http://www.carabos.com/
V   V   C=E1rabos Coop. V. =A0=A0Enjoy Data
 "-"

[Numpy-discussion] A possible problem with PythonWin and Numeric3

[Colin J. W. <cj...@sy...>]

PythonWin 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] 
on win32.
Portions Copyright 1994-2004 Mark Hammond (mha...@sk...) - 
see 'Help/About PythonWin' for further copyright information.
 >>> import scipy                         <==  Executing this causes a 
crash.
 >>> import scipy.base                 <== This has the same effect

Colin W.

Re: [SciPy-user] Re: [SciPy-dev] Re: [Numpy-discussion] Purchasing Documentation

[Matthew B. <mat...@gm...>]

Hi Travis,

So, can I summarize for my own benefit?

I think we all agree that software without documentation is not
usable, and therefore that free software requires that the basic
documentation also be free.

Obviously if the _basic_ documentation is not free, this will
dramatically reduce software uptake.

And I think we all also agree that there is no problem of any sort
with not-free documentation that expands in a useful way on the basic
documentation.

So, just to clarify - does Fenando win his bet (was it dollars or
doughnuts)?  Are you happy for the community to write and release free
basic documentation for scipy.base?

Thanks a lot,

Matthew

[Numpy-discussion] pysci base formerly Numeric3

[Colin J. W. <cj...@sy...>]

I have just downloaded and installed the Windows version.

The install appeared to go smoothly but test_basic.py gave some errors, 
is this what one should expect?
---------------------------------------------------------------------------------------------------------------------
 >pythonw -u "test_basic.py"
   !! No test file 'test_scimath.py' found for <module 
'scipy.base.scimath' from '...ackages\\scipy\\base\\scimath.pyc'>
   !! No test file 'test_umath.py' found for <module 'scipy.base.umath' 
from '...-packages\\scipy\\base\\umath.pyd'>
  Found 23 tests for scipy.base.function_base
   !! No test file 'test_machar.py' found for <module 
'scipy.base.machar' from '...packages\\scipy\\base\\machar.pyc'>
   !! No test file 'test_ma.py' found for <module 'scipy.base.ma' from 
'...ite-packages\\scipy\\base\\ma.pyc'>
   !! No test file 'test_numerictypes.py' found for <module 
'scipy.base.numerictypes' from '...es\\scipy\\base\\numerictypes.pyc'>
   !! No test file 'test_getlimits.py' found for <module 
'scipy.base.getlimits' from '...kages\\scipy\\base\\getlimits.pyc'>
  Found 9 tests for scipy.base.twodim_base
   !! No test file 'test__compiled_base.py' found for <module 
'scipy.base._compiled_base' from '...\\scipy\\base\\_compiled_base.pyd'>
   !! No test file 'test_info_scipy_base.py' found for <module 
'scipy.base.info_scipy_base' from '...scipy\\base\\info_scipy_base.pyc'>
   !! No test file 'test_base.py' found for <module 'scipy.base' from 
'...ckages\\scipy\\base\\__init__.pyc'>
   !! No test file 'test_convertcode.py' found for <module 
'scipy.base.convertcode' from '...ges\\scipy\\base\\convertcode.pyc'>
   !! No test file 'test_multiarray.py' found for <module 
'scipy.base.multiarray' from '...ages\\scipy\\base\\multiarray.pyd'>
   !! No test file 'test_matrix.py' found for <module 
'scipy.base.matrix' from '...packages\\scipy\\base\\matrix.pyc'>
   !! No test file 'test_oldnumeric.py' found for <module 
'scipy.base.oldnumeric' from '...ages\\scipy\\base\\oldnumeric.pyc'>
  Found 44 tests for scipy.base.shape_base
   !! No test file 'test_numeric.py' found for <module 
'scipy.base.numeric' from '...ackages\\scipy\\base\\numeric.pyc'>
   !! No test file 'test_polynomial.py' found for <module 
'scipy.base.polynomial' from '...ages\\scipy\\base\\polynomial.pyc'>
  Found 42 tests for scipy.base.type_check
   !! No test file 'test_arrayprint.py' found for <module 
'scipy.base.arrayprint' from '...ages\\scipy\\base\\arrayprint.pyc'>
  Found 4 tests for scipy.base.index_tricks
  Found 0 tests for __main__
................................E.................................................E........E.E.E...........EEEEEE.E..E....
======================================================================
ERROR: check_simple 
(scipy.base.shape_base.test_shape_base.test_apply_along_axis)
----------------------------------------------------------------------
Traceback (most recent call last):
  File 
"C:\Python24\Lib\site-packages\scipy\base\tests\test_shape_base.py", 
line 14, in check_simple
    assert_array_equal(apply_along_axis(len,0,a),len(a)*ones(shape(a)[1]))
  File "C:\Python24\Lib\site-packages\scipy\base\shape_base.py", line 
31, in apply_along_axis
    res = func1d(arr[tuple(i)],*args)
IndexError: each subindex must be either a slice, an integer, Ellipsis, 
or newaxis

======================================================================
ERROR: check_complex1 (scipy.base.type_check.test_type_check.test_isfinite)
----------------------------------------------------------------------
Traceback (most recent call last):
  File 
"C:\Python24\Lib\site-packages\scipy\base\tests\test_type_check.py", 
line 162, in check_complex1
    assert_all(isfinite(array(1+1j)/0.) == 0)
ZeroDivisionError: complex division

======================================================================
ERROR: check_neginf_scalar 
(scipy.base.type_check.test_type_check.test_isinf)
----------------------------------------------------------------------
Traceback (most recent call last):
  File 
"C:\Python24\Lib\site-packages\scipy\base\tests\test_type_check.py", 
line 176, in check_neginf_scalar
    assert_all(isinf(array(-1.)/0.) == 1)
ZeroDivisionError: float division

======================================================================
ERROR: check_posinf_scalar 
(scipy.base.type_check.test_type_check.test_isinf)
----------------------------------------------------------------------
Traceback (most recent call last):
  File 
"C:\Python24\Lib\site-packages\scipy\base\tests\test_type_check.py", 
line 172, in check_posinf_scalar
    assert_all(isinf(array(1.,)/0.) == 1)
ZeroDivisionError: float division

======================================================================
ERROR: check_complex1 (scipy.base.type_check.test_type_check.test_isnan)
----------------------------------------------------------------------
Traceback (most recent call last):
  File 
"C:\Python24\Lib\site-packages\scipy\base\tests\test_type_check.py", 
line 142, in check_complex1
    assert_all(isnan(array(0+0j)/0.) == 1)
ZeroDivisionError: complex division

======================================================================
ERROR: check_default_1 
(scipy.base.type_check.test_type_check.test_mintypecode)
----------------------------------------------------------------------
Traceback (most recent call last):
  File 
"C:\Python24\Lib\site-packages\scipy\base\tests\test_type_check.py", 
line 18, in check_default_1
    assert_equal(mintypecode(itype),'d')
  File "C:\Python24\Lib\site-packages\scipy\base\type_check.py", line 
30, in mintypecode
    typecodes = [(type(t) is type('') and t) or asarray(t).dtypechar\
UnboundLocalError: local variable 'typecodes' referenced before assignment

======================================================================
ERROR: check_default_2 
(scipy.base.type_check.test_type_check.test_mintypecode)
----------------------------------------------------------------------
Traceback (most recent call last):
  File 
"C:\Python24\Lib\site-packages\scipy\base\tests\test_type_check.py", 
line 26, in check_default_2
    assert_equal(mintypecode(itype+'f'),'f')
  File "C:\Python24\Lib\site-packages\scipy\base\type_check.py", line 
30, in mintypecode
    typecodes = [(type(t) is type('') and t) or asarray(t).dtypechar\
UnboundLocalError: local variable 'typecodes' referenced before assignment

======================================================================
ERROR: check_default_3 
(scipy.base.type_check.test_type_check.test_mintypecode)
----------------------------------------------------------------------
Traceback (most recent call last):
  File 
"C:\Python24\Lib\site-packages\scipy\base\tests\test_type_check.py", 
line 50, in check_default_3
    assert_equal(mintypecode('fdF'),'D')
  File "C:\Python24\Lib\site-packages\scipy\base\type_check.py", line 
30, in mintypecode
    typecodes = [(type(t) is type('') and t) or asarray(t).dtypechar\
UnboundLocalError: local variable 'typecodes' referenced before assignment

======================================================================
ERROR: check_complex_bad 
(scipy.base.type_check.test_type_check.test_nan_to_num)
----------------------------------------------------------------------
Traceback (most recent call last):
  File 
"C:\Python24\Lib\site-packages\scipy\base\tests\test_type_check.py", 
line 211, in check_complex_bad
    v += array(0+1.j)/0.
ZeroDivisionError: complex division

======================================================================
ERROR: check_complex_bad2 
(scipy.base.type_check.test_type_check.test_nan_to_num)
----------------------------------------------------------------------
Traceback (most recent call last):
  File 
"C:\Python24\Lib\site-packages\scipy\base\tests\test_type_check.py", 
line 217, in check_complex_bad2
    v += array(-1+1.j)/0.
ZeroDivisionError: complex division

======================================================================
ERROR: check_complex_good 
(scipy.base.type_check.test_type_check.test_nan_to_num)
----------------------------------------------------------------------
Traceback (most recent call last):
  File 
"C:\Python24\Lib\site-packages\scipy\base\tests\test_type_check.py", 
line 207, in check_complex_good
    vals = nan_to_num(1+1j)
  File "C:\Python24\Lib\site-packages\scipy\base\type_check.py", line 
99, in nan_to_num
    y = nan_to_num(x.real) + 1j * nan_to_num(x.imag)
  File "C:\Python24\Lib\site-packages\scipy\base\type_check.py", line 
106, in nan_to_num
    y[are_nan] = 0
TypeError: object does not support item assignment

======================================================================
ERROR: check_integer (scipy.base.type_check.test_type_check.test_nan_to_num)
----------------------------------------------------------------------
Traceback (most recent call last):
  File 
"C:\Python24\Lib\site-packages\scipy\base\tests\test_type_check.py", 
line 204, in check_integer
    vals = nan_to_num(1)
  File "C:\Python24\Lib\site-packages\scipy\base\type_check.py", line 
105, in nan_to_num
    maxf, minf = _getmaxmin(y.dtype)
  File "C:\Python24\Lib\site-packages\scipy\base\type_check.py", line 
86, in _getmaxmin
    f = getlimits.finfo(t)
  File "C:\Python24\Lib\site-packages\scipy\base\getlimits.py", line 29, 
in __init__
    raise ValueError, "data type not inexact"
ValueError: data type not inexact

======================================================================
ERROR: check_basic 
(scipy.base.type_check.test_type_check.test_real_if_close)
----------------------------------------------------------------------
Traceback (most recent call last):
  File 
"C:\Python24\Lib\site-packages\scipy\base\tests\test_type_check.py", 
line 230, in check_basic
    b = real_if_close(a+1e-15j)
  File "C:\Python24\Lib\site-packages\scipy\base\type_check.py", line 
120, in real_if_close
    tol = f.epsilon * tol
AttributeError: 'finfo' object has no attribute 'epsilon'

----------------------------------------------------------------------
Ran 122 tests in 0.521s

FAILED (errors=13)
 >Exit code: -1073741819
-------------------------------------------------------------------------------------------------------------------

Colin W.

Re: [Numpy-discussion] Re: Purchasing Documentation

[Francesc A. <fa...@ca...>]

Exactly, I'm wondering the same questions. Provided that numarray is
an excellent and mature piece of code, I'd like to hear a declaration
of principles on that subject.

Regards,

A Dijous 06 Octubre 2005 01:55, Colin J. Williams va escriure:
> Perry,
>
> It would be helpful if you gave some indication of your organization's
> intention with respect to numarray.
>
> Will it be maintained, as in the past, fully in the public domain and
> without charge for either the code or the API information needed to make
> use of the code?
>
> New versions have been produced every few months, will this continue?
>
> Colin W.
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

=2D-=20
>0,0<   Francesc Altet =A0 =A0 http://www.carabos.com/
V   V   C=E1rabos Coop. V. =A0=A0Enjoy Data
 "-"

Re: [Numpy-discussion] Re: Purchasing Documentation

[Colin J. W. <cj...@sy...>]

Perry Greenfield wrote:

> First of all, I certainly don't want to prevent Travis from recovering
> something for all the effort he has put into scipy_core. Nor do I wish
> to discourage anyone that wishes to provide alternative free 
> documentation
> if they so choose. But I will note some facts about numarray 
> documentation
> below that may prove useful to anyone considering the latter.
>
> On Oct 4, 2005, at 1:32 AM, Tim Churches wrote:
>
>> Paul F. Dubois wrote:
>>
>>> The original sources were in Framemaker. I am not positive where they
>>> are. In any case they are copyrighted by the Regents of the University
>>> of California. I am not a lawyer and don't know what the 
>>> consequences of
>>> that are. LLNL granted free distribution of the printed document with
>>> the Numeric source code but I don't know what their position would 
>>> be on
>>> using their copyrighted text in a new document or on giving away the
>>> sources.
>>
>
> The numarray User's Manual was derived from the Numpy manual that LLNL
> originally sponsored David Ascher to write (if that is incorrect I'm sure
> Paul will correct me). We dutifully propagated the legal notice in the
> original to the numarray version. Although IANAL I'll note that the
> text seems to permit changes by others, but it also seems mis-worded as
> it refers to software, not documentation regarding the rights. What that
> really means in the end I'm not sure.
>
> In any case, Jochen Kupper (I hope I have that right) converted the 
> format
> from Framemaker to the Python document latex style. The source for the
> numarray version is currently on sourceforge (under the numarray/doc
> directory). I'll also note much of the capabilities in scipy_core are
> very similar to those of numarray. There are differences, though I don't
> believe it would take a great deal of work to udpate the numarray version
> to reflect these (e.g. the changes in the types system, how rank-0
> issues, the C-API, object array details and the names of the standard
> packages within scipy_core.)
>
>> OK, thanks Paul. That may have implications for you, Travis, if you are
>> planning to base your SciPy Core book on the existing NumPy 
>> documentation.
>>
> From what I've seen of it, I don't believe it is based at all on the
> original manual or any derivative, but I'll leave that for Travis to
> comment further on.
>
> Perry
>
>
Perry,

It would be helpful if you gave some indication of your organization's 
intention with respect to numarray.

Will it be maintained, as in the past, fully in the public domain and 
without charge for either the code or the API information needed to make 
use of the code?

New versions have been produced every few months, will this continue?

Colin W.

Re: [SciPy-user] Re: [SciPy-dev] Re: [Numpy-discussion] Purchasing Documentation

[Travis O. <oli...@ee...>]

Fernando Perez wrote:

> Travis Oliphant wrote:
>
>> Alan G Isaac wrote:
>>
>>
>>> I also plan to ask our library to purchase the book, but I am 
>>> concerned that your statement that multiple users each need their 
>>> own copy might mean a library purchase is forbidden.  I assume it 
>>> did not mean that, and that you just meant that making multiple 
>>> copies is restricted.  (Our library supports electronic book check 
>>> out.)  Ruling out library purchases would, I think, be a costly 
>>> mistake for many reasons, which I can list if you are interested.
>>>
>>
>> A library purchase is fine.   If that how a single copy is shared.  
>> I'll make that more clear.  But, really, if multiple users need to 
>> use it at the same time, then the library should purchase several 
>> copies. 
>
>
> 'a single printed copy can be made from the electronic version, which 
> is subject to the same restrictions imposed on paper books (lending is 
> OK but not wholesale photocopying for redistribution, for example)'
>
> This would put at ease a lot of people who normally buy a book in a 
> lab or research group with the natural assumption that anyone in that 
> lab can go to the shelf and read it.  Obviously if it's a book with 
> very frequent use, traditional book purchasers buy multiple copies.  
> With your book, the exact same thing would be expected: just because 
> they have the PDF doesn't mean they can print 10 copies of it for the 
> whole lab.  Or at least that's my understanding.
>
Thanks, I like this wording.  It is exactly what I meant.   

I also think except for a library-checkout system (where only one 
digital copy is in circulation), somebody should not be able to buy an 
e-copy and then make electronic copies for everybody in their 
organization.   That's really quite counter productive.  If you want to 
share your e-copy with someone for a while (or give it away) fine...   
I'm really just asking that you treat the e-copy something like a 
physical book.  

I'll make some more details concerning the intent, available.  Thanks 
for everybody's help.

-Travis

Re: [SciPy-dev] Re: [Numpy-discussion] Purchasing Documentation

[Fernando P. <Fer...@co...>]

Travis Oliphant wrote:
> Alan G Isaac wrote:
> 
> 
>>I also plan to ask our library to purchase the book, but 
>>I am concerned that your statement that multiple users each 
>>need their own copy might mean a library purchase is 
>>forbidden.  I assume it did not mean that, and that you 
>>just meant that making multiple copies is restricted.  (Our 
>>library supports electronic book check out.)  Ruling out 
>>library purchases would, I think, be a costly mistake for 
>>many reasons, which I can list if you are interested. 
>> 
>>
> 
> A library purchase is fine.   If that how a single copy is shared.  I'll 
> make that more clear.  But, really, if multiple users need to use it at 
> the same time, then the library should purchase several copies. 

Travis,  I think that what confused some people (and which I believe was not 
your original intent) was the impression that you meant to have terms on the 
printed version of the book which were more restrictive than those of 
traditional paper books.

With a single physical copy of a paper book, the rules are pretty simple and 
constrained by the laws of nature (one non-quantum object can't really be in 
more than one place at the same time).  Lending, borrowing, library use, 'lab 
bench' use, etc, are all accepted practices because while one person is using 
the book, nobody else has access to it.

Since your book is originally provided electronically, there is the technical 
possiblity to make multiple physical copies, which I believe is what you wish 
to prevent (and something I'm not arguing with).

So perhaps a clarification along the lines of the following could help (this 
is my wording, of course, so you should say what _you_ want, not what I get 
from trying to read your mind :)

'a single printed copy can be made from the electronic version, which is 
subject to the same restrictions imposed on paper books (lending is OK but not 
wholesale photocopying for redistribution, for example)'

This would put at ease a lot of people who normally buy a book in a lab or 
research group with the natural assumption that anyone in that lab can go to 
the shelf and read it.  Obviously if it's a book with very frequent use, 
traditional book purchasers buy multiple copies.  With your book, the exact 
same thing would be expected: just because they have the PDF doesn't mean they 
can print 10 copies of it for the whole lab.  Or at least that's my understanding.

Best regards,

Fernando.

Re[2]: [SciPy-dev] Re: [Numpy-discussion] Purchasing Documentation

[Alan G I. <ai...@am...>]

On Tue, 04 Oct 2005, Travis Oliphant apparently wrote: 
> A library purchase is fine.   If that how a single copy is shared.  I'll 
> make that more clear.  But, really, if multiple users need to use it at 
> the same time, then the library should purchase several copies. 

Our library supports single copy checkout.
I think this currently is a pretty standard library 
function these days.


> My only question about writing "free" documentation, is that it just 
> seems rather wasteful to spend time writing free documentation when you 
> can set free the documentation by spending a little money instead.

I've done my part.  ;-)

Cheers,
Alan Isaac

Re: [SciPy-dev] Re: [Numpy-discussion] Purchasing Documentation

[Travis O. <oli...@ee...>]

Alan G Isaac wrote:

>I also plan to ask our library to purchase the book, but 
>I am concerned that your statement that multiple users each 
>need their own copy might mean a library purchase is 
>forbidden.  I assume it did not mean that, and that you 
>just meant that making multiple copies is restricted.  (Our 
>library supports electronic book check out.)  Ruling out 
>library purchases would, I think, be a costly mistake for 
>many reasons, which I can list if you are interested. 
>  
>
A library purchase is fine.   If that how a single copy is shared.  I'll 
make that more clear.  But, really, if multiple users need to use it at 
the same time, then the library should purchase several copies. 

>Finally, I agree with Tim that seven years is too long and 
>at the price I'd hope for a paperback copy.  I think 
>a better strategy would be two years copy protection, with 
>an updated edition every two years.  (But then I am not 
>writing the code!)  T
>
Thanks for the feedback.  I'm experimenting with the right combination 
of total price and total time so feedback is welcomed.  I want to 
encourage people who can really afford the book to spend the money on 
it.   What is the "right" time/$$ combination that will encourage this.  
I'm willing to shorten the time and come down on the total price.  They 
are set so I cannot increase them.  But, there is no problem with 
lowering them.

I could also support the idea of a cheaper total price 1st edition with 
a need to spend for the 2nd edition again.  Thanks for the feedback.

>he basic concept is really nice, as 
>long as it does not make it harder for you to 
>- fully document your code, 
>- smile on the free documentation that emerges, and 
>- keep your sunny disposition. 
>  
>
Don't worry, I'm not banking my future on this little experiment, so I 
won't worry about what other people do.   In fact, as John Hunter 
inferred, I would be thrilled by more contributions however they come.   
I just want to see more people use Python for scientific computing, and 
am trying some things out to help it along.

My only question about writing "free" documentation, is that it just 
seems rather wasteful to spend time writing free documentation when you 
can set free the documentation by spending a little money instead.   If 
you think I'm charging too much (either in $$ or time-delay), then 
continue to give me feedback.     I am interested in what works.

-Travis

[Numpy-discussion] Re: [SciPy-user] Release of SciPy Core 0.4 (Beta)

[Travis O. <oli...@ee...>]

Rob Managan wrote:

> Does the new scipy_core support the Numeric function 
> PyArray_FromDimsAndData?
>
> I use that to create a front end to a stand alone program that 
> generates a lot of arrays that I want to be able to query. Not the 
> best approach maybe but it works!
>
Yes,

All of the old Numeric C-API is available (I believe...).  Direct access 
to descr->one and descr->zero does not work anymore, though (it's 
replaced with a function call).

If you look at the source, you will see that these older calls are all 
special cases of the call to

PyArray_New()



-Travis

Re: [Numpy-discussion] Re: Purchasing Documentation

[Tim C. <tc...@op...>]

John Hunter wrote:
>>>>>>"Tim" == Tim Churches <tc...@op...> writes:
> 
> 
>     Tim> Yes, I agree entirely. Travis, you are at perfect liberty to
>     Tim> create commercial documentation for SciPy Core, but please
>     Tim> don't object if others try to organise to create free open
>     Tim> source documentation as well.
> 
> Object?  I'll bet dollars to doughnuts that Travis would be delighted
> to see this, just as he would have been at any time over the last
> several years.  And be careful: Perry still owes me a doughnut.

Travis did indeed object, which surprised me. Verbatim:

Tim C:
>> I think there needs to be some community debate about this. Is there
>> sufficient interest for people other than Travis to start with the
>> Numeric documentation and update it as necessary to become a free
>> SciPy Core documentation? The NumPy documentation is available in
>> HTML format as the basis of this - perhaps the original source
>> (LaTeX?) for the Numeric docs is also available?

Travis:
> I don't know why you would want to undermine my efforts in this way
> by duplicating effort.   Perhaps, instead you could have people donate
> $$ instead of time to releasing the documentation.    I give away
> copies of the documentation to people who participate in the
> development process all the time (and that comes off the total price
> --- though I haven't advertised this as of yet).   So, why don't you
> encourage people who don't have the money to contribute to the project
> instead.

So, Travis seems to be proposing that he write his documentation book,
which will be available only on a commercial basis (or by barter for
development work) and which cannot be shared as a lab bench manual, and
that any effort to create freely available documentation for scipy.core
undermines his efforts.

Now, we are **extremely** grateful to Travis for rescuing NumPy from a
slow death by decay, and for saving us the pain of having to convert all
our code to numarray (whereas the conversion to scipy.core should be
much less painful). But the foregoing sets off alarm bells ringing in my
head... I really think it would be useful if Travis makes a clear and
unambiguous statement about where he stands on the free, open source
nature of both the scipy.core code AND on documentation for it, just so
we all know where we respectively stand.

I have stated my position (not that it really matters), but I will
re-iterate:

a) scipy.core deserves a basic set of documentation (similar to the
current NumPy documentation) which is available to everyone on exactly
the same basis as the scipy.core code itself - that is, freely available
at no cost.

b) It is not Travis's duty to create such freely-available documentation.

c) Others at at liberty to create such freely-available documentation
for scipy.core if they so chose.

d) The documentation which Travis is proposing to write will not be made
freely available until targets of $300k in sales or 7 years have been
reached, and this effectively renders such documentation proprietary.

e) I think that the creation of proprietary supplementary documentation
for scipy.core, as Travis is doing, is a good idea and I will personally
buy several copies provided that the work is licensed in a reasonable
manner (eg sharing of single physical copies as a bench manual is
permitted).

Tim C

Re: [Numpy-discussion] how to use lu decomposition in lapack library?

[Piotr L. <lus...@cs...>]

Then you have to dig in deeper:

import numarray
import numarray.linear_algebra
import numarray.linear_algebra.lapack_lite2 as lapack_lite

piv = numarray.zeros((n,), "l")
outcome = lapack_lite.dgesv(n, nrhs, a, lda, piv, b, ldb, 0)

outcome['info'] is the 'info' parameter set by LAPACK.

You have to make sure that 'a' and 'b' are in Fortran order
because you're calling Fortran code. Here is a sample code:

>>> a=numarray.array([[1,2,3],[4,5,6]], 'd')
>>> a.is_fortran_contiguous()
0
>>> a.is_c_array()
True
>>> a.is_f_array()
0
>>> a.transpose()
>>> a.is_fortran_contiguous()
1
>>> a.is_c_array()
False
>>> a.is_f_array()
True

Call to 'transpose()' made it a Fortran array but it transposed
the array too.

Piotr

me...@ar... wrote:
> Thanks, Piotr!
> 
> What I actually want is the lower (L) and upper triangular matrix (U) 
> from matrix 'a'. How to get it?
> 
> Xiangyi
> 
> At 15:14 2005-10-4 -0400, you wrote:
> 
>> You would have to be more specific. If you just want to
>> solve a system of linear equations with matrix 'a' and
>> right-hand-side 'b':
>>
>> import numarray.linear_algebra as LA
>>
>> x = LA.solve_linear_equations(a, b)
>>
>> Unlike LAPACK, the above will leave your 'a' untouched.
>> So, if you have another right hand side 'b1' and the
>> same matrix 'a' you'll have to pay the cost of factorization
>> all over again.
>>
>> There is a way around it but I don't know what you really need.
>>
>> Piotr
>>
>> me...@ar... wrote:
>>
>>> Hi there-
>>> Can someone help me on this? Thanks!
>>> Best,
>>> Xiangyi
>>> Xiangyi Meng
>>> Department of Agricultural and Resource Economics
>>> Room 303, Giannini Hall #3310
>>> University of California, Berkeley
>>> Berkeley, CA 94720-3310
>>> Tel:  (510) 643-4124
>>> Fax: (510) 643-8911
>>> Email: me...@ar...
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by:
>>> Power Architecture Resource Center: Free content, downloads, 
>>> discussions,
>>> and more. http://solutions.newsforge.com/ibmarch.tmpl
>>> _______________________________________________
>>> Numpy-discussion mailing list
>>> Num...@li...
>>> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> 
> 
> Best,
> Xiangyi
> 
> Xiangyi Meng
> Department of Agricultural and Resource Economics
> Room 303, Giannini Hall #3310
> University of California, Berkeley
> Berkeley, CA 94720-3310
> Tel:  (510) 643-4124
> Fax: (510) 643-8911
> Email: me...@ar...
>          

Re: [Numpy-discussion] how to use lu decomposition in lapack library?

[Piotr L. <lus...@cs...>]

You would have to be more specific. If you just want to
solve a system of linear equations with matrix 'a' and
right-hand-side 'b':

import numarray.linear_algebra as LA

x = LA.solve_linear_equations(a, b)

Unlike LAPACK, the above will leave your 'a' untouched.
So, if you have another right hand side 'b1' and the
same matrix 'a' you'll have to pay the cost of factorization
all over again.

There is a way around it but I don't know what you really need.

Piotr

me...@ar... wrote:
> Hi there-
> 
> Can someone help me on this? Thanks!
> 
> Best,
> Xiangyi
> 
> Xiangyi Meng
> Department of Agricultural and Resource Economics
> Room 303, Giannini Hall #3310
> University of California, Berkeley
> Berkeley, CA 94720-3310
> Tel:  (510) 643-4124
> Fax: (510) 643-8911
> Email: me...@ar...
>          
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

[Numpy-discussion] how to use lu decomposition in lapack library?

[<me...@ar...>]

Hi there-

Can someone help me on this? Thanks!

Best,
Xiangyi

Xiangyi Meng
Department of Agricultural and Resource Economics
Room 303, Giannini Hall #3310
University of California, Berkeley
Berkeley, CA 94720-3310
Tel:  (510) 643-4124
Fax: (510) 643-8911
Email: me...@ar...
           

[Numpy-discussion] Re: Purchasing Documentation

[RayS <ra...@bl...>]

As a lurker and neophyte user of Numeric/numarray, I inject my perspective...

 >the existing documentation for
 >NumPy is not fantastic - some aspects of it are positively
 >obscure - but overall it is better than good-enough

I disagree here - I have found the docs to be a real stumbling block 
to learning and putting new (to me) methods to use.
There is often a very high level of C and/or specific math 
familiarity assumed; I spend a large amount of time in those 
instances Googling for example code (usually not much Numpy code is 
just sitting, posted online) and Usenet examples and discussion. I 
then spent time at the prompt testing up my own examples.

The printed Python books are usually very good resources, 
unfortunately, there is too much competition for general, intro 
Python and not enough depth into specific areas. This is the classic 
Publishers Dilemma. I am buying the new wx book, myself. A similar, 
in-depth book on Numpy does interest me at $29-$39, and Ch2 seems to 
be nicely done. Hopefully the new scipy_core will have the low 
overhead of Numeric for small arrays. Does it have easy access to the 
pointer to the array memory, as in numarray? (for use with ctypes.memmove())

That said, I still like more examples. People learn in different 
ways. I still maintain some PHP web sites, and the best (some say 
only ;-) ) thing is their style of online docs with user comments, ex.:
array-rand: http://www.php.net/manual/en/function.array-rand.php
I you need to do a particular Thing, it is very likely to already be 
_in_ the docs.
I think this is a better approach than Wikis, and is easier and more 
likely for users to contribute, like this:
http://www.php.net/manual/add-note.php?sect=index&redirect=http://www.php.net/manual/en/index.php
(Notice also:
"Please note that periodically, the developers may go through the 
notes and incorporate the information in them into the documentation. 
This means that any note submitted here becomes the property of the 
PHP Documentation Group.")


Ray Schumacher
hobby: http://rjs.org/astro/1004x/Python/

Re: [SciPy-dev] Re: [Numpy-discussion] Purchasing Documentation

[Eric J. <jo...@co...>]

I wanted to echo isaac's point: 

> I also plan to ask our library to purchase the book, but 
> I am concerned that your statement that multiple users each 
> need their own copy might mean a library purchase is 
> forbidden.  I assume it did not mean that, and that you 
> just meant that making multiple copies is restricted.  (Our 
> library supports electronic book check out.)  Ruling out 
> library purchases would, I think, be a costly mistake for 
> many reasons, which I can list if you are interested. 


I couldn't agree more, although I'm not quite sure how a license could
be worded such that it would allow a library copy and prevent a lab
bench copy, which I think was Travis' intent. 

That said, have you considered selling "site licenses" of a sort? I know
my lab would pay a few hundred to get a PDF that we could just stick in
our fileserver and use in perpetuity. I know that right now there's
nothing -preventing- us from buying just one copy and doing that (other
than pesky copyright law), but we'd like to support the project. 

	   ...Eric

Re: [Numpy-discussion] Purchasing Documentation

[Alan G I. <ai...@am...>]

On Mon, 03 Oct 2005, Travis Oliphant apparently wrote: 
> I hope people can understand that the reality of scarcity 
> dictates that we coordinate efforts through some 
> mechanism.  The price mechanism has been the most 
> succesful large-scale mechanism yet developed. 

> I am interested in feedback.  If  you don't buy the book 
> because you think I'm asking too much money, then let me 
> know, as Tim has done. 

I found this an interesting approach to supporting the 
project.  I plan to buy the book when it is released.
Hmm, why wait?  I should put my money where my mouth is.
Just a moment ... ok, done.

I view the book as a *complement* to other documentation 
that will appear and as a way to support the project. 
I agree with Tim that freely accessible online documentation 
will and must become available as well.  As Chris notes, 
some of this can happen on the Wiki. 

I also plan to ask our library to purchase the book, but 
I am concerned that your statement that multiple users each 
need their own copy might mean a library purchase is 
forbidden.  I assume it did not mean that, and that you 
just meant that making multiple copies is restricted.  (Our 
library supports electronic book check out.)  Ruling out 
library purchases would, I think, be a costly mistake for 
many reasons, which I can list if you are interested. 

Finally, I agree with Tim that seven years is too long and 
at the price I'd hope for a paperback copy.  I think 
a better strategy would be two years copy protection, with 
an updated edition every two years.  (But then I am not 
writing the code!)  The basic concept is really nice, as 
long as it does not make it harder for you to 
- fully document your code, 
- smile on the free documentation that emerges, and 
- keep your sunny disposition. 

Cheers, 
Alan Isaac 

Re: [Numpy-discussion] Re: Purchasing Documentation

[Perry G. <pe...@st...>]

First of all, I certainly don't want to prevent Travis from recovering
something for all the effort he has put into scipy_core. Nor do I wish
to discourage anyone that wishes to provide alternative free 
documentation
if they so choose. But I will note some facts about numarray 
documentation
below that may prove useful to anyone considering the latter.

On Oct 4, 2005, at 1:32 AM, Tim Churches wrote:

> Paul F. Dubois wrote:
>> The original sources were in Framemaker. I am not positive where they
>> are. In any case they are copyrighted by the Regents of the University
>> of California. I am not a lawyer and don't know what the consequences 
>> of
>> that are. LLNL granted free distribution of the printed document with
>> the Numeric source code but I don't know what their position would be 
>> on
>> using their copyrighted text in a new document or on giving away the
>> sources.

The numarray User's Manual was derived from the Numpy manual that LLNL
originally sponsored David Ascher to write (if that is incorrect I'm 
sure
Paul will correct me). We dutifully propagated the legal notice in the
original to the numarray version. Although IANAL I'll note that the
text seems to permit changes by others, but it also seems mis-worded as
it refers to software, not documentation regarding the rights. What that
really means in the end I'm not sure.

In any case, Jochen Kupper (I hope I have that right) converted the 
format
from Framemaker to the Python document latex style. The source for the
numarray version is currently on sourceforge (under the numarray/doc
directory). I'll also note much of the capabilities in scipy_core are
very similar to those of numarray. There are differences, though I don't
believe it would take a great deal of work to udpate the numarray 
version
to reflect these (e.g. the changes in the types system, how rank-0
issues, the C-API, object array details and the names of the standard
packages within scipy_core.)

> OK, thanks Paul. That may have implications for you, Travis, if you are
> planning to base your SciPy Core book on the existing NumPy 
> documentation.
>
 From what I've seen of it, I don't believe it is based at all on the
original manual or any derivative, but I'll leave that for Travis to
comment further on.

Perry