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...> - 2003-07-17 10:29:02
|
On Wed, 2003-07-16 at 21:13, Dave Cole wrote: > >>>>> "Todd" == Todd Miller <jm...@st...> writes: > > Todd> I think however that memory mapping sequences or arbitrary > Todd> Python objects isn't going to happen in numarray any time soon; > Todd> it sounds too much like object persistence. > > It is used to minimize the cost of huge datasets. That's what we use it for too... but only for primitive data types. > > >> I know that is a big ask! We have an extension module which stores > >> variable length blobs in a single memory-mapped file which might be > >> useful - the code could be made available to the numarray project, > >> I think. > > Todd> I don't understand the difference between your module and > Todd> Python's mmap. > > The code could use probably the Python mmap module. It would be > difficult because all access to the Python mmap object is via Python. > > A CObject exported API in the Python mmap module would be very useful. > What do you want to get via the CObject API? Since any mmap can be treated as a buffer, it's easy to get a pointer and size via the Python buffer API in C. Is there something else you need? > - Dave -- Todd Miller <jm...@st...> |
From: <mi...@sa...> - 2003-07-17 08:02:07
|
English version | Русский вариант Мы рады предложить вам новый бесплатный почтовый сервис http://www.mail15.com. Его отличительные особенности: 1) размер ящика 15 мб; 2) защищенность и надежность; 3) возможность использования любых почтовых программ(POP,IMAP,SMTP); 4) доступ из любого места в любое время; 5) простой и доступный вебинтерфейс с ПОЛНЫМ ОТСУТСТВИЕМ РЕКЛАМЫ; 6) антивирусный и антиспамовый контроль; 7) мгновенная пересылка почты. Если вы не хотите получать более данную рассылку, пишите mailto:uns...@ma...?subject=unsubscribe ************* We are glad to invite you at new free mail service http://www.mail15.com. The advantages of this service are: 1) mailbox, up to 15 Mb; 2) absolute privacy and high reliability; 3) ability to use mail clients (POP3, IMAP4, SMTP); 4) access from anywhere, anytime; 5) flexible light-weight web interface without advertising banners; 6) antivirus and antispam control; 7) fast mail transfer; 8) high speed network channel; 9) flexible light-weight web interface; 10) wide spread ability of mail filtering and forwarding mail; 11) clock around support; If you wish to be removed: mailto:uns...@ma...?subject=unsubscrib wRhv8A69w9 |
From: Dave C. <dj...@ob...> - 2003-07-17 01:13:22
|
>>>>> "Todd" == Todd Miller <jm...@st...> writes: Todd> I think however that memory mapping sequences or arbitrary Todd> Python objects isn't going to happen in numarray any time soon; Todd> it sounds too much like object persistence. It is used to minimize the cost of huge datasets. >> I know that is a big ask! We have an extension module which stores >> variable length blobs in a single memory-mapped file which might be >> useful - the code could be made available to the numarray project, >> I think. Todd> I don't understand the difference between your module and Todd> Python's mmap. The code could use probably the Python mmap module. It would be difficult because all access to the Python mmap object is via Python. A CObject exported API in the Python mmap module would be very useful. - Dave -- http://www.object-craft.com.au |
From: Todd M. <jm...@st...> - 2003-07-16 22:36:22
|
On Wed, 2003-07-16 at 17:43, Tim Churches wrote: > On Wed, 2003-07-16 at 05:34, Todd Miller wrote: > > I am adding arrays of Python objects to numarray and so I am curious > > about the uses people have found for Numeric's object arrays. If you > > have found Numeric's object arrays useful, please tell us about what > > you used them for so that we can make certain that numarray can satisfy > > the same need. > > We use NumPy to store vectors (rank-1 arrays) of numbers representing > columns in a dataset. The NumPy arrays, which are large and numerous) > are memory-mapped (using an extension) to disc to conserve real memory. > However, in some vectors (columns) we need to store variable-length, and > in others, variable length sequences of integers or floats (and possibly > even sets in the future). NumPy's object arrays are more > memory-efficient that Python lists of lists or lists of strings from Well, right now the prototype actually uses a single list internally as the object store; still, we might beat out lists of lists by a small margin. > these purposes, and of course they support NumPy functions such as > take(), which makes life simpler. The prototype currently uses common code for put/take on strings, object arrays, and soon record arrays. The common code is currently Python prototype. Numarray numeric arrays use specialized C-code for speed. > But we haven't been able to memory-map > these object arrays, which is a problem. Is there any prospect of > numarray supporting memory-mapped arrays of sequences/strings? numarray supports arrays of fixed length strings with its chararray module. The default chararray string stripping and padding functions blank fill unused space and give the appearance of variable length strings. The data buffers of all of numarray's classes which represent primitive data items (numbers, strings, records) can be memory mapped. I think however that memory mapping sequences or arbitrary Python objects isn't going to happen in numarray any time soon; it sounds too much like object persistence. > I know > that is a big ask! We have an extension module which stores variable > length blobs in a single memory-mapped file which might be useful - the > code could be made available to the numarray project, I think. I don't understand the difference between your module and Python's mmap. > > We also use MA extensively (because in the health care domain life is > full of missing data) - I'll jot down some thoughts on how MA could be > improved in the next few days. I'd be very interested in hearing your thoughts on improving MA. -- Todd Miller <jm...@st...> |
From: Tim C. <tc...@op...> - 2003-07-16 21:45:28
|
On Wed, 2003-07-16 at 05:34, Todd Miller wrote: > I am adding arrays of Python objects to numarray and so I am curious > about the uses people have found for Numeric's object arrays. If you > have found Numeric's object arrays useful, please tell us about what > you used them for so that we can make certain that numarray can satisfy > the same need. We use NumPy to store vectors (rank-1 arrays) of numbers representing columns in a dataset. The NumPy arrays, which are large and numerous)=20 are memory-mapped (using an extension) to disc to conserve real memory. However, in some vectors (columns) we need to store variable-length, and in others, variable length sequences of integers or floats (and possibly even sets in the future). NumPy's object arrays are more memory-efficient that Python lists of lists or lists of strings from these purposes, and of course they support NumPy functions such as take(), which makes life simpler. But we haven't been able to memory-map these object arrays, which is a problem. Is there any prospect of numarray supporting memory-mapped arrays of sequences/strings? I know that is a big ask! We have an extension module which stores variable length blobs in a single memory-mapped file which might be useful - the code could be made available to the numarray project, I think. We also use MA extensively (because in the health care domain life is full of missing data) - I'll jot down some thoughts on how MA could be improved in the next few days. --=20 Tim C PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere or at http://members.optushome.com.au/tchur/pubkey.asc Key fingerprint =3D 8C22 BF76 33BA B3B5 1D5B EB37 7891 46A9 EAF9 93D0 |
From: Todd M. <jm...@st...> - 2003-07-16 17:49:55
|
On Wed, 2003-07-16 at 13:34, Konrad Hinsen wrote: > On Wednesday 16 July 2003 18:29, you wrote: > > > Support for universal functions (calling numarray.add(a,b) rather than > > a+b) and the C-API for object arrays is still missing. Did these matter > > to your application of object arrays? > > Not add(a, b), but add.reduce(a) as well as things like log(a). OK. That makes sense. I have a fair amount of work left to do... > Konrad. -- Todd Miller <jm...@st...> |
From: Konrad H. <hi...@cn...> - 2003-07-16 17:35:18
|
On Wednesday 16 July 2003 18:29, you wrote: > Support for universal functions (calling numarray.add(a,b) rather than > a+b) and the C-API for object arrays is still missing. Did these matte= r > to your application of object arrays? Not add(a, b), but add.reduce(a) as well as things like log(a). Konrad. --=20 -------------------------------------------------------------------------= ------ Konrad Hinsen | E-Mail: hi...@cn... Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------= ------ |
From: Todd M. <jm...@st...> - 2003-07-16 16:29:31
|
On Wed, 2003-07-16 at 05:26, Konrad Hinsen wrote: > On Tuesday 15 July 2003 21:34, Todd Miller wrote: > > I am adding arrays of Python objects to numarray and so I am curious > > about the uses people have found for Numeric's object arrays. If you > > have found Numeric's object arrays useful, please tell us about what > > you used them for so that we can make certain that numarray can satisfy > > the same need. > > I have used them several times in order to be able to use array operations on > number-like objects, e.g. multiple precision numbers, quaternions, automatic > derivatives, polynomials, etc. OK. Right now the prototype supports array structural operations (indexing, slicing, array indexing, copies, views, transpose...) and element-wise operator application (so when you add two object arrays, the corresponding objects are added using the number protocol). Support for universal functions (calling numarray.add(a,b) rather than a+b) and the C-API for object arrays is still missing. Did these matter to your application of object arrays? -- Todd Miller <jm...@st...> |
From: Konrad H. <hi...@cn...> - 2003-07-16 09:26:55
|
On Tuesday 15 July 2003 21:34, Todd Miller wrote: > I am adding arrays of Python objects to numarray and so I am curious > about the uses people have found for Numeric's object arrays. If you > have found Numeric's object arrays useful, please tell us about what > you used them for so that we can make certain that numarray can satisfy > the same need. I have used them several times in order to be able to use array operation= s on=20 number-like objects, e.g. multiple precision numbers, quaternions, automa= tic=20 derivatives, polynomials, etc. Konrad. --=20 -------------------------------------------------------------------------= ------ Konrad Hinsen | E-Mail: hi...@cn... Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------= ------ |
From: Todd M. <jm...@st...> - 2003-07-15 19:31:43
|
I am adding arrays of Python objects to numarray and so I am curious about the uses people have found for Numeric's object arrays. If you have found Numeric's object arrays useful, please tell us about what you used them for so that we can make certain that numarray can satisfy the same need. Thanks, Todd -- Todd Miller jm...@st... STSCI / ESS / SSB |
From: <23...@ma...> - 2003-07-15 01:01:52
|
<html> <head> <title>DVD Magic Pro</title> </head> <font color="#FFFFFF" size="2"> ************ 19B2F07C-2133E8C4-1D563275-6BC750C9-2D6BC3B9 ******* </font><body><table border="4" cellpadding="0" cellspacing="0" style="border-collapse: collapse" bordercolor="#00009D" width="460" bgcolor="#000080" bordercolorlight="#3366CC" bordercolordark="#000080" height="44"> <tr> <td width="163" height="44" bgcolor="#FFFFFF" bordercolor="#000000" style="border: 1px solid #000000"> <p align="center"><i><b><font size="4" color="#000080" face="Tahoma">DVD Magick Pro</font></b></i></td> <td width="294" height="44" style="border: 2px solid #3366CC"> <p align="center"><b><font face="Tahoma" color="#FFFFFF">A Revolutionary Way to Create DVDs in Your Own Home!</font></b></td> </tr> </table> <table border="3" cellpadding="5" cellspacing="5" style="border-collapse: collapse" bordercolor="#3366CC" width="460" bgcolor="#3366CC" bordercolorlight="#0066CC" bordercolordark="#0066CC"> <tr> <td> <p align="center"><font face="Arial" color="#FFFFFF"> <marquee behavior="slide" scrollamount="25" scrolldelay="40" style="color: #FFFFFF; font-family: Arial; font-size: 14pt" width="320">Want to Create your own DVD library?</marquee><br> Worried about scratching your favorite movie?<br>We have THE solution for you!<br> <marquee behavior="slide" scrollamount="5" scrolldelay="50" width="316" style="color: #FFFFFF; font-family: Arial; font-size: 12pt; font-weight: bold">Now you can Make DVD's using your PC!</marquee><br> It's easy to use, and For a limited time it is <b><u>Only $39.99!</u></b></font></td> </tr> </table> <table border="4" cellpadding="5" cellspacing="5" style="border-collapse: collapse" bordercolor="#3366CC" width="460" bgcolor="#000080" bordercolorlight="#0066CC" bordercolordark="#0066CC"> <tr> <td align="left"> <p><b><font color="#FFFFFF" size="2" face="Tahoma">- Instant Download!<br>- No DVD Burner Required<br> - Simple & Easy-to-Use<br>- Win 95/98/2k/XP Compatible</font></b></td> <td bgcolor="#FFFFFF" style="text-decoration: blink; color: #000080; font-family: Tahoma; font-size: 12pt; font-weight: bold; border-style: solid; border-width: 3"> <p align="center"><span style="font-weight: 400"><i><strong><blink> <a style="color: #000080; font-family: Tahoma; font-size: 12pt; text-decoration: blink; font-style: oblique; font-weight: bold" href="http://www.pro2security.biz/dvd/adv166/"> <font face="Tahoma" color="#000080" size="4">Click Here for More Info or <br>Order Online Now!</font></a></blink></strong></i></span></td> </tr> </table> <font color="#FFFFFF" size="1"> 238122 CA69F28-50670039-739B9C74-3579F98C-5EF8077F 551770021 </font> </body> </html> |
From: <vi...@ya...> - 2003-07-11 18:03:36
|
DQo8Ym9keT4NCg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToNCjEyLjBwdDtm b250LWZhbWlseTpBcmlhbCI+cGxlYXNlIG5vdGUgdG8gc2VuZCBBTEwgUkVQTFkgZS1tYWls IGRpcmVjdCB0byBvdXIgDQpTYWxlcyBSZXByZXNlbnRhdGl2ZSBhdDogPG86cD4NCjwvbzpw Pg0KPC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bXNvLWJpZGktZm9udC1zaXplOg0K MTIuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48YSBocmVmPSJtYWlsdG86UXVlc3Rpb25zQFBl cmZlY3RXYXRjaFBpZWNlLmNvbSI+UXVlc3Rpb25zQFBlcmZlY3RXYXRjaFBpZWNlLmNvbTwv YT48bzpwPg0KPC9vOnA+DQo8L3NwYW4+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDttc28tYmlk aS1mb250LXNpemU6DQoxMi4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwiPiZuYnNwOzxvOnA+DQo8 L286cD4NCjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPkhpLCZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmsgeW91IGZvciBleHByZXNzaW5nIGludGVyZXN0IGlu IA0KQVRHV1Mgd2F0Y2hlcy48YnI+DQpXZSB3b3VsZCBsaWtlIHRvIHRha2UgdGhpcyBvcHBv cnR1bml0eSB0byBvZmZlciB5b3Ugb3VyIGZpbmUgc2VsZWN0aW9uIG9mIA0KSXRhbGlhbiBj cmFmdGVkIFJvbGV4IFRpbWVwaWVjZXMuJm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Zb3UgY2FuIHZpZXcgb3VyIGxhcmdlIHNl bGVjdGlvbiBvZiANClJvbGV4ZXMgKGluY2x1ZGluZyBCcmVpdGxpbmcsIFRhZyBIZXVlciwg Q2FydGllciBldGMpIGF0OjxiciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVyOmxpbmUt YnJlYWsiPg0KPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48YSBocmVmPSJodHRwOi8vd3d3LnBlcmZlY3R3YXRjaHBpZWNlLmNvbS8iPnd3 dy5QZXJmZWN0V2F0Y2hQaWVjZS5jb208L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDs8bzpwPg0KPC9vOnA+DQo8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPkZvciBhbGwgb3JkZXJzIHBsYWNlZCBpbiB0aGUgbW9udGgg b2YgDQpKdWx5LCA8Yj5hbGwgc2hpcHBpbmcgYW5kIGhhbmRsaW5nIGNoYXJnZXMgd2lsbCBi ZSBmcmVlPC9iPi4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPkFzIHdlIGFyZSB0aGUgZGlyZWN0IG1hbnVmYWN0dXJlcnMsIHlv dSANCmFyZSBndWFyYW50ZWVkIG9mIGxvd2VzdCBwcmljZXMgYW5kIGhpZ2hlc3QgcXVhbGl0 eSBlYWNoIGFuZCBldmVyeSB0aW1lIHlvdSANCnB1cmNoYXNlIGZyb20gdXMuJm5ic3A7PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Zb3Ug bWF5IGFsc28gYmUgaW50ZXJlc3RlZCB0byBrbm93IHRoYXQgDQp3ZSBoYXZlIHRoZSBmb2xs b3dpbmcgYnJhbmRzIGF2YWlsYWJsZSBpbiBvdXIgd2lkZSBzZWxlY3Rpb24gYXMgd2VsbDo8 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxi cj4NCjEuIExlYXRoZXIgYmFuZCBEYXl0b25hIChsYWRpZXMgYW5kIG1lbqGvcyk8L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjIuIEJsYW5j cGFpbjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+My4gRm9ydGlzPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj40LiBKYWVnZXIgTGVDb3V0cmU8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjUuIExvbmdpbmVzPC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj42LiBNb250IEJsYW5jPC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj43LiBN b3ZhZG88L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjguIE9yaXM8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjkuIFJvZ2VyIER1YnVpczwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+MTAuIFVseXNzZTwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+MTEuIFplbml0aDwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+MTIuIEF1ZGVtYXIg UGlndWV0PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj4xMy4gQnJlaXRsaW5nPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj4xNC4gQnZnbGFyaTwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+MTUuIENhcnRpZXI8L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjE2LiBDb3J1bTwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+MTcuIER1bmhp bGw8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjE4LiBGcmFuY2sgTXVsbGVyPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj4xOS4gR2VyYXJkIFBlcnJlZ2F1eDwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+MjAuIElXQzwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+MjEuIElXQzwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+MjIuIFBh bmVyYWk8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjIzLiBQYXRlayBQaGlsaXBwZTwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+MjQuIFRhZyBIZXVlcjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+MjUuIFZhY2hlcm9uIENvbnN0YW50 aW48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+SWYgeW91IHNlZSBhbnl0aGluZyB0aGF0IG1pZ2h0IGludGVyZXN0IA0KeW91LCBv ciBpZiB5b3UgaGF2ZSBhbnkgcXVlc3Rpb25zLCBwbGVhc2UgZG9uJ3QgaGVzaXRhdGUgdG8g dmlzaXQgb3VyIHdlYnNpdGUgDQphdDo8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHA6Ly93d3cucGVyZmVjdHdhdGNo cGllY2UuY29tLyI+d3d3LlBlcmZlY3RXYXRjaFBpZWNlLmNvbTwvYT48YnI+DQpJIGNlcnRh aW5seSBsb29rIGZvcndhcmQgdG8gaGVhcmluZyBmcm9tIHlvdS48YnI+DQpCZXN0IHJlZ2Fy ZHMsPGJyPg0KPGJyPg0KQ2FsPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48YnI+DQpEaXZpc2lvbiBTYWxlcyBNYW5hZ2VyPGJyPg0KQVRH V1MmbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOzwvc3Bhbj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTpBcmlh bCI+Jm5ic3A7PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTpBcmlhbCI+ WW91IA0KcmVjZWl2ZWQgdGhpcyBlbWFpbCBiZWNhdXNlIHlvdXIgaGF2ZSBwcmV2aW91cyBw dXJjaGFzZWQgZnJvbSwgb3IgaW5xdWlyZWQgYWJvdXQgDQpvdXIgcHJvZHVjdCBsaW5lIHVu ZGVyIEFUR1dTLiBJZiB5b3UgZG8gbm90IHdhbnQgdG8gcmVjZWl2ZSBmdXJ0aGVyIG1haWxp bmdzIA0KZnJvbSBBVEdXUywgdW5zdWJzY3JpYmUgYnkgc2VuZGluZyBhbiBlbWFpbCB3aXRo IHRoZSB0aXRsZSBoZWFkaW5nOiBERUxFVEUgaW4gDQp0aGUgc3ViamVjdCBsaW5lIHRvIDxh IGhyZWY9Im1haWx0bzp1bnN1YnNjcmliZUBQZXJmZWN0V2F0Y2hQaWVjZS5jb20iPnVuc3Vi c2NyaWJlQFBlcmZlY3RXYXRjaFBpZWNlLmNvbTwvYT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+DQo8L286cD4NCjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bXNvLWJpZGktZm9udC1zaXplOg0KMTIuMHB0O2Zv bnQtZmFtaWx5OkFyaWFsIj5wbGVhc2Ugbm90ZSB0byBzZW5kIEFMTCBSRVBMWSBlLW1haWwg ZGlyZWN0IHRvIG91ciANClNhbGVzIFJlcHJlc2VudGF0aXZlIGF0OjxvOnA+DQo8L286cD4N Cjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToNCjEy LjBwdDtmb250LWZhbWlseTpBcmlhbCI+PGEgaHJlZj0ibWFpbHRvOlF1ZXN0aW9uc0BQZXJm ZWN0V2F0Y2hQaWVjZS5jb20iPlF1ZXN0aW9uc0BQZXJmZWN0V2F0Y2hQaWVjZS5jb208L2E+ PG86cD4NCjwvbzpwPg0KPC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bXNvLWJpZGkt Zm9udC1zaXplOg0KMTIuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj4mbmJzcDs8bzpwPg0KPC9v OnA+DQo8L3NwYW4+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8bzpwPg0KPC9vOnA+DQo8L3NwYW4+PC9wPg0KDQo8L2JvZHk+DQoN Cg0KICAgIA== |
From: o.mekkaoui <o.m...@fr...> - 2003-07-11 09:35:36
|
Hi, I used Numeric, GSL and mysql to create some C python extension. The objective is to make requests and after are stocked in a python array. So this work fine with python1.5 and Numeric17 using: gcc -c GnoStructTC.c -DHAVE_CONFIG_H -I/usr/include/python-I/usr/lib/python/config1.5 -I/usr/inlude/mysql -I/usr/lib/mysql gcc -shared GnoStructTC.o -lgsl -lgslcblas -lmysqlclient -o GnoStructTC.so Now, with Python 2.2 and Numeric22 : this don't work (default segmentation) and I can't create my array On other hand, if I just create simple array using gcc -c GnoStructTC.c -DHAVE_CONFIG_H -I/usr/include/python2.2 -I/usr/lib/python2.2/config gcc -shared GnoStructTC.o -o GnoStructTC.so there are no problem. Perhaps there are some mistakes in the compilation or a conflit between Numeric and GSL. Any idea. Thanks in advance. |
From: Gerard V. <gve...@gr...> - 2003-07-07 13:02:17
|
PyQwt-3.7 = FAST and EASY data plotting for Python and Qt. PyQwt is a set of Python bindings for the Qwt C++ class library. Qwt extends the Qt framework with widgets for scientific and engineering applications. PyQwt really shines with Numeric and/or numarray. Numeric and numarray extend Python with new data types that make Python an ideal language for numerical computing and experimentation. PyQwt requires and extends PyQt, a set of Python bindings for Qt. PyQwt runs on Windows and Unix/Linux. The home page of PyQwt has moved to http://pyqwt.sourceforge.net. New features in PyQwt-3.7: 1. PyQwt will work with either Numeric, or numarray or both (depending on the presence of Numeric and numarray during PyQwt's build). 2. PyQwt will work without Numeric and numarray (is not recommended). 3. PyQwt is compatible with the Python Command Line Interpreter or IPython, provided that the readline module is installed: Qt's event processing is scheduled by the readline library through (int)(*PyOS_InputHook)(void). 4. PyQwt is always rlcompleter-friendly, even though PyQt-3.6 and earlier are not (the dir() function has been enhanced in PyQt-3.7). 5. The module qwt.qplt is enhanced: qwt.qplt is sugar coating for the QwtPlot widget to facilitate plotting from an interpreter. 6. QwtImagePlot maps a 2-dimensional array of z-values on a QImage using a color scale. 7. New Qwt widgets: QwtDial and QwtCompass. 8. Works with PyQt-3.7, PyQt-3.6, PyQt-3.5 and PyQt-3.4. 9. Works with Qt-2.3.x, Qt-3.0.x and Qt-3.1.x. Gerard Vermeulen |
From: eric j. <er...@en...> - 2003-06-27 22:10:20
|
Hey folks, I've been postponing this announcement because the registration page isn't active yet. It's getting late though, and I thought I'd at least let you know SciPy '03 is happening. I'll repost when registration is open. Thanks, Eric ------------------------------------------------------- SciPy '03 The 2nd Annual Python for Scientific Computing Workshop ------------------------------------------------------- CalTech, Pasadena, CA September 11-12, 2003 http://www.scipy.org/site_content/scipy03 This workshop provides a unique opportunity to learn and affect what is happening in the realm of scientific computing with Python. Attendees will have the opportunity to review the available tools and how they apply to specific problems. By providing a forum for developers to share their Python expertise with the wider industrial, academic, and research communities, this workshop will foster collaboration and facilitate the sharing of software components, techniques and a vision for high level language use in scientific computing. The cost of the workshop is $100.00 and includes 2 breakfasts and 2 lunches on Sept. 11th and 12th, one dinner on Sept. 11th, and snacks during breaks. Online registration is not available yet, but will be soon. We would like to have a wide variety of presenters this year. If you have a paper you would like to present, please contact er...@en.... Discussion about the conference may be directed to the SciPy-user mailing list: Mailing list page: http://www.scipy.org/MailList Mailinbg list address: sci...@sc... Please forward this announcement to anyone/list that might be interested. ------------- Co-Hosted By: ------------- The National Biomedical Computation Resource (NBCR, SDSC, San Diego, CA) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://nbcr.sdsc.edu The mission of the National Biomedical Computation Resource at the San Diego Supercomputer Center is to conduct, catalyze, and enable biomedical research by harnessing advanced computational technology. The Center for Advanced Computing Research (CACR, CalTech, Pasadena, CA) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://nbcr.sdsc.edu CACR is dedicated to the pursuit of excellence in the field of high-performance computing, communication, and data engineering. Major activities include carrying out large-scale scientific and engineering applications on parallel supercomputers and coordinating collaborative research projects on high-speed network technologies, distributed computing and database methodologies, and related topics. Our goal is to help further the state of the art in scientific computing. Enthought, Inc. (Austin, TX) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://enthought.com Enthought, Inc. provides scientific and business computing solutions through software development, consulting and training. ---------------------------------------------- eric jones 515 Congress Ave www.enthought.com Suite 1614 512 536-1057 Austin, Tx 78701 |
From: Todd M. <jm...@st...> - 2003-06-25 11:01:44
|
On Tue, 2003-06-24 at 19:06, Cliff Martin wrote: > Dear Group, > > I've just started to use numarray as I have an imaging program I want to > port. I noticed in the differences document that one can read in data > using fromfile into an array. This is a great savings over using the > standard , string to integer floats. For some strange reason I can't > get it to work correctly with my interferometer file (512,512) array. So > I made up a small set of data in a file.(Attached test.txt). > Looking over your test data, it looks like it is in ASCII. fromfile() works with binary data. Reading in your data can be done with a few lines of Python code: >>> import numarray >>> n = numarray.array(shape=(16,), type=numarray.Int32) >>> f = open("test.txt") >>> s = f.read() # Read the whole file as one string >>> words = s.split(" ")[:-1] # split on spaces; discard trailing junk >>> for i in range(len(words)): n[i] = eval(words[i]) # convert ASCII to Python Ints and assign >>> n.shape=(4,4) # Add the "real" shape >>> n array([[ 0, -32678, 14, 85], [ 342, 12, 14, 15], [ 16, 45, 67, 98], [ 38, 256, 234, 234]]) Binary files are easier and more efficient, but are not portable unless you remember the byte order. Todd -- Todd Miller <jm...@st...> |
From: Cliff M. <cam...@sn...> - 2003-06-24 23:05:03
|
Dear Group, I've just started to use numarray as I have an imaging program I want to port. I noticed in the differences document that one can read in data using fromfile into an array. This is a great savings over using the standard , string to integer floats. For some strange reason I can't get it to work correctly with my interferometer file (512,512) array. So I made up a small set of data in a file.(Attached test.txt). The code I used was simple, inp = open('c:/transfer/test.txt','r') y=fromfile(inp,Int32,[4,4]) with the following error message(s) Traceback (most recent call last): File "<interactive input>", line 1, in ? File "C:\Python22\Lib\site-packages\numarray\numarray.py", line 380, in fromfile raise ValueError( ValueError: Not enough bytes left in file for specified shape and type Well I thought maybe Int32 is not the correct specification so I tried Int16 and Int8. These both worked but the numbers read in were wrong. So what am I not understanding here? Thanks Cliff Martin |
From: Magnus L. H. <ma...@he...> - 2003-06-14 12:38:07
|
When I try to build numarray 0.5, it seems to look for Src/_convmodule.c, which isn't there (although it is there in 0.4). I couldn't find anything about this in the bug tracker, which somehow surprised me... Am I missing something obvious? Another thing: I'm having trouble using setupall.py in Solaris with Python 2.3b1 (it worked with earlier versions, including some pre-2.3a1 CVS versions, IIRC). Things compile, but when the tests run, I get a segmentation fault. I can import numarray (and everything from it) but if I try something basic, such as calling the array function, I again get a segfault. Things *do* work, however, if I simply use python setup.py install, so I suppose there must be some problem with some extension...? I don't quite understand how that would affect the basic array function, for example... Is there an interaction effect there? I couldn't find anything about this in the bug tracker either, when searching for "build failure". Tips on how to find out more so I can give a more precise bug report would be appreciated. I really hope I can eventually use 0.6 (can't seem to be able to get anything with anonymous CVS :() with Py2.3 and Solaris... And -- I really think the numarray restructuring looks _great_! :) Thanks for any input, - Magnus -- Magnus Lie Hetland "In this house we obey the laws of http://hetland.org thermodynamics!" Homer Simpson |
From: Todd M. <jm...@st...> - 2003-06-13 17:33:56
|
On Fri, 2003-06-13 at 12:32, Francesc Alted wrote: > Hi, > > The new interface looks pretty clear. I don't think numarray.numcomp veneer > would be very elegant, because after all, it took to me only 30 minuts to > migrate pytables from numarray 0.5 to the forthcoming numarray 0.6 (and it > used the old recarray, charray and ndarray modules intensively), although I > recognize that it may be useful in some circunstances, of course. numcomp is a free-standing collection of compatibility modules. It is throw-away code to help mitigate the need to simultaneously change several pieces of software. It's not required or recommended, but is there as a tool to ease the transition from the old names to the new if the transition presents any sticky problems. Thanks looking it over, Todd |
From: Francesc A. <fa...@op...> - 2003-06-13 16:33:08
|
Hi, The new interface looks pretty clear. I don't think numarray.numcomp veneer would be very elegant, because after all, it took to me only 30 minuts to migrate pytables from numarray 0.5 to the forthcoming numarray 0.6 (and it used the old recarray, charray and ndarray modules intensively), although I recognize that it may be useful in some circunstances, of course. On the contrary, I find the numarray.numeric module a *great* thing as it will easy a lot the migration of applications from Numeric to numarray. Cheers, -- Francesc Alted |
From: Todd M. <jm...@st...> - 2003-06-13 14:47:57
|
Our efforts to repackage numarray as a package rather than a collection of modules have taken form, so I'm looking for a (final) final round of comments before we declare this to be the "new interface". ================= basic repackaging ================= The core numarray routines will be distributed as the package "numarray" and because the new package __init__.py imports the contents of the old numarray.py module, simple import phrases involving numarray will continue to work like they always did: import numarray # These will continue to work unchanged from numarray import * For everything else, a "numarray." prefix and possibly a new name are required: recarray --> numarray.records chararray --> numarray.strings ndarray --> numarray.generic numtestall --> numarray.testall * --> numarray.* The 4 standard add-on packages have been renamed and will be distributed as a single unit called "numarray-addons" and will install directly in the numarray package. This has most effect for Windows binary users who should now be able to install with two clicks: one for numarray, the other for the addons. UNIX users still have the setupall one liner or the option to use the two independent setups however they like. FFT2 --> numarray.fft LinearAlgebra2 --> numarray.linear_algebra Convolve --> numarray.convolve Convolve.Image --> numarray.image ======= numcomp ======= There is a new "compatibility distribution" called "numcomp" which installs backward compatibility modules in a directory separate from numarray. Install numcomp if you want to run numarray-0.6 without changing your existing numarray applications for the new naming scheme (and if you directly import anything other than numarray itself, e.g. recarray or FFT2). We need numcomp at STSCI as a pragmatic issue, to prevent needing simultaneous changes of numarray and software depending on it. numcomp issues a single deprecation warning when you import your first compatibility module. numcomp is a sort of veneer, not a complete distribution; you still need the numarray-0.6 package in order to use numcomp. The plan is to phase numcomp out of existence at the release of numarray-1.0. The warning can be eliminated either by a simple hack of numcomp's repackage.py module, or from the Python command line. Thus, without numcomp but with numarray-0.6: >>> import recarray # can't do this anymore ... ImportError >>> import numarray.records # have to do this now >>> but with numcomp: >>> import recarray # this still works, but with a warning ...NumarrayRepackagingWarning... # too big a mouthful for email ================ numarray.numeric ================ There is now a submodule of numarray, numarray.numeric, which is more Numeric compatbile than numarray itself. It is part of the main numarray distribution. numarray.numeric contains everything the (old) numarray module does, but also redefines things for better compatibility. Currently, it just redefines nonzero() to handle 1D arrays the same as Numeric does. numarray.nonzero() remains unchanged. Any future Numeric compatibility changes will be added to numarray.numeric as well. So... if you've already written numarray code using nonzero() and it works, you're done. If you want to port Numeric code to numarray, consider importing numarray.numeric instead of numarray. The current plan is to maintain numarray.numeric indefinitely. >>> import numarray >>> import numarray.numeric >>> a=numarray.arange(5) >>> numarray.nonzero(a) (array([1, 2, 3, 4]),) # this format handles multi-D arrays >>> numarray.numeric.nonzero(a) array([1, 2, 3, 4]) # this format doesn't Comments? Todd -- Todd Miller jm...@st... STSCI / ESS / SSB |
From: <23...@ma...> - 2003-06-13 08:06:01
|
<html> <head> <title>Untitled Document</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> </head> <body> <center><font color="#FF0000"><b>PC Surveillance The most powerful Spy Software!<br></font> <font color="#0000FF"><a href="http://www.sil20221.com/surveillance/adv166/">PC Surveillance Records everything on your PC Remotely!</a></font><br><br> -----------------------------------------------------------<br><br> <font color="#0000FF"><a href="http://www.sil20221.com/surveillance/adv166/">PC Surveillance</a></font> is an award winning critically acclaimed package!</b><br><br> <u><b><a href="http://www.sec1001.biz/surveillance/adv166/"><font color="#0000FF">:: Remote Internet Monitoring ::</font></a></b></u><br><br> <font color="#FF0000"><a href="http://www.sec1001.biz/surveillance/adv166/">PC Surveillance</a></font> is the first and only real time remotely deployable spy software application. PC Surveillance Pro v3.41 gives you the power to remotely monitor computers from anywhere in the world at anytime! Record chat conversations, keystrokes, email, usernames, passwords and more secretly! PC Surveillance is also completely undetectable to the user being monitored. It will not be listed in the task manager and also cloaks itself making it completely stealth and hidden at all times!<br><br> <u><a href="http://www.sec1001.biz/surveillance/adv166/"><b><font color="#0000FF"> :: Immediate Online Delivery! ::</font></b></a></u><br><br> <a href="http://www.sil20221.com/surveillance/adv166/">DARKSOFT GROUP</a> <font size="1">Copyright 2003</font></p> </body> </html> |
From: Felix B. <fe...@fb...> - 2003-06-11 21:31:34
|
Hello! I am using Numeric 0.23 with Python 2.2 on my Gentoo Linux box. Problem: >>> from Numeric import * >>> import RandomArray Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.2/site-packages/Numeric/RandomArray.py", line 30, in ? seed() File "/usr/lib/python2.2/site-packages/Numeric/RandomArray.py", line 26, in seed x = int(t/base) OverflowError: float too large to convert Is this a bug, a misconfiguration on my system or a misusage on my part? Opinions, anyone? Thanks, Felix |
From: Todd M. <jm...@st...> - 2003-06-09 13:40:05
|
On Sun, 2003-06-08 at 14:38, Pete Shinners wrote: > still there are a few things i am > doing that i'm unsure if numarray is ready to handle yet? > > what is going to make this tricky is i'm doing a bit of 'attribute > mangling' to the Numeric array structure. this is necessary as the image > data is extremely 'non-flat'. also, since i am referencing data held in > another python object, i need to make sure the array holds a reference > to the original object. these are the things i'm afraid i'll be stuck on. > > here is pretty much what i am doing now, simplified quite a bit... > > PyObject* pixelsarray(SDL_Surface *surf) > { > int dim[3]; > PyObject *array; > > dim[0] = surf->w; > dim[1] = surf->h; > dim[2] = 3; > array = PyArray_FromDimsAndData(3, dim, > PyArray_UBYTE, surf->pixels); > if(array) > { > PyArrayObject *a = (PyArrayObject*)array > a->flags = OWN_DIMENSIONS|OWN_STRIDES; > a->strides[2] = 1; > a->strides[1] = surf->pitch; > a->strides[0] = surf->format->BytesPerPixel; > a->base = _pyobject_to_surf_; > } > return array; > } > > note that depending on pixel packing and endianess, the strides[2] can > become -1. smiley. Despite old documentation to the contrary, the strides array is now writable. The -1 is more problematic. Anytime a ufunc is called, there is "safety code" which evaluates the shape, strides, byteoffset, buffer base and buffer size to ensure that the ufunc won't attempt an access outside the buffer or generate a misaligned pointer. negative strides are possible *provided* that the byteoffset is chosen so that everything works out. > also pretend a->base is pointing to a real python > object, which it does in the real version. numarray has a "base" pointer which is currently unused and intended for the purpose of backward compatibility. Since numarray does not yet use the base pointer at all, it does not deallocate it at array destruction time. > there is likely a way to workaround the "base" requirement with weakrefs > i suppose, but i'd rather not jump through the extra hoops. the real > necessity is setting the strides how i want. i didn't see any array > creation functions that allow me to pick my own strides. New in numarray-0.5 is the API function NA_NewAllStrides which allows you to pass in a pointer to a strides array. NA_NewAllStrides does not currently check the validity of the strides array. > once i create > the array here i never change any of the array attributes. > > if this looks doable then it's time for me to sit down with the numarray > docs and see what new and exciting things await me :] It looks close to doable to me. There are probably still a few loose ends. Todd -- Todd Miller jm...@st... STSCI / ESS / SSB |
From: Pete S. <pe...@sh...> - 2003-06-08 18:40:15
|
in the pygame project i've had the ability to map images into Numeric data arrays onto image pixel data. This has worked excellently for me, but in the near future i'd also like to support numarray. early in numarray's development it looked like this was not going to be possible at all. i've been following numarray loosely, and it sure looks like things have 'loosened' up a bit. still there are a few things i am doing that i'm unsure if numarray is ready to handle yet? what is going to make this tricky is i'm doing a bit of 'attribute mangling' to the Numeric array structure. this is necessary as the image data is extremely 'non-flat'. also, since i am referencing data held in another python object, i need to make sure the array holds a reference to the original object. these are the things i'm afraid i'll be stuck on. here is pretty much what i am doing now, simplified quite a bit... PyObject* pixelsarray(SDL_Surface *surf) { int dim[3]; PyObject *array; dim[0] = surf->w; dim[1] = surf->h; dim[2] = 3; array = PyArray_FromDimsAndData(3, dim, PyArray_UBYTE, surf->pixels); if(array) { PyArrayObject *a = (PyArrayObject*)array a->flags = OWN_DIMENSIONS|OWN_STRIDES; a->strides[2] = 1; a->strides[1] = surf->pitch; a->strides[0] = surf->format->BytesPerPixel; a->base = _pyobject_to_surf_; } return array; } note that depending on pixel packing and endianess, the strides[2] can become -1. smiley. also pretend a->base is pointing to a real python object, which it does in the real version. there is likely a way to workaround the "base" requirement with weakrefs i suppose, but i'd rather not jump through the extra hoops. the real necessity is setting the strides how i want. i didn't see any array creation functions that allow me to pick my own strides. once i create the array here i never change any of the array attributes. if this looks doable then it's time for me to sit down with the numarray docs and see what new and exciting things await me :] |