Menu
▾
▴
numpy-discussion — Discussion list for all users of Numerical Python
You can subscribe to this list here.
| 2000 |
Jan
(8) |
Feb
(49) |
Mar
(48) |
Apr
(28) |
May
(37) |
Jun
(28) |
Jul
(16) |
Aug
(16) |
Sep
(44) |
Oct
(61) |
Nov
(31) |
Dec
(24) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(56) |
Feb
(54) |
Mar
(41) |
Apr
(71) |
May
(48) |
Jun
(32) |
Jul
(53) |
Aug
(91) |
Sep
(56) |
Oct
(33) |
Nov
(81) |
Dec
(54) |
| 2002 |
Jan
(72) |
Feb
(37) |
Mar
(126) |
Apr
(62) |
May
(34) |
Jun
(124) |
Jul
(36) |
Aug
(34) |
Sep
(60) |
Oct
(37) |
Nov
(23) |
Dec
(104) |
| 2003 |
Jan
(110) |
Feb
(73) |
Mar
(42) |
Apr
(8) |
May
(76) |
Jun
(14) |
Jul
(52) |
Aug
(26) |
Sep
(108) |
Oct
(82) |
Nov
(89) |
Dec
(94) |
| 2004 |
Jan
(117) |
Feb
(86) |
Mar
(75) |
Apr
(55) |
May
(75) |
Jun
(160) |
Jul
(152) |
Aug
(86) |
Sep
(75) |
Oct
(134) |
Nov
(62) |
Dec
(60) |
| 2005 |
Jan
(187) |
Feb
(318) |
Mar
(296) |
Apr
(205) |
May
(84) |
Jun
(63) |
Jul
(122) |
Aug
(59) |
Sep
(66) |
Oct
(148) |
Nov
(120) |
Dec
(70) |
| 2006 |
Jan
(460) |
Feb
(683) |
Mar
(589) |
Apr
(559) |
May
(445) |
Jun
(712) |
Jul
(815) |
Aug
(663) |
Sep
(559) |
Oct
(930) |
Nov
(373) |
Dec
|
|
From: Todd M. <jm...@st...> - 2005-11-21 15:14:02
|
Travis Oliphant wrote: > > I would appreciate understanding typically use cases for memory-mapped > files. I am not sure I understand why certain choices were made for > numarray's memmap and memmap slice classes. They seem like a lot of > "extra" stuff and I'm not sure what all that stuff is for. > > Rather than just copy these over, I would like to understand what > people typically want to do with memory-mapped files to see if scipy > core doesn't already provide that. > > For example, write now I can open a file, use mmap to obtain a memory > map object and then pass that object into frombuffer in scipy_core to > get an ndarray whose memory maps a file on disk. > Now, this ndarray can be sliced and indexed and manipulated all the > while referring to the file on disk (well technically, I suppose, the > memory-mapped object would need to be flushed to synchronize). > Now, I could see wanting to make the process of opening the file, > getting the mmap object and setting it's buffer to the array object a > little easier. Thus, a simple memmap class would be a useful > construct -- I could even see it inheriting from the ndarray directly > and adding a few methods. I guess I just don't see why one would > care about a memory-mapped slice object, when the mmaparray sub-class > would be perfectly useful. > There are a few extra capabilities which are supported in numarray's memmap: 1. slice insertion 2. slice deletion 3. memmap based array resizing Each of these things implicitly changes the layout of the underlying file. Whether or not these features get used or justify the complexity is another matter. Because of 32-bit address space exhaustion and swap file issues, memory mapping was a disappointment at STSCI so I'm doubtful we used these features ourselves. Regards, Todd > On a related, but orthogonal note: > > My understanding is that using memory-mapped files for *very* large > files will require modification to the mmap module in Python --- > something I think we should push. One part of that process would be > to add the C-struct array interface to the mmap module and the buffer > object -- perhaps this is how we get the array interface into Python > quickly. Then, if we could make a base-type mmap that did not use > the buffer interface or the sequence interface (similar to the > bigndarray in scipy_core) and therefore by-passed the problems with > Python in those areas, then the current mmap object could inherit from > the base class and provide current functionality while still exposing > the array interface for access to >2GB files on 64-bit systems. > > Who would like to take up the ball for modifying mmap in Python in > this fashion? > > -Travis > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > _______________________________________________ > Numpy-discussion mailing list > Num...@li... > https://lists.sourceforge.net/lists/listinfo/numpy-discussion |
|
From: <pe...@ce...> - 2005-11-21 15:05:12
|
On Wed, 16 Nov 2005, Colin J. Williams wrote: > scipy._import_tools.py has a comment referring to DEVELOPERS.TXT but I > don't find it in the Windows download. This is fixed in scipy core SVN repositoy. Up-to-date DEVELOPERS.TXT (that used to reside in scipy source directory) can be now found as scipy/doc/DISTUTILS.txt file. Pearu |
|
From: Travis N. V. <tr...@en...> - 2005-11-21 14:45:05
|
All, I'm posting this here in the hopes that someone that is passionate about=20 python/numeric/scipy will "answer the call": `Enthought, Inc. <http://www.enthought.com>`__ (Austin, TX, USA) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D **Job Description**: Position: IT Administrator --------------------------- Enthought is looking for an exceptional IT Administrator to manage the=20 IT infrastructure for it's Austin, TX offices. This person will have a=20 passion for supporting software development tools and environments. The=20 target server platforms include Linux (RedHat and Fedora), Windows XP,=20 and Solaris. Workstations are a mix of Windows and Linux. We're looking=20 for an Admin that focuses on supporting software developers. Desired Skills and Capabilities: * B.S. in Computer Science of other related field (preferably not MIS) * 5+ Years Experience in Enterprise IT Administration Role * Ability to program or script in a programming language or shell -=20 (Python, Perl and small C programs) * Ability to solve problems quickly and completely * Strong inter-personal and communication skills as well as a team=20 player in a group of highly talented software developers * Willingness to pitch in wherever needed * Interested in making developer's lives easier Duties: * Perform installation, patching and other server maintenance to ensure=20 security and stability of server infrastructure. * Maintain core infrastructure technologies such as Firewall, VPN,=20 apache web server, mail server, NIS, NFS, DNS, DHCP, SSH, network-wide=20 backups, RAID and Samba * Identify routine tasks and automate through shell/Python scripting * Perform on-call duties and out of hours maintenance as necessary * Configure Nortel phone system * Build RPMs for RH/FC Linux * Using development tools on Linux such as gcc/g++, make, autoconf, etc. * Working with Python and building & installing Python packages using=20 distutils * Support developer tools such as SVN repositories, bug trackers,=20 Software Project Management utilities Company: -------- Enthought is a scientific computing company located in downtown Austin,=20 Texas. Founded in 2001, it has grown nearly 100% per year both in staff=20 and revenue to become a stable and profitable technology company. This=20 growth has been possible because of Enthought=92s talented team and=20 because of our commitment to developing quality software. We strive to=20 combine advanced algorithm development with modern software practices,=20 such as component based architectures, application scripting, and=20 intuitive user interface design. We take a holistic approach to software=20 development, in which architects and developers team with technical=20 writers, human factors specialists, and project managers (always highly=20 technical individuals) to develop a complete solution for our customers. Much of our work is based on the Python programming language, and we are=20 actively engaged in open source development (www.scipy.org=20 <http://www.scipy.org>). We=92re lucky enough to work on interesting=20 problems and are looking for talented people to join us. Some of our=20 current efforts are in the areas of geophysics, electromagnetics, fluid=20 dynamics, micro-rheology, CAD, 2-D and 3-D visualization, and others.=20 All of these tools are developed as plug-ins into our Envisage=20 "Scientific IDE" framework. * **Contact**: Travis N. Vaught, CEO * **E-mail contact**: jo...@en... * **Web**: http://www.enthought.com/careers.htm --=20 ........................ Travis N. Vaught CEO Enthought, Inc. http://www.enthought.com ........................ |
|
From: Eduardo S. <egs...@ya...> - 2005-11-21 03:42:43
|
Dear naumarray and numpy community:
Could you tell me where can I get real life examples to apply numarray. I am a Python and numarray begineer.
Thanks
Eduardo Stark
---------------------------------
Correo Yahoo!
Comprueba qué es nuevo, aquí
http://correo.yahoo.es |
|
From: Eduardo S. <egs...@ya...> - 2005-11-21 03:42:43
|
Dear naumarray and numpy community:
Could you tell me where can I get real life examples to apply numarray. I am a Python and numarray begineer.
Thanks
Eduardo Stark
---------------------------------
Correo Yahoo!
Comprueba qué es nuevo, aquí
http://correo.yahoo.es |
|
From: Travis O. <oli...@ee...> - 2005-11-20 09:03:17
|
I would appreciate understanding typically use cases for memory-mapped files. I am not sure I understand why certain choices were made for numarray's memmap and memmap slice classes. They seem like a lot of "extra" stuff and I'm not sure what all that stuff is for. Rather than just copy these over, I would like to understand what people typically want to do with memory-mapped files to see if scipy core doesn't already provide that. For example, write now I can open a file, use mmap to obtain a memory map object and then pass that object into frombuffer in scipy_core to get an ndarray whose memory maps a file on disk. Now, this ndarray can be sliced and indexed and manipulated all the while referring to the file on disk (well technically, I suppose, the memory-mapped object would need to be flushed to synchronize). Now, I could see wanting to make the process of opening the file, getting the mmap object and setting it's buffer to the array object a little easier. Thus, a simple memmap class would be a useful construct -- I could even see it inheriting from the ndarray directly and adding a few methods. I guess I just don't see why one would care about a memory-mapped slice object, when the mmaparray sub-class would be perfectly useful. On a related, but orthogonal note: My understanding is that using memory-mapped files for *very* large files will require modification to the mmap module in Python --- something I think we should push. One part of that process would be to add the C-struct array interface to the mmap module and the buffer object -- perhaps this is how we get the array interface into Python quickly. Then, if we could make a base-type mmap that did not use the buffer interface or the sequence interface (similar to the bigndarray in scipy_core) and therefore by-passed the problems with Python in those areas, then the current mmap object could inherit from the base class and provide current functionality while still exposing the array interface for access to >2GB files on 64-bit systems. Who would like to take up the ball for modifying mmap in Python in this fashion? -Travis |
|
From: Jordan D. <jdawe@u.washington.edu> - 2005-11-19 19:30:32
|
I just tried to install scipy under cygwin using both 0.61 and the current svn. I get this: gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o -L/usr/lib/python2.4/config -lpython2.4 -o build/lib.cygwin-1.5.18-i686-2.4/scipy/base/umath.dll build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `UBYTE_multiply': /usr/local/core/build/src/scipy/base/src/umathmodule.c:2215: undefined reference to `_feraiseexcept' build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `USHORT_multiply': /usr/local/core/build/src/scipy/base/src/umathmodule.c:2233: undefined reference to `_feraiseexcept' build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `UINT_multiply': /usr/local/core/build/src/scipy/base/src/umathmodule.c:2251: undefined reference to `_feraiseexcept' build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `ULONG_multiply': /usr/local/core/build/src/scipy/base/src/umathmodule.c:2269: undefined reference to `_feraiseexcept' build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `BYTE_multiply': /usr/local/core/build/src/scipy/base/src/umathmodule.c:2305: undefined reference to `_feraiseexcept' build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o:/usr/local/core/build/src/scipy/base/src/umathmodule.c:2325: more undefined references to `_feraiseexcept' follow build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `PyUFunc_checkfperr': /usr/local/core/scipy/base/src/ufuncobject.c:475: undefined reference to `_fetestexcept' /usr/local/core/scipy/base/src/ufuncobject.c:475: undefined reference to `_feclearexcept' build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `PyUFunc_clearfperr': /usr/local/core/scipy/base/src/ufuncobject.c:506: undefined reference to `_fetestexcept' /usr/local/core/scipy/base/src/ufuncobject.c:506: undefined reference to `_feclearexcept' build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `PyUFunc_GenericFunction': /usr/local/core/scipy/base/src/ufuncobject.c:506: undefined reference to `_fetestexcept' /usr/local/core/scipy/base/src/ufuncobject.c:506: undefined reference to `_feclearexcept' build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `construct_reduce': /usr/local/core/scipy/base/src/ufuncobject.c:506: undefined reference to `_fetestexcept' /usr/local/core/scipy/base/src/ufuncobject.c:506: undefined reference to `_feclearexcept' collect2: ld returned 1 exit status build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `UBYTE_multiply': /usr/local/core/build/src/scipy/base/src/umathmodule.c:2215: undefined reference to `_feraiseexcept' build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `USHORT_multiply': /usr/local/core/build/src/scipy/base/src/umathmodule.c:2233: undefined reference to `_feraiseexcept' build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `UINT_multiply': /usr/local/core/build/src/scipy/base/src/umathmodule.c:2251: undefined reference to `_feraiseexcept' build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `ULONG_multiply': /usr/local/core/build/src/scipy/base/src/umathmodule.c:2269: undefined reference to `_feraiseexcept' build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `BYTE_multiply': /usr/local/core/build/src/scipy/base/src/umathmodule.c:2305: undefined reference to `_feraiseexcept' build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o:/usr/local/core/build/src/scipy/base/src/umathmodule.c:2325: more undefined references to `_feraiseexcept' follow build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `PyUFunc_checkfperr': /usr/local/core/scipy/base/src/ufuncobject.c:475: undefined reference to `_fetestexcept' /usr/local/core/scipy/base/src/ufuncobject.c:475: undefined reference to `_feclearexcept' build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `PyUFunc_clearfperr': /usr/local/core/scipy/base/src/ufuncobject.c:506: undefined reference to `_fetestexcept' /usr/local/core/scipy/base/src/ufuncobject.c:506: undefined reference to `_feclearexcept' build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `PyUFunc_GenericFunction': /usr/local/core/scipy/base/src/ufuncobject.c:506: undefined reference to `_fetestexcept' /usr/local/core/scipy/base/src/ufuncobject.c:506: undefined reference to `_feclearexcept' build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o: In function `construct_reduce': /usr/local/core/scipy/base/src/ufuncobject.c:506: undefined reference to `_fetestexcept' /usr/local/core/scipy/base/src/ufuncobject.c:506: undefined reference to `_feclearexcept' collect2: ld returned 1 exit status error: Command "gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.5.18-i686-2.4/build/src/scipy/base/src/umathmodule.o -L/usr/lib/python2.4/config -lpython2.4 -o build/lib.cygwin-1.5.18-i686-2.4/scipy/base/umath.dll" failed with exit status 1 Any suggestions? Jordan |
|
From: Sebastien M. <sm...@um...> - 2005-11-19 18:52:01
|
Curzio Basso <cur...@gm...> writes: > I get the following error compiling an extension module using numarray > 1.4.1 on Mac OSX 10.4: > ----- > building 'fmlio' extension > gcc-3.3 -fno-strict-aliasing -Wno-long-double -no-cpp-precomp > -mno-fused-madd -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DLINUX > -I/home/basso/usr/include/python -I/sw/include/python2.4 -c > src/fmlio.cpp -o > build/temp.darwin-8.3.0-Power_Macintosh-2.4/src/fmlio.o > In file included from /sw/include/python2.4/numarray/libnumarray.h:17, > from /sw/include/python2.4/numarray/numarray.h:6, > from src/fmlio.h:10, > from src/fmlio.cpp:2: > /sw/include/python2.4/numarray/nummacro.h:27: error: parse error before `;' > token There is a bug report for this problem: http://sourceforge.net/tracker/?func=detail&atid=450446&aid=1350954&group_id=1369 The problem has been fixed in FreeBSD: http://www.freebsd.org/cgi/cvsweb.cgi/ports/math/py-numarray/files/patch-Include::numarray::nummacro.h Maybe this patch could be applied to numarray ? Sébastien |
|
From: Curzio B. <cur...@gm...> - 2005-11-19 17:48:24
|
> I should correct myself: on Gentoo it compiles but I have version 1.3.1.
First of all, compilation fails also on Gentoo with version 1.4.1.
Second, I can reproduce the result trying to compile the following code:
--------------
#include <Python.h>
#include "numarray/libnumarray.h"
int main() {
return 0;
}
-------------
Compiling the above code as C++, I get the error already reported,
while compiling as C works fine. The reason is that at line 27 in
nummacro.h the C++ keyword "operator" is used. Would it be possible to
replace it with something else? like "operator_"? By the way, using
extern "C" {...}
does not help.
cheers
curzio
|
|
From: Curzio B. <cur...@gm...> - 2005-11-19 13:59:28
|
> the same happens with gcc-4. On Gentoo I can compile without problems. I should correct myself: on Gentoo it compiles but I have version 1.3.1. curzio |
|
From: Curzio B. <cur...@gm...> - 2005-11-19 13:33:10
|
Hi all,
I get the following error compiling an extension module using numarray
1.4.1 on Mac OSX 10.4:
-----
building 'fmlio' extension
gcc-3.3 -fno-strict-aliasing -Wno-long-double -no-cpp-precomp
-mno-fused-madd -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DLINUX
-I/home/basso/usr/include/python -I/sw/include/python2.4 -c
src/fmlio.cpp -o
build/temp.darwin-8.3.0-Power_Macintosh-2.4/src/fmlio.o
In file included from /sw/include/python2.4/numarray/libnumarray.h:17,
from /sw/include/python2.4/numarray/numarray.h:6,
from src/fmlio.h:10,
from src/fmlio.cpp:2:
/sw/include/python2.4/numarray/nummacro.h:27: error: parse error before `;'
token
error: command 'gcc-3.3' failed with exit status 1
-----
the same happens with gcc-4. On Gentoo I can compile without problems.
Did anyone else get a similar problem? Ah, and numarray.h is included
right after Python.h.
cheers
curzio
|
|
From: Todd M. <jm...@st...> - 2005-11-17 12:14:51
|
Nice catch Andrew, and very timely! Thanks, Todd Andrew Straw wrote: >Hi, > >I think there's a bug in the new __array_struct__ code in numarray CVS. > >Consider an object a which implements the __array_struct__ interface. If >one constructs a numarray "view" of this array using aview = >numarray.asarray(a), the numarray.ndarray instance does not keep a >reference to a.__array_struct__. Thus, a segfault may occur because >a.data can be freed although aview may attempt to access it. > >In particular code like this will crash: > >buf = numarray.asarray( array_struct_factory() ) # buffer is freed >buf[1] = 2 # attempt is made to write to the non-existant buffer, >causing a segfault > >I've "fixed" this issue with the following, which I'm sure is not the >right way, but it's all I can do at this point. > >diff -u -r1.130 numarraycore.py >--- Lib/numarraycore.py 4 Nov 2005 20:27:11 -0000 1.130 >+++ Lib/numarraycore.py 17 Nov 2005 11:38:29 -0000 >@@ -357,6 +357,7 @@ > a = None > if hasattr(sequence, "__array_struct__"): > a = >_numarray._array_from_array_struct(sequence.__array_struct__) >+ a._hack_to_hold_reference_ = sequence.__array_struct__ > elif (hasattr(sequence, "__array_shape__") and > hasattr(sequence, "__array_typestr__")): > typestr = sequence.__array_typestr__ > > >And while I'm at it, can the "from distutils.command.config import log" >be turned off in setup.py? I like to see those errors, warnings, and >status strings whiz past... > > >------------------------------------------------------- >This SF.Net email is sponsored by the JBoss Inc. Get Certified Today >Register for a JBoss Training Course. Free Certification Exam >for All Training Attendees Through End of 2005. For more info visit: >http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click >_______________________________________________ >Numpy-discussion mailing list >Num...@li... >https://lists.sourceforge.net/lists/listinfo/numpy-discussion > > |
|
From: Francesc A. <fa...@ca...> - 2005-11-17 11:59:34
|
A Dijous 17 Novembre 2005 12:41, Andrew Straw va escriure: > And while I'm at it, can the "from distutils.command.config import log" > be turned off in setup.py? I like to see those errors, warnings, and > status strings whiz past... +1 ;-) =2D-=20 >0,0< Francesc Altet =A0 =A0 http://www.carabos.com/ V V C=E1rabos Coop. V. =A0=A0Enjoy Data "-" |
|
From: Andrew S. <str...@as...> - 2005-11-17 11:41:42
|
Hi,
I think there's a bug in the new __array_struct__ code in numarray CVS.
Consider an object a which implements the __array_struct__ interface. If
one constructs a numarray "view" of this array using aview =
numarray.asarray(a), the numarray.ndarray instance does not keep a
reference to a.__array_struct__. Thus, a segfault may occur because
a.data can be freed although aview may attempt to access it.
In particular code like this will crash:
buf = numarray.asarray( array_struct_factory() ) # buffer is freed
buf[1] = 2 # attempt is made to write to the non-existant buffer,
causing a segfault
I've "fixed" this issue with the following, which I'm sure is not the
right way, but it's all I can do at this point.
diff -u -r1.130 numarraycore.py
--- Lib/numarraycore.py 4 Nov 2005 20:27:11 -0000 1.130
+++ Lib/numarraycore.py 17 Nov 2005 11:38:29 -0000
@@ -357,6 +357,7 @@
a = None
if hasattr(sequence, "__array_struct__"):
a =
_numarray._array_from_array_struct(sequence.__array_struct__)
+ a._hack_to_hold_reference_ = sequence.__array_struct__
elif (hasattr(sequence, "__array_shape__") and
hasattr(sequence, "__array_typestr__")):
typestr = sequence.__array_typestr__
And while I'm at it, can the "from distutils.command.config import log"
be turned off in setup.py? I like to see those errors, warnings, and
status strings whiz past...
|
|
From: Colin J. W. <cj...@sy...> - 2005-11-16 23:08:23
|
scipy._import_tools.py has a comment referring to DEVELOPERS.TXT but I don't find it in the Windows download. |
|
From: John H. <jdh...@ac...> - 2005-11-16 15:37:12
|
To compile numpy 24.2 on solaris 8, I needed to make the following change to Packages/RNG/Src/ranf.c #if !defined(__sgi) //int gettimeofday(struct timeval *, struct timezone *); //old int gettimeofday(); //new #endif Not sure why __sgi is defined... JDH |
|
From: Jeff R. <je...@ta...> - 2005-11-16 06:43:32
|
Greetings. I'm working with the Python Conference planning group, for a
conference to be held in Dallas in 2006. As you probably know from
postings to python-announce, this year, for the first time, we're having
a full day (Feb 23, 2006) of trainer-compensated tutorials, structured
as either half-day or full-day sessions.
From the feedback we received at last year's PyCon, there was a strong
interest in scientific/engineering uses of Python, which has a rich set
of tools and frameworks. We hope this year to dedicate one room on
Tutorial Day to such topics.
While I was looking over the submissions for the tutorials tonight, I
noticed there were none related to science/engineering. It would be
cool to have a half-day class on one of the underlying packages used
across disciplines.
Note that these are to be professionally-run half or full day classes,
suggested with handouts or notebooks. And the trainer will receive
monetary compensation, depending upon the number of attendees that
register for specific tutorials.
If you or someone on your staff is interested, there is more information at:
http://us.pycon.org/TX2006/CallForTutorials
While the submission deadline expires tonight, we have some flexibility.
Jeff Rush
|
|
From: RayS <ra...@bl...> - 2005-11-14 16:15:55
|
Has anyone implemented a fast, generic circular array buffer in Numpy? I didn't see one in the usual searches, but I don't want to re-invent one either. I did see a number of C implementations like http://www.codeproject.com/csharp/circularbuffer.asp (http://www.gois.ws/files/attach/200209/200209201850040.zip) which could be weave'd, I suppose. I have some previous implementations I've used, but what I had in mind was making a new FIFO class with attributes of address, state<None,reading,writing>, pointer, size etc., and methods like flush (if I implement it as a memmap) and other things, like queue has. The important part of the idea is that multiple threads and processes could fully access it. Currently, I will have an ADC process fill it, and other processes use it. I'll post code as I go, in any case. Ray |
|
From: Colin J. W. <cj...@sy...> - 2005-11-14 00:54:31
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Travis Oliphant wrote:
<blockquote cite="mid...@ee..." type="cite">Colin J.
Williams wrote: <br>
<br>
<blockquote type="cite"><br>
I have a package based on subclassing numarray, which is working
satisfactorily, and am looking at the possibility of transferring the
package to work under the revised Numeric. <br>
<br>
My feeling is that the transfer is probably feasible but that it would
be premature to work on it at this time. <br>
</blockquote>
<br>
That's unfortunate. The more feedback we get early on about
subclassing, the better. <br>
</blockquote>
<big>Release of a win32 binaries version would help - Thanks, I have
version 0.6 now. I assume that the
intent is to include the multi-dimensional array in the Python library
and thus that compatibility with current Python practices makes sense.</big><br>
<blockquote cite="mid...@ee..." type="cite">
<blockquote type="cite"><br>
One of the problems is the cluttered namespace, through the use of
"from X import *". This is a style which is deprecated, see page 401
of Alex Martelli's /Python in a Nutshell/. <br>
</blockquote>
<br>
You will have to be more specific about what you think is wrong. What
namespace is "cluttered" exactly. Just because use is made of from X
import * in one module does not mean everything is "cluttered". SciPy
Core makes use of the __all__ variables to control what gets imported
and usually only specific functions are imported as necessary. <br>
</blockquote>
<big>The number of names introduced in the namespace seems high: 422.<br>
<br>
New types, not all of which are clearly documented. For example:
_castDict, PyCObject, builtin_function_or_method, getset_descriptor,
instancemethod, member_descriptor, method_descriptor, ufunc,
wrapper_descriptor.<br>
<br>
There are 39 Python types. I can see merit in adding a ufunc type but
wonder about some of the others.<br>
<br>
See:<br>
</big>
<blockquote><big>>>> import scipy; import types<br>
>>> len(dir(types))<br>
39<br>
>>> len(dir(scipy))<br>
422<br>
>>> dir(types)<br>
['BooleanType', 'BufferType', 'BuiltinFunctionType',
'BuiltinMethodType', 'ClassType', 'CodeType', '<br>
ComplexType', 'DictProxyType', 'DictType', 'DictionaryType',
'EllipsisType', 'FileType', 'FloatType'<br>
, 'FrameType', 'FunctionType', 'GeneratorType', 'InstanceType',
'IntType', 'LambdaType', 'ListType',<br>
'LongType', 'MethodType', 'ModuleType', 'NoneType',
'NotImplementedType', 'ObjectType', 'SliceType'<br>
, 'StringType', 'StringTypes', 'TracebackType', 'TupleType',
'TypeType', 'UnboundMethodType', 'Unico<br>
deType', 'XRangeType', '__builtins__', '__doc__', '__file__',
'__name__']<br>
</big></blockquote>
<big>I have just downloaded 0.6 and will look at it. One immediate
impression is the massive size, nearly three times the latest numarray,
which has the basic functionality.<br>
<br>
Use is made of the "classic" class. Since Python is moving
towards 2.5, it would probably make sense to convert these to "new"
classes.<br>
</big>
<blockquote cite="mid...@ee..." type="cite">
<blockquote type="cite">Another problem, at this stage, is that many
doc strings are missing and that some which exist are a little cryptic.
<br>
</blockquote>
<br>
I would submit there are more docstrings then Numeric had. Jump in
and help. The water is fine. <br>
<br>
<blockquote type="cite"><br>
I would like to take another look when the next win32 binaries are
available. <br>
</blockquote>
<br>
There has been much improvement since the last beta. I'm trying to
track down some remaining memory leaks before releasing new windows
binaries. The SVN code is always available for check out and it is
quite easy to build. </blockquote>
<big>I tried to build some months ago and failed. The problem with
using the SVN code is that it is good for the Python scripts but there
is no assurance that the binaries are stable.</big><br>
<blockquote cite="mid...@ee..." type="cite">We could
always use more build testers to make
sure building is going as smoothly as we believe it is. <br>
<br>
<blockquote type="cite"><br>
Some further thoughts on the present state of Numeric3.0 are available
here <a class="moz-txt-link-rfc2396E"
href="http://www3.sympatico.ca/cjw/scipy1/"><http://www3.sympatico.ca/cjw/scipy1/></a>.
<br>
</blockquote>
<br>
<br>
Most of your comments have more to do with differences between builtin
types and Python classes than anything about scipy. The type-class
chasm has shrunken of late, but there are still remaining issues.
These are Python issues that I believe are of little concern. <br>
</blockquote>
<big>Among the other matters were the PEP 8 recommendation, view vs
reference (is one of these a typo?), <big><font
face="Arial, sans-serif"><font size="2"><big><big>Missing
special methods: Set(['__dict__', '__module__', '__weakref__']) and </big></big></font></font></big><font
face="Times New Roman, serif"><font size="3"><big>the
class associated with a method.</big></font></font></big><br>
<br>
<br>
<blockquote cite="mid...@ee..." type="cite"> <br>
I will comment on your issues that are not related to the above
comment: <br>
<br>
<br>
Use of package __init__.py to create namespace. <br>
<br>
If the epydoc and pydoc tools are not respecting the __init__.py code
then I would say they are broken. Using the __init__.py this way
frees the user from having to understand every little detail of the
package structure (which could also change as better organization is
obtained in the future). <br>
</blockquote>
<big>Python is modular in its approach. The created namespace loses
the benefits of a modular organization.</big><br>
<blockquote cite="mid...@ee..." type="cite"> <br>
<br>
Use of the from X import Y style <br>
<br>
Please give more support here. Just because one Python user advocates
against it is not sufficient argument. </blockquote>
<big>I suggest that Alex Martelli is more than just another Python
user. He is a knowledgeable and valued contributor to Python. He is a
developer with the <a href="http://gmpy.sourceforge.net/">gmpy project</a>.</big><br>
<blockquote cite="mid...@ee..." type="cite">There is
an argument to be made
for avoiding attribute lookups by importing the names directly in this
fashion. <br>
<br>
<br>
*Methods vs functions* <br>
<br>
I agree that methods and functions are somewhat redundant. However,
the functions are still needed both to support lists and especially for
back-wards compatibility. Your example using take is odd (perhaps it's
a bug in an old release). I get consistent behavior. One problem is
you define a 1-d array in one case and a 2-d array in another. Of
course the answers will be different. <big>I'll look at this.</big><br>
</blockquote>
<big>Use of static methods could reduce the need for functions and thus
the plethora of names, since the functions are closely associated with
a class hierarchy.<br>
<br>
I wonder about the push for backwards compatibility, isn't that better
handled through a compatibility module?<br>
</big>
<blockquote cite="mid...@ee..." type="cite">One
difference is that the default axis argument is different. The old
functions have exactly the same default axis argument as they always
did, while the methods have a default of None for the axis (which means
treat the array as flat). <br>
<br>
<br>
Lack of basic information in the doc strings <br>
<br>
Your examples are all class constructors. First of all, there is no
special __init__ method for the ndarray because __new__ takes care of
it. Second of all, the new method does need better documentation.
I'm not sure where to put it, though. The array_new function is
placed in the TypeObject of the array type. The __new__ attribute is
pasted on by PyTypeReady. I'm not sure how to give a docstring as
well. <br>
I suspect the proper thing to do is place the information in the
docstring for the Type Object. <br>
</blockquote>
<big>The usual approach is to use __new_ for to allocate space and
create the instance and for __init__ to initialize the instance. See
Thomas Wouters
(<a class="moz-txt-link-freetext" href="http://www.python.org/pycon/dc2004/papers/48/newstyle-classes.ppt">http://www.python.org/pycon/dc2004/papers/48/newstyle-classes.ppt</a>).<br>
<br>
Or see David Mertz's Example 4
(<a class="moz-txt-link-freetext" href="http://www.onlamp.com/pub/a/python/2003/04/17/metaclasses.html">http://www.onlamp.com/pub/a/python/2003/04/17/metaclasses.html</a>)<br>
<br>
Or see Greg Ewings section on initialization:
(<a class="moz-txt-link-freetext" href="http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/version/Doc/special_methods.html">http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/version/Doc/special_methods.html</a>)<br>
<br>
<br>
<br>
</big>
<blockquote cite="mid...@ee..." type="cite"> <br>
-Travis <br>
</blockquote>
<big>Thanks for version 0.6, I shall look at it.</big><br>
<br>
<big>Colin W.</big><br>
<blockquote cite="mid...@ee..." type="cite"> <br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</blockquote>
<br>
<br>
</body>
</html>
|
|
From: N. V. <mit...@we...> - 2005-11-12 23:24:43
|
Sorry to once again report a build error ;-) Numeric 24.1 builds just fine, while Numeric 24.2 produces the attaced messages (out.txt) and error messages (err.txt). HTH, Niklas. |
|
From: Todd M. <jm...@st...> - 2005-11-12 12:24:38
|
Francesc Altet wrote: >Hi, > >I've checked CVS numarray today and yes, the problem with strided arrays >seems to be gone. It does remain some small (I think) issue: > > > >>>>import Numeric;Numeric.__version__ >>>> >>>> >'24.1' > > >>>>import numarray;numarray.__version__ >>>> >>>> >'1.4.2' > > >>>>num=Numeric.array([0.,1.]) >>>>na=numarray.zeros(shape=2) >>>>na[...] = num >>>> >>>> >Traceback (most recent call last): > File "<stdin>", line 1, in ? >TypeError: NA_DescrFromType: unknown type: -1 > >and also: > > > >>>>numarray.array(num) >>>> >>>> >Traceback (most recent call last): > File "<stdin>", line 1, in ? > File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line >359, in array > a = _numarray._array_from_array_struct(sequence.__array_struct__) >TypeError: NA_DescrFromType: unknown type: -1 > >Regards, > > > This was a cut-and-pasto in numarray's scipy type definition table. It's fixed in CVS. Thanks, Todd |
|
From: Francesc A. <fa...@ca...> - 2005-11-11 08:50:20
|
Hi,
I've checked CVS numarray today and yes, the problem with strided arrays
seems to be gone. It does remain some small (I think) issue:
>>> import Numeric;Numeric.__version__
'24.1'
>>> import numarray;numarray.__version__
'1.4.2'
>>> num=3DNumeric.array([0.,1.])
>>> na=3Dnumarray.zeros(shape=3D2)
>>> na[...] =3D num
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: NA_DescrFromType: unknown type: -1
and also:
>>> numarray.array(num)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line
359, in array
a =3D _numarray._array_from_array_struct(sequence.__array_struct__)
TypeError: NA_DescrFromType: unknown type: -1
Regards,
--=20
>0,0< Francesc Altet http://www.carabos.com/
V V C=E1rabos Coop. V. Enjoy Data
"-"
|
|
From: <co...@ph...> - 2005-11-11 03:22:01
|
Travis Oliphant <oli...@ee...> writes: > I've finished altering the subversion repository of SciPy so that the > new development is taking place on the trunk of both scipy and scipy_core. > > The old versions are under branches named oldcore and oldscipy. > > Get the new repositor(y,ies) using: > > *Core*: > svn co http://svn.scipy.org/svn/scipy_core/trunk core > > *Full SciPy*: > svn co http://svn.scipy.org/svn/scipy/trunk scipy > > Doing both will place two directories named core and scipy in your > current directory containing the current state of both repositories. Alternatively, instead of doing a full checkout, you can switch your working copies: Within your (old) newcore directory: svn sw http://svn.scipy.org/svn/scipy_core/trunk and same for full scipy. -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |co...@ph... |
|
From: Travis O. <oli...@ee...> - 2005-11-11 00:29:34
|
I've finished altering the subversion repository of SciPy so that the new development is taking place on the trunk of both scipy and scipy_core. The old versions are under branches named oldcore and oldscipy. Get the new repositor(y,ies) using: *Core*: svn co http://svn.scipy.org/svn/scipy_core/trunk core *Full SciPy*: svn co http://svn.scipy.org/svn/scipy/trunk scipy Doing both will place two directories named core and scipy in your current directory containing the current state of both repositories. python setup.py install should work in each directory. The Freeze is now over. I want to track down the bug that Christopher Hanley noted and another f2py-related bug before making a release, which I expect to happen by the weekend. -Travis |
|
From: N. V. <mit...@we...> - 2005-11-10 19:09:14
|
>>With the knowledge, that it _should_ work, I have just retried to build >>scipy_core 0.4.2 on my rather fresh installation of Slackware Linux >>10.2 (python 2.4.1) and still couldn't get it to build. I have >>attached the log files out.txt and err.txt to this e-mail, which I got >>by typing >> >>$ python setup.py build 1>out.txt 2>err.txt >> >>in the scipy_core main directory. The two files are compressed into a >>single tar.gz archive (5k), because I do not know if 60k attachments are >>o.k. on this list. >> >>Maybe you can help me solve my problem? > > > Did you try a recent check out? > With Travis' speed of coding scipy_core version 0.4.2.1252 > seems pretty old to me > > I tested > In [95]: scipy.__core_version__ > Out[95]: '0.4.3.1440' > this morning without problems. That was a wonderful idea! I checked out 0.4.3.1456 and it works just fine. Thank you very much. BTW, I checked out the source via $ svn co http://svn.scipy.org/svn/scipy_core/branches/newcore which took me a while to find (it was on the conference paper about scipy). Best regards, Niklas. |
258 messages has been excluded from this view by a project administrator.
