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: Perry G. <pe...@st...> - 2003-12-11 21:02:10
|
> There has been little clamour for adding this complication to the syntax > over the last three plus years. > This is certainly true. > I suggest that PyMatrix shows that the desired results can be achieved, > with few additional key strokes and without adding to the Python > character set. > > Colin W > I guess I will wait and see. The worry I have is that when people attempt to use a PyMatrix where a numarray is expected (and the same issue would be true for Numeric) that the behavior of expressions may cause some confusion (i.e., since matrix multiplies may happen instead of element-wise operations). This most likely will result in some visible exception (e.g., incompatible shapes) but may not. If people never mix the two, it won't be a problem; or if they are careful to convert before doing so. Perry |
|
From: Colin J. W. <cj...@sy...> - 2003-12-11 20:45:42
|
Perry Greenfield wrote: >>-----Original Message----- >>From: num...@li... >>[mailto:num...@li...]On Behalf Of >>Sebastian >>Haase >>Sent: Thursday, December 11, 2003 1:45 PM >>To: Colin J. Williams >>Cc: num...@li... >>Subject: Re: [Numpy-discussion] PyMatrix: Announcement >> >> >>Thanks for the reply. >>PEP 225 is from Sept-2000 and http://matpy.sourceforge.net and >>dated from >>Mar-2002 (Python 2.0) >> >>That is about the results I got from my first google-groups >>search. What is >>the current thinking about this ? >>Looks to me like the "new operator" idea is dead. Or ?? >> >>I actually like (read: could live with) alternative 4 in PEP >>225: which is, >>to provide operator overloading for what I call >>"different views" of the same matrix / image. How difficult is this to >>implement ? >>(What is the real difference to alternative 3 ? They both have >>m1.E * m2.E >>. ) >> >>Regards, >>Sebastian >> >> >> None >> >> >> >If I recall correctly, Guido didn't dismiss it out of hand, but he >wasn't going to do anything about it unless there was sufficient >noise from the community that this was very important. I think it >is, and I suppose if we campaign enough, it may be considered. > >Perry > > There has been little clamour for adding this complication to the syntax over the last three plus years. I suggest that PyMatrix shows that the desired results can be achieved, with few additional key strokes and without adding to the Python character set. Colin W |
|
From: Perry G. <pe...@st...> - 2003-12-11 19:34:51
|
> -----Original Message----- > From: num...@li... > [mailto:num...@li...]On Behalf Of > Sebastian > Haase > Sent: Thursday, December 11, 2003 1:45 PM > To: Colin J. Williams > Cc: num...@li... > Subject: Re: [Numpy-discussion] PyMatrix: Announcement > > > Thanks for the reply. > PEP 225 is from Sept-2000 and http://matpy.sourceforge.net and > dated from > Mar-2002 (Python 2.0) > > That is about the results I got from my first google-groups > search. What is > the current thinking about this ? > Looks to me like the "new operator" idea is dead. Or ?? > > I actually like (read: could live with) alternative 4 in PEP > 225: which is, > to provide operator overloading for what I call > "different views" of the same matrix / image. How difficult is this to > implement ? > (What is the real difference to alternative 3 ? They both have > m1.E * m2.E > . ) > > Regards, > Sebastian > > > None > If I recall correctly, Guido didn't dismiss it out of hand, but he wasn't going to do anything about it unless there was sufficient noise from the community that this was very important. I think it is, and I suppose if we campaign enough, it may be considered. Perry |
|
From: Sebastian H. <ha...@ms...> - 2003-12-11 18:45:18
|
Thanks for the reply. PEP 225 is from Sept-2000 and http://matpy.sourceforge.net and dated = from Mar-2002 (Python 2.0) That is about the results I got from my first google-groups search. = What is the current thinking about this ? Looks to me like the "new operator" idea is dead. Or ?? I actually like (read: could live with) alternative 4 in PEP 225: which = is, to provide operator overloading for what I call=20 "different views" of the same matrix / image. How difficult is this to = implement ? (What is the real difference to alternative 3 ? They both have m1.E * = m2.E . ) Regards, Sebastian ----- Original Message -----=20 From: Colin J. Williams=20 To: Sebastian Haase=20 Sent: Wednesday, December 10, 2003 5:27 AM Subject: Re: [Numpy-discussion] PyMatrix: Announcement Sebastian Haase wrote: Hi Colin, We are interested in using your PyMatrix packages (It' numarray not = Numeric, right?).That is correct. Testing so far is with numarray 0.7. Please = remember to also install the version 0.7 addons. When version 0.8 = arrives, all will be included in one package. The package is intended for comment and review. There is at least one = problem in numarray, which we hope will be resolved in version 0.8. For = example, for some functions, upon the first call, the function returns = an instance of the M class (matrix), on the second call, it returns an = instance of the NumArray class. First though, someone in my lab had the following concern: What if I actually need the element-wise multiplication ? (In other words: The Matlab .* operator) [1] I understand that python does not allow to invent new operator = symbols.Yes. This issue was discussed in PEP 225. How about multiplying a Matrix with a Numarray ?Please see [2]. Is it possible to have a 'numarray view' of a Matrix object ? (I'm = thinking of two differently typed objects sharing one "value-memory space", so = that essentially the type determines which multiplication is being used = ...)There is a need to think through the copy/view approach in PyMatrix. = Currently, most cases are copies. I'm inclined to deprecate the dual view approach, but I would = appreciate comments. Let me know if you have any questions or comments. Colin W. Thanks, Sebastian Haase ----- Original Message -----=20 From: "Colin J. Williams" <cj...@sy...> Newsgroups: comp.lang.python,comp.lang.python.announce To: "numpy-discussion" <num...@li...>; "SciPy Discussion List" <sci...@sc...> Cc: "Huaiyu Zhu" <hz...@us...> Sent: Monday, November 24, 2003 5:17 AM Subject: [Numpy-discussion] PyMatrix: Announcement PyMatrix is available for test and review. http://www3.sympatico.ca/cjw PyMatrix provides access to basic matrix arithmetic, using Python and numarray. Examples: A * B =3D> the product of matrices A and B A.I =3D> the inverse of = matrix A A.EVectors =3D> the eigenvectors of = A A.var(0) =3D> the variances of the columns of A (a.T*a).I * a.T*b =3D> the solution (x) for a * x =3D b, where a is a matrix and b a column vector This package was developed on a Windows XP. I would appreciate comments, particularly with respect to usage on other systems. Colin W. ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Numpy-discussion mailing list Num...@li... https://lists.sourceforge.net/lists/listinfo/numpy-discussion Notes: [1] Elementwise Multiplication The thinking here is that, for most matrix usage, the elementwise = multiplication is less frequently required. Thus, a more complex expression can be tolerated. See the example = below: a=3D mRange(9, shape=3D(3, 3)) b=3D mRange((9, 18), shape=3D (3, 3)) print 'Matrixwise multiplation:' print 'a * b (prettyprinted):', pp(a * b) print 'Elementwise multiplation:' print 'a * b (prettyprinted):', pp(M(a.A * b.A))) In the last case, we use the array mechanism. The output is: Matrixwise multiplation: a * b (prettyprinted):matrix([[ 42, 45, 48], [150, 162, 174], [258, 279, 300]]) None Elementwise multiplation: a * b (prettyprinted):matrix([[ 0, 10, 22], [ 36, 52, 70], [ 90, 112, 136]]) None [2] Multiplication of a matrix by an array or nested list When an compatible array or list is juxtapositioned with a matrix, = it is in effect coerced to the higher class. a=3D mRange(9, shape=3D(3, 3) c=3D N.arange(9, shape=3D(3, 3)) print 'A matrix multiplied by an array:' print 'a * c (prettyprinted):', pp(a * c) print 'A matrix multiplied by a list:' lst=3D [[0, 1, 2], [3, 4, 5], [6, 7, 8]] print 'a * lst (prettyprinted):', pp(a * lst) The output is: A matrix multiplied by an array: a * c (prettyprinted):matrix([[ 15, 18, 21], [ 42, 54, 66], [ 69, 90, 111]]) None A matrix multiplied by a list: a * lst (prettyprinted):matrix([[ 15, 18, 21], [ 42, 54, 66], [ 69, 90, 111]]) None |
|
From: <ho...@gl...> - 2003-12-10 15:06:49
|
QmVydGhvbGQgSPZsbG1hbm4gPGhvZWxAZ2wtZ3JvdXAuY29tPiB3cml0ZXM6DQoNCj4gSGVsbG8s DQouLi4NCj4NCj4+cHl0aG9uIH4veHgucHkNCj4gMjEuMA0KPiAyLjIuMSAoIzEsIERlYyAxMyAy MDAyLCAxMDozNzozMikgDQo+IFtHQ0MgMy4yXQ0KPiBEDQo+IGFycmF5SW5mbyhtKToNCj4gMyBk aW1lbnNpb25zLCBkaW1lbnNpb25zIDogOCA0OCA2LCBzdHJpZGVzIDogMSA0OCA4DQo+IGFycmF5 SW5mbyhhKToNCj4gMyBkaW1lbnNpb25zLCBkaW1lbnNpb25zIDogNDggOCAzLCBzdHJpZGVzIDog MSA0OCAzODQNCj4gKDgsIDQ4LCAzKQ0KPiAoNDgsIDgsIDMpDQo+ICgxKzBqKQ0KPiBTZWdtZW50 YXRpb24gZmF1bHQNCg0KVGhpcyBpcyBidWcgODU3NjIyIG9uIFNGIG5vdy4NCg0KS2luZCByZWdh cmRzDQoNCkJlcnRob2xkIEj2bGxtYW5uDQotLSANCkdlcm1hbmlzY2hlciBMbG95ZCBBRw0KQ0FF IERldmVsb3BtZW50DQpWb3JzZXR6ZW4gMzUNCjIwNDU5IEhhbWJ1cmcNClBob25lOiArNDkoMCk0 MCAzNjE0OS03Mzc0DQpGYXg6ICs0OSgwKTQwIDM2MTQ5LTczMjANCmUtbWFpbDogaG9lbEBnbC1n cm91cC5jb20NCkludGVybmV0OiBodHRwOi8vd3d3LmdsLWdyb3VwLmNvbSANCiANCiANCiANCioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiogIA0KIA0K UGxlYXNlIG5vdGljZTogV2Ugd291bGQgbGlrZSB0byBpbmZvcm0geW91IHRoYXQgdGhlIGUtbWFp bCBhZGRyZXNzIG9mIEdlcm1hbmlzY2hlciBMbG95ZCBhcyB3ZWxsIGFzIG91ciBpbnRlcm5ldCBh ZGRyZXNzIGhhZCBiZWVuIGNoYW5nZWQgdG8gIGdsLWdyb3VwLmNvbSB3aXRoIGVmZmVjdCBmcm9t IDFzdCBNYXJjaCAyMDAzLiANCiANClRoaXMgbWVhbnMgdGhhdCB0aGUgcHJldmlvdXMgYWRkcmVz cyBzaG9ydG1hcmtAZ2VybWFubGxveWQub3JnIHdpbGwgYmUgcmVwbGFjZWQgYnkgc2hvcnRtYXJr QGdsLWdyb3VwLmNvbS4gRnJvbSBub3cgb24gdGhlIEdMIGhvbWVwYWdlIGNhbiBiZSBhY2Nlc3Nl ZCBhdCB0aGUgYWRkcmVzcyAnaHR0cDovL3d3dy5nbC1ncm91cC5jb20nLiBUaGUgb2xkIGFkZHJl c3NlcyByZW1haW4gdmFsaWQgZm9yIGEgdHJhbnNpdGlvbmFsIHBlcmlvZC4gDQogDQogDQoqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqIA0KIA0KIA0K IA0KVGhpcyBlLW1haWwgY29udGFpbnMgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGZvciB0aGUg ZXhjbHVzaXZlIGF0dGVudGlvbiBvZiB0aGUgaW50ZW5kZWQgYWRkcmVzc2VlLiBBbnkgYWNjZXNz IG9mIHRoaXJkIHBhcnRpZXMgdG8gdGhpcyBlLW1haWwgaXMgdW5hdXRob3Jpc2VkLiBBbnkgdXNl IG9mIHRoaXMgZS1tYWlsIGJ5IHVuaW50ZW5kZWQgcmVjaXBpZW50cyBzdWNoIGFzIGNvcHlpbmcs IGRpc3RyaWJ1dGlvbiwgZGlzY2xvc3VyZSBldGMuIGlzIHByb2hpYml0ZWQgYW5kIG1heSBiZSB1 bmxhd2Z1bC4gV2hlbiBhZGRyZXNzZWQgdG8gb3VyIGNsaWVudHMgdGhlIGNvbnRlbnQgb2YgdGhp cyBlLW1haWwgaXMgc3ViamVjdCB0byB0aGUgR2VuZXJhbCBUZXJtcyBhbmQgQ29uZGl0aW9ucyBv ZiBHTCdzIEdyb3VwIG9mIENvbXBhbmllcyBhcHBsaWNhYmxlIGF0IHRoZSBkYXRlIG9mIHRoaXMg ZS1tYWlsLiAgDQogDQpHTCdzIEdyb3VwIG9mIENvbXBhbmllcyBkb2VzIG5vdCB3YXJyYW50IGFu ZC9vciBndWFyYW50ZWUgdGhhdCB0aGlzIG1lc3NhZ2UgYXQgdGhlIG1vbWVudCBvZiByZWNlaXB0 IGlzIGF1dGhlbnRpYywgY29ycmVjdCBhbmQgaXRzIGNvbW11bmljYXRpb24gZnJlZSBvZiBlcnJv cnMsIGludGVycnVwdGlvbiBldGMuICANCiANCg== |
|
From: <ho...@gl...> - 2003-12-10 14:26:27
|
SGVsbG8sDQoNCkZvciBzb21lIHRpbWUgbm93IEkgd2F3cyBzZWFyY2hpbmcgZm9yIHRoZSBjYXVz ZSBvZiBhIHNlZ21lbnRhdGlvbg0KZmF1bHQgaW4gYSBxdWl0ZSBjb21wbGV4IHBpZWNlIG9mIHNv ZnR3YXJlIG9mIG91cnMgd2hpY2ggb2NjdXJlZCBvbmx5DQp1bmRlciBXaW5kb3dzIGFuZCBub3Qg dW5kZXIgTGludXggbm9yIHVuZGVyIFNvbGFyaXMuIEZpbmFsbHkgaXQgc2VlbXMNCnRoYXQgdGhl IGNhc2Ugd2VyZSBzb21lIGxpbmVzIHRoYXQgZGlkIHRoZSBmb2xsb3dpbmc6DQoNCmZyb20gTnVt ZXJpYyBpbXBvcnQgKg0KaW1wb3J0IG51bWVyaWNfdmVyc2lvbg0KcHJpbnQgbnVtZXJpY192ZXJz aW9uLnZlcnNpb24NCmZyb20gbnVtZm9ydCBpbXBvcnQgYXJyYXlJbmZvDQppbXBvcnQgc3lzDQpw cmludCBzeXMudmVyc2lvbg0KbSA9IG9uZXMoKDQ4LDYsOCksIENvbXBsZXgpDQptID0gdHJhbnNw b3NlKG0sWzIsMCwxXSkNCmEgPXN3YXBheGVzKGlubmVycHJvZHVjdCh0cmFuc3Bvc2UoW1sxLDAs MF0sWzAsMSwwXSxbMCwwLDFdXSksbVs6LDosOjNdKSwwLC0xKQ0KcHJpbnQgYS50eXBlY29kZSgp DQpwcmludCAiYXJyYXlJbmZvKG0pOiINCmFycmF5SW5mbyhtKQ0KcHJpbnQgImFycmF5SW5mbyhh KToiDQphcnJheUluZm8oYSkNCnByaW50IG1bOiw6LDozXS5zaGFwZQ0KcHJpbnQgYS5zaGFwZQ0K cHJpbnQgbVsxLDEsMV0NCm1bOiw6LDozXT1hDQpwcmludCBtWzEsMSwxXQ0KbVs6LDosMzpdPWEN CnByaW50IG1bMSwxLDFdDQoNCnRoZSBudWFycmF5LmFycmF5SW5mbyBqdXN0IHByaW50cyB0aGUg ZGltZW5zaW9ucyBhbmQgc3RyaWRlcyBvZiBhDQpOdW1lcmljIGFycmF5LiBXaXRoIHRoaXMgc2Ny aXB0IEkgZ2V0DQoNCj5weXRob24gfi94eC5weQ0KMjEuMA0KMi4yLjEgKCMxLCBEZWMgMTMgMjAw MiwgMTA6Mzc6MzIpIA0KW0dDQyAzLjJdDQpEDQphcnJheUluZm8obSk6DQozIGRpbWVuc2lvbnMs IGRpbWVuc2lvbnMgOiA4IDQ4IDYsIHN0cmlkZXMgOiAxIDQ4IDgNCmFycmF5SW5mbyhhKToNCjMg ZGltZW5zaW9ucywgZGltZW5zaW9ucyA6IDQ4IDggMywgc3RyaWRlcyA6IDEgNDggMzg0DQooOCwg NDgsIDMpDQooNDgsIDgsIDMpDQooMSswaikNClNlZ21lbnRhdGlvbiBmYXVsdA0KDQp1bmRlciBM aW51eC4gVGhlIGNvZGUgZG9lcyBub3Qgc2VnZmF1bHQgd2hlbiBJIHByaW50IG0gaW4gd2hvbGUN CigicHJpbnQgbSIgaW5zdGVhZCBvZiAicHJpbnQgbVsxLDEsMV0iKSBhbmQgaXQgZG9lcyBub3Qg c2VnZmF1bHQgaW4gbXkNCmNvbXBlbGV4IHByb2dyYW0uIEl0IGRvZXMgc2VnZmF1bHQgaW4gbXkg Y29tcGxleCBwcm9ncmFtIHVuZGVyDQpXaW5kb3dzLiAgVmVyc2lvbnMgYXJlIDIuMy4yIGZvciBw eXRob24gYW5kIDIzLjEgZm9yIE51bWVyaWMgdW5kZXINCldpbmRvd3MuIFRoZSBtYWluIHF1ZXN0 aW9uIGlzLCB3aHkgaXMgbm8gZXhjZXB0aW9uIHJhaXNlZCBvbiB0aGUNCmluY29tcGF0aWJsZSBk aW1lbnNpb25zIGluIHRoaXMgZXhhbXBsZT8NCg0KS2luZCByZWdhcmRzDQoNCkJlcnRob2xkIEj2 bGxtYW5uDQotLSANCkdlcm1hbmlzY2hlciBMbG95ZCBBRw0KQ0FFIERldmVsb3BtZW50DQpWb3Jz ZXR6ZW4gMzUNCjIwNDU5IEhhbWJ1cmcNClBob25lOiArNDkoMCk0MCAzNjE0OS03Mzc0DQpGYXg6 ICs0OSgwKTQwIDM2MTQ5LTczMjANCmUtbWFpbDogaG9lbEBnbC1ncm91cC5jb20NCkludGVybmV0 OiBodHRwOi8vd3d3LmdsLWdyb3VwLmNvbSANCiANCiANCiANCioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiogIA0KIA0KUGxlYXNlIG5vdGljZTogV2Ug d291bGQgbGlrZSB0byBpbmZvcm0geW91IHRoYXQgdGhlIGUtbWFpbCBhZGRyZXNzIG9mIEdlcm1h bmlzY2hlciBMbG95ZCBhcyB3ZWxsIGFzIG91ciBpbnRlcm5ldCBhZGRyZXNzIGhhZCBiZWVuIGNo YW5nZWQgdG8gIGdsLWdyb3VwLmNvbSB3aXRoIGVmZmVjdCBmcm9tIDFzdCBNYXJjaCAyMDAzLiAN CiANClRoaXMgbWVhbnMgdGhhdCB0aGUgcHJldmlvdXMgYWRkcmVzcyBzaG9ydG1hcmtAZ2VybWFu bGxveWQub3JnIHdpbGwgYmUgcmVwbGFjZWQgYnkgc2hvcnRtYXJrQGdsLWdyb3VwLmNvbS4gRnJv bSBub3cgb24gdGhlIEdMIGhvbWVwYWdlIGNhbiBiZSBhY2Nlc3NlZCBhdCB0aGUgYWRkcmVzcyAn aHR0cDovL3d3dy5nbC1ncm91cC5jb20nLiBUaGUgb2xkIGFkZHJlc3NlcyByZW1haW4gdmFsaWQg Zm9yIGEgdHJhbnNpdGlvbmFsIHBlcmlvZC4gDQogDQogDQoqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqIA0KIA0KIA0KIA0KVGhpcyBlLW1haWwgY29u dGFpbnMgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGZvciB0aGUgZXhjbHVzaXZlIGF0dGVudGlv biBvZiB0aGUgaW50ZW5kZWQgYWRkcmVzc2VlLiBBbnkgYWNjZXNzIG9mIHRoaXJkIHBhcnRpZXMg dG8gdGhpcyBlLW1haWwgaXMgdW5hdXRob3Jpc2VkLiBBbnkgdXNlIG9mIHRoaXMgZS1tYWlsIGJ5 IHVuaW50ZW5kZWQgcmVjaXBpZW50cyBzdWNoIGFzIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiwgZGlz Y2xvc3VyZSBldGMuIGlzIHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gV2hlbiBhZGRy ZXNzZWQgdG8gb3VyIGNsaWVudHMgdGhlIGNvbnRlbnQgb2YgdGhpcyBlLW1haWwgaXMgc3ViamVj dCB0byB0aGUgR2VuZXJhbCBUZXJtcyBhbmQgQ29uZGl0aW9ucyBvZiBHTCdzIEdyb3VwIG9mIENv bXBhbmllcyBhcHBsaWNhYmxlIGF0IHRoZSBkYXRlIG9mIHRoaXMgZS1tYWlsLiAgDQogDQpHTCdz IEdyb3VwIG9mIENvbXBhbmllcyBkb2VzIG5vdCB3YXJyYW50IGFuZC9vciBndWFyYW50ZWUgdGhh dCB0aGlzIG1lc3NhZ2UgYXQgdGhlIG1vbWVudCBvZiByZWNlaXB0IGlzIGF1dGhlbnRpYywgY29y cmVjdCBhbmQgaXRzIGNvbW11bmljYXRpb24gZnJlZSBvZiBlcnJvcnMsIGludGVycnVwdGlvbiBl dGMuICANCiANCg== |
|
From: Colin J. W. <cj...@sy...> - 2003-12-10 13:31:16
|
Sebastian Haase wrote: >Hi Colin, >We are interested in using your PyMatrix packages (It' numarray not Numeric, >right?). > That is correct. Testing so far is with numarray 0.7. Please remember to also install the version 0.7 addons. When version 0.8 arrives, all will be included in one package. The package is intended for comment and review. There is at least one problem in numarray, which we hope will be resolved in version 0.8. For example, for some functions, upon the first call, the function returns an instance of the M class (matrix), on the second call, it returns an instance of the NumArray class. > First though, someone in my lab had the following concern: >What if I actually need the element-wise multiplication ? >(In other words: The Matlab .* operator) [1] <%5B1%5D> > >I understand that python does not allow to invent new operator symbols. > Yes. This issue was discussed in PEP 225 <http://www.python.org/peps/pep-0225.html>. >How about multiplying a Matrix with a Numarray ? > Please see [2] <#2>. >Is it possible to have a 'numarray view' of a Matrix object ? (I'm thinking >of two differently typed objects sharing one "value-memory space", so that >essentially the type determines which multiplication is being used ...) > There is a need to think through the copy/view approach in PyMatrix. Currently, most cases are copies. I'm inclined to deprecate the dual view approach, but I would appreciate comments. Let me know if you have any questions or comments. Colin W. >Thanks, >Sebastian Haase > > >----- Original Message ----- >From: "Colin J. Williams" <cj...@sy...> >Newsgroups: comp.lang.python,comp.lang.python.announce >To: "numpy-discussion" <num...@li...>; "SciPy >Discussion List" <sci...@sc...> >Cc: "Huaiyu Zhu" <hz...@us...> >Sent: Monday, November 24, 2003 5:17 AM >Subject: [Numpy-discussion] PyMatrix: Announcement > > > > >>PyMatrix is available for test and review. >> http://www3.sympatico.ca/cjw >> >>PyMatrix provides access to basic matrix arithmetic, using Python and >>numarray. >> >>Examples: >> A * B => the product of >>matrices A and B >> A.I => the inverse of matrix >> >> >A > > >> A.EVectors => the eigenvectors of A >> A.var(0) => the variances of the >>columns of A >> (a.T*a).I * a.T*b => the solution (x) for a * >>x = b, >> where a is a >>matrix and b a column vector >> >>This package was developed on a Windows XP. I would appreciate >>comments, particularly with respect to usage on other systems. >> >>Colin W. >> >> >> >> >> >>------------------------------------------------------- >>This SF.net email is sponsored by: SF.net Giveback Program. >>Does SourceForge.net help you be more productive? Does it >>help you create better code? SHARE THE LOVE, and help us help >>YOU! Click Here: http://sourceforge.net/donate/ >>_______________________________________________ >>Numpy-discussion mailing list >>Num...@li... >>https://lists.sourceforge.net/lists/listinfo/numpy-discussion >> >> >> Notes: [1] Elementwise Multiplication The thinking here is that, for most matrix usage, the elementwise multiplication is less frequently required. Thus, a more complex expression can be tolerated. See the example below: a= mRange(9, shape=(3, 3)) b= mRange((9, 18), shape= (3, 3)) print 'Matrixwise multiplation:' print 'a * b (prettyprinted):', pp(a * b) print 'Elementwise multiplation:' print 'a * b (prettyprinted):', pp(M(a.A * b.A))) In the last case, we use the array mechanism. The output is: Matrixwise multiplation: a * b (prettyprinted):matrix([[ 42, 45, 48], [150, 162, 174], [258, 279, 300]]) None Elementwise multiplation: a * b (prettyprinted):matrix([[ 0, 10, 22], [ 36, 52, 70], [ 90, 112, 136]]) None [2] Multiplication of a matrix by an array or nested list When an compatible array or list is juxtapositioned with a matrix, it is in effect coerced to the higher class. a= mRange(9, shape=(3, 3) c= N.arange(9, shape=(3, 3)) print 'A matrix multiplied by an array:' print 'a * c (prettyprinted):', pp(a * c) print 'A matrix multiplied by a list:' lst= [[0, 1, 2], [3, 4, 5], [6, 7, 8]] print 'a * lst (prettyprinted):', pp(a * lst) The output is: A matrix multiplied by an array: a * c (prettyprinted):matrix([[ 15, 18, 21], [ 42, 54, 66], [ 69, 90, 111]]) None A matrix multiplied by a list: a * lst (prettyprinted):matrix([[ 15, 18, 21], [ 42, 54, 66], [ 69, 90, 111]]) None |
|
From: Todd M. <jm...@st...> - 2003-12-09 22:55:41
|
Good news... I too see the problem in numarray-0.7, but it is already fixed in CVS for numarray-0.8. Thanks for the report. Regards, Todd On Tue, 2003-12-09 at 17:31, Edward C. Jones wrote: > numarray 0.7, Python 2.3.2, and Gentoo Linux 1.4. > > #! /usr/bin/env python > > import numarray > from numarray.numerictypes import * > > arr = numarray.zeros((4,4,4), Int32) > arr[0,3,2] = 1 > > a = numarray.sometrue(arr) > b = numarray.sometrue(arr) > > print a > print b > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Numpy-discussion mailing list > Num...@li... > https://lists.sourceforge.net/lists/listinfo/numpy-discussion -- Todd Miller <jm...@st...> |
|
From: Edward C. J. <edc...@er...> - 2003-12-09 22:35:17
|
numarray 0.7, Python 2.3.2, and Gentoo Linux 1.4. #! /usr/bin/env python import numarray from numarray.numerictypes import * arr = numarray.zeros((4,4,4), Int32) arr[0,3,2] = 1 a = numarray.sometrue(arr) b = numarray.sometrue(arr) print a print b |
|
From: Sebastian H. <ha...@ms...> - 2003-12-09 21:37:29
|
Hi Colin, We are interested in using your PyMatrix packages (It' numarray not Numeric, right?). First though, someone in my lab had the following concern: What if I actually need the element-wise multiplication ? (In other words: The Matlab .* operator) I understand that python does not allow to invent new operator symbols. How about multiplying a Matrix with a Numarray ? Is it possible to have a 'numarray view' of a Matrix object ? (I'm thinking of two differently typed objects sharing one "value-memory space", so that essentially the type determines which multiplication is being used ...) Thanks, Sebastian Haase ----- Original Message ----- From: "Colin J. Williams" <cj...@sy...> Newsgroups: comp.lang.python,comp.lang.python.announce To: "numpy-discussion" <num...@li...>; "SciPy Discussion List" <sci...@sc...> Cc: "Huaiyu Zhu" <hz...@us...> Sent: Monday, November 24, 2003 5:17 AM Subject: [Numpy-discussion] PyMatrix: Announcement > PyMatrix is available for test and review. > http://www3.sympatico.ca/cjw > > PyMatrix provides access to basic matrix arithmetic, using Python and > numarray. > > Examples: > A * B => the product of > matrices A and B > A.I => the inverse of matrix A > A.EVectors => the eigenvectors of A > A.var(0) => the variances of the > columns of A > (a.T*a).I * a.T*b => the solution (x) for a * > x = b, > where a is a > matrix and b a column vector > > This package was developed on a Windows XP. I would appreciate > comments, particularly with respect to usage on other systems. > > Colin W. > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Numpy-discussion mailing list > Num...@li... > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > |
|
From: Todd M. <jm...@st...> - 2003-12-09 18:17:04
|
I responded to Nadav about this earlier but accidentally made it private e-mail. In a nutshell, GPL'ed code doesn't belong in numarray. I am not familiar with the chirp-z-transform myself. Does anyone have numarray/Numeric code which does the chirp-z which we can include in numarray under a modified BSD license? Todd On Tue, 2003-12-09 at 01:48, Nadav Horesh wrote: > I am using a chirp-z-transform routine which I have ported from an > Octave m-file (GPL licensed). What should I do in order to offer it to > be included into the numarray.fft package? > > Nadav. > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Numpy-discussion mailing list > Num...@li... > https://lists.sourceforge.net/lists/listinfo/numpy-discussion -- Todd Miller <jm...@st...> |
|
From: Nadav H. <na...@Vi...> - 2003-12-09 06:49:47
|
I am using a chirp-z-transform routine which I have ported from an Octave m-file (GPL licensed). What should I do in order to offer it to be included into the numarray.fft package? Nadav. |
|
From: Subsumed <sub...@it...> - 2003-12-08 23:11:00
|
<body bgcolor=#cefae9> <center><font face="Arial"> <table cellspacing=0 cellpadding=0 border=0 width=550 id=5533235285> <tr id=1920210596><td id=6769480225 align=right> <table cellspacing=0 cellpadding=0 border=0 id=1715138666 width=200> <tr id=1754776835><td id=5031970092 align=right>Exprets in the Ne</td></tr> <tr id=6107611577><td id=2947425019 align=right>report that Humaan Gro</td></tr> <tr id=6699896905><td id=2672434682 align=right>maakes you look and fe</td></tr> </td></tr> </table> </td> <td> <table cellspacing=0 cellpadding=0 border=0 id=3028861472 width=300> <tr id=3393283974><td id=5912255714>w England Journal of Medicine,</td></tr> <tr id=9552349586><td id=7207635022>wth Hoormone therrappy</td></tr> <tr id=4715041612><td id=1186320279>el 10 YEARS YOUUNGERR!</td></tr> </td></tr> </table> </td> <td rowspan=2 width=50 align=center bgcolor=fafeff id=9519282785><b><a href="http://www.e-buy-net.com/hgh/index.php?pid=evaph3839">Folllow <font color=#ff0000>this</font> linnk for more info!</a></b></td> </tr> <tr><td colspan=2 id=2327368971> <br><br><b>Check out our discuont intenret specails, and<br> get yuor FRREE boottles of H GgH todaay!</b></td></tr> </table> </center> </font> </body> |
|
From: Sebastian H. <ha...@ms...> - 2003-12-08 22:27:46
|
I just realized that import numarray as na and from numarray import numeric as na actually just differ in the definition of zeros() (and 3 other calls) Hopefully I was the only one who missed this difference. I thought that since numarray 0.5 everything was now in sub-packages and the second way of doing the import was now the suggested one ... Now I think otherwise and it makes all sense again. Regards, Sebastian Haase > On Tue, 2003-12-02 at 19:44, Sebastian Haase wrote: > > Hi, > > I'm just trying to debug some PyOpenGl stuff . It seems that this is only > > available with Numeric (no numarray !?) > > > > Drawing a 60000 vertex array takes 6 sec ( should be much less than 0.5 sec > > !! ) > > I found this is because all my other code is using numarray and it is this > > conversion that takes so long. > > Switching to Numeric (and back to numarray) got this error message: > > [[[ Num is here numarray !! ]] > > self.m_histPlotArray = Num.zeros((n,2), typecode=Num.Float32) > > TypeError: zeros() got an unexpected keyword argument 'typecode' > > numarray is still weak in a few places for keyword names. Try 'type' > instead. > > Todd > > > > I thought numarray suppossed to be backwards compatible ... so I just > > report this as a bug. > > > > Regards, > > Sebastian > > |
|
From: Sebastian H. <ha...@ms...> - 2003-12-05 17:55:25
|
Hi,
I create a memmap file with mode 'w+'. But I forgot to assign a name to the
object. So just call the same function again.
But this time I get a "no such file error" ! a) the file actually does
exist , b) It shouldn't care, because mode == 'w+'.
This is the traceback I get : (len == 1024)
>>> Mrc.bindMrc("C:/mm7.mrc", mode='w+')
array([], type=Int8)
>>> a = Mrc.bindMrc("C:/mm7.mrc", mode='w+')
Traceback (most recent call last):
File "<input>", line 1, in ?
File "X:\PrWin\Priithon\Mrc.py", line 9, in bindMrc
a = Mrc(fn,mode)
File "X:\PrWin\Priithon\Mrc.py", line 43, in __init__
self.m = mm.open(filename=path, mode=mode, len=len)
File "X:\PrWin\numarray\memmap.py", line 762, in open
return Memmap(filename, mode, len)
File "X:\PrWin\numarray\memmap.py", line 269, in __init__
file = _open(filename, (mode == "c" and "r" or mode))
File "X:\PrWin\numarray\memmap.py", line 236, in _open
return __open(file, mode+"b")
IOError: [Errno 2] No such file or directory: 'C:/mm7.mrc'
Any idea how this error message could come about ?
Regards,
Sebastian Haase
|
|
From: Colin J. W. <cj...@sy...> - 2003-12-05 01:07:46
|
Thanks, I've copied the list here.
Colin W.
Sebastian Haase wrote:
>Hi Colin,
>Did you also forget to cc that message to the mailing list - because I just
>realized that I send my second mail directly to Perry (only)
>[I'm not part of the "numarray-team" - so you would need to resent this
>message to the list ...]
>
>Regards,
>Sebastian
>
>----- Original Message -----
>From: "Colin J. Williams" <cj...@sy...>
>To: "Sebastian Haase" <ha...@ms...>
>Sent: Thursday, December 04, 2003 4:01 PM
>Subject: Re: [Numpy-discussion] numarray.records - get/set item
>
>
>
>
>>Sebastian Haase wrote:
>>
>>
>>
>>>Hi,
>>>Is it maybe a good idea to add this to the definition of 'class Record'
>>>
>>>class Record:
>>> """Class for one single row."""
>>><snip>
>>> def __getitem__(self, fieldName):
>>> return self.array.field(fieldName)[self.row]
>>> def __setitem__(self, fieldName, value):
>>> self.array.field(fieldName)[self.row] = value
>>>
>>>I don't know about the implications if __delitem __ and so on are not
>>>defined.
>>>I just think it would look quite nice to say
>>>myRecArr[0]['mmm'] = 'hallo'
>>>as opposed to
>>>myRecArr[0].setfield('mmm', 'hallo')
>>>
>>>Actually I would even like
>>>myRecArr[0].mmm = 'hallo'
>>>
>>>This should be possible by defining __setattr__.
>>>It would obviously only work for fieldnames that do not contain '.' or '
>>>
>>>
>'
>
>
>>>or ...
>>>
>>>Any comments ?
>>>
>>>
>>>
>>>
>>I prefer this, it requires fewer key strokes and should be easy to do.
>>
>>Colin W.
>>
>>
>>
>>
>>
>
>
>
>
|
|
From: Sebastian H. <ha...@ms...> - 2003-12-05 00:27:39
|
My situation where I got onto this, is having one field named 'mmm'
("MinMaxMean") being an 3 element array.
Now, to assign the values first I tried:
self.hdrArray = makeHdrArray(self.h) #this makes the record array
self.hdr = self.hdrArray[0].field #this is my shortcut to the
bound member function
# it essentially is a solution (hack) for the getitem part
# but regarding setitem I had to learn that "assigning to a function" is
illigal in Python - as opposed to C++
#so to do assignment I need to do:
self.hdr('mmm')[0], self.hdr('mmm')[1], self.hdr('mmm')[2] = (mi,ma,av)
now that I'm looking at it,
self.hdrArray[0].setfield('mmm', (mi,ma,av))
would probably be better...
How about adding an attribute 'f' which could serve as a "proxy" to allow:
myRec.f.mmm = (mi,ma,av)
and maybe even additionally:
myRec.f['mmm'] = (mi,ma,av)
Regards,
Sebastian
----- Original Message -----
From: "Perry Greenfield" <pe...@st...>
To: "Sebastian Haase" <ha...@ms...>;
<num...@li...>
Sent: Thursday, December 04, 2003 3:08 PM
Subject: RE: [Numpy-discussion] numarray.records - get/set item
> > Hi,
> > Is it maybe a good idea to add this to the definition of 'class Record'
> >
> > class Record:
> > """Class for one single row."""
> > <snip>
> > def __getitem__(self, fieldName):
> > return self.array.field(fieldName)[self.row]
> > def __setitem__(self, fieldName, value):
> > self.array.field(fieldName)[self.row] = value
> >
> > I don't know about the implications if __delitem __ and so on are not
> > defined.
> > I just think it would look quite nice to say
> > myRecArr[0]['mmm'] = 'hallo'
> > as opposed to
> > myRecArr[0].setfield('mmm', 'hallo')
> >
> > Actually I would even like
> > myRecArr[0].mmm = 'hallo'
> >
> > This should be possible by defining __setattr__.
> > It would obviously only work for fieldnames that do not contain '.' or '
'
> > or ...
> >
> > Any comments ?
> >
> >
> We've had many internal discussions about doing this. The latter was
> considered a problem because of possible name collisions of field
> names with other attributes or methods. The former is not bothered
> by this problem, but we decided to be conservative on this and see
> how strong the need was. We are interested in other opinions.
>
> Perry
|
|
From: Perry G. <pe...@st...> - 2003-12-04 23:08:46
|
> Hi,
> Is it maybe a good idea to add this to the definition of 'class Record'
>
> class Record:
> """Class for one single row."""
> <snip>
> def __getitem__(self, fieldName):
> return self.array.field(fieldName)[self.row]
> def __setitem__(self, fieldName, value):
> self.array.field(fieldName)[self.row] = value
>
> I don't know about the implications if __delitem __ and so on are not
> defined.
> I just think it would look quite nice to say
> myRecArr[0]['mmm'] = 'hallo'
> as opposed to
> myRecArr[0].setfield('mmm', 'hallo')
>
> Actually I would even like
> myRecArr[0].mmm = 'hallo'
>
> This should be possible by defining __setattr__.
> It would obviously only work for fieldnames that do not contain '.' or ' '
> or ...
>
> Any comments ?
>
>
We've had many internal discussions about doing this. The latter was
considered a problem because of possible name collisions of field
names with other attributes or methods. The former is not bothered
by this problem, but we decided to be conservative on this and see
how strong the need was. We are interested in other opinions.
Perry
|
|
From: Sebastian H. <ha...@ms...> - 2003-12-04 22:41:32
|
Hi,
Is it maybe a good idea to add this to the definition of 'class Record'
class Record:
"""Class for one single row."""
<snip>
def __getitem__(self, fieldName):
return self.array.field(fieldName)[self.row]
def __setitem__(self, fieldName, value):
self.array.field(fieldName)[self.row] = value
I don't know about the implications if __delitem __ and so on are not
defined.
I just think it would look quite nice to say
myRecArr[0]['mmm'] = 'hallo'
as opposed to
myRecArr[0].setfield('mmm', 'hallo')
Actually I would even like
myRecArr[0].mmm = 'hallo'
This should be possible by defining __setattr__.
It would obviously only work for fieldnames that do not contain '.' or ' '
or ...
Any comments ?
Sebastian Haase
|
|
From: Jerome F. <jer...@ya...> - 2003-12-04 15:57:41
|
Hi, I would like to ask if anyone has worked on meshless methods or any of the below mentioned using python (with numpy or any other python open source tools)? -- reproducing kernel particle method -- smooth particle hydrodynamics -- moving least squares -- partition of unity -- meshless point collocation method -- galerkin method I'm going to be doing some simulation programs that need these methods. I hope to be able to add some value to the community and at the same time use whatever the community already has. Links or other info would also be very much appreciated. Thank you very much! Regards, Jerome |
|
From: Todd M. <jm...@st...> - 2003-12-04 10:21:25
|
On Wed, 2003-12-03 at 19:23, Edward C. Jones wrote:
> /*
> * When I use NA_IeeeSpecial64 in this little module, I get a
> * segfault. If I use MY_IeeeSpecial64, the program appears to
> * work. Anyone know what the problem is?
Did you "import_libnumarray();" in the module where you are trying to
use NA_IeeeSpecial64? If not, then the numarray C-API jump table
pointer (for that module) is uninitialized and leads to a segfault on
the first call through it.
Regards,
Todd
> Here is the Python code.
> *
> * #! /usr/bin/env python
> * import ieee
> * mask = ieee.POS_QUIET_NAN
> * print ieee.IeeeSpecial64(1.0, mask)
> */
>
> #include </usr/local/include/python2.3/Python.h>
> #include </usr/local/include/python2.3/numarray/numarray.h>
> #include </usr/local/include/python2.3/numarray/libnumarray.h>
>
> /* From libnumarraymodule.c or ieeespecial.ch */
> #define WITHIN64(v, f) (((v) >= f##_MIN64) && ((v) <= f##_MAX64))
> Bool MY_IeeeSpecial64( Float64 *f, Int32 *mask)
> {
> Int32 category;
> UInt64 *f1 = (UInt64 *) f;
> UInt64 v = *f1;
>
> if (v & BIT(63)) {
> if (WITHIN64(v, NEG_NORMALIZED)) {
> category = MSK_NEG_NOR;
> } else if (WITHIN64(v, NEG_DENORMALIZED)) {
> category = MSK_NEG_DEN;
> } else if (WITHIN64(v, NEG_SIGNAL_NAN)) {
> category = MSK_NEG_SNAN;
> } else if (WITHIN64(v, NEG_QUIET_NAN)) {
> category = MSK_NEG_QNAN;
> } else if (v == NEG_INFINITY_MIN64) {
> category = MSK_NEG_INF;
> } else if (v == NEG_ZERO_MIN64) {
> category = MSK_NEG_ZERO;
> } else if (v == INDETERMINATE_MIN64) {
> category = MSK_INDETERM;
> } else {
> category = MSK_BUG;
> }
> } else {
> if (WITHIN64(v, POS_NORMALIZED)) {
> category = MSK_POS_NOR;
> } else if (WITHIN64(v, POS_DENORMALIZED)) {
> category = MSK_POS_DEN;
> } else if (WITHIN64(v, POS_SIGNAL_NAN)) {
> category = MSK_POS_SNAN;
> } else if (WITHIN64(v, POS_QUIET_NAN)) {
> category = MSK_POS_QNAN;
> } else if (v == POS_INFINITY_MIN64) {
> category = MSK_POS_INF;
> } else if (v == POS_ZERO_MIN64) {
> category = MSK_POS_ZERO;
> } else {
> category = MSK_BUG;
> }
> }
> return (category & *mask) != 0;
> }
>
> static PyObject* IeeeSpecial64(PyObject* obj, PyObject *args)
> {
> Int32 mask;
> Bool b;
> Float64 value;
> PyObject* result;
>
> if (!PyArg_ParseTuple(args, "di:IeeeSpecial64", &value, &mask))
> return NULL;
>
> printf("%f %d\n", value, mask);
> /* Seems to work. */
> b = MY_IeeeSpecial64(&value, &mask);
> printf("L75 %d\n", b);
> /* The next line causes a segfault. */
> b = NA_IeeeSpecial64(&value, &mask);
> printf("L78 %d\n", b);
> if (b)
> result = Py_True;
> else
> result = Py_False;
>
> Py_INCREF(result);
> return result;
> }
>
> static PyMethodDef ieee_Methods[] = {
> {"IeeeSpecial64", IeeeSpecial64, METH_VARARGS, ""},
> {NULL, NULL, 0, NULL} /* sentinel */
> };
>
> PyMODINIT_FUNC initieee(void)
> {
> PyObject* m;
>
> m = Py_InitModule("ieee", ieee_Methods);
>
> PyModule_AddIntConstant(m, "POS_QUIET_NAN", (int) MSK_POS_QNAN);
> }
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive? Does it
> help you create better code? SHARE THE LOVE, and help us help
> YOU! Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
--
Todd Miller <jm...@st...>
|
|
From: Edward C. J. <edc...@er...> - 2003-12-04 00:26:50
|
/*
* When I use NA_IeeeSpecial64 in this little module, I get a
* segfault. If I use MY_IeeeSpecial64, the program appears to
* work. Anyone know what the problem is? Here is the Python code.
*
* #! /usr/bin/env python
* import ieee
* mask = ieee.POS_QUIET_NAN
* print ieee.IeeeSpecial64(1.0, mask)
*/
#include </usr/local/include/python2.3/Python.h>
#include </usr/local/include/python2.3/numarray/numarray.h>
#include </usr/local/include/python2.3/numarray/libnumarray.h>
/* From libnumarraymodule.c or ieeespecial.ch */
#define WITHIN64(v, f) (((v) >= f##_MIN64) && ((v) <= f##_MAX64))
Bool MY_IeeeSpecial64( Float64 *f, Int32 *mask)
{
Int32 category;
UInt64 *f1 = (UInt64 *) f;
UInt64 v = *f1;
if (v & BIT(63)) {
if (WITHIN64(v, NEG_NORMALIZED)) {
category = MSK_NEG_NOR;
} else if (WITHIN64(v, NEG_DENORMALIZED)) {
category = MSK_NEG_DEN;
} else if (WITHIN64(v, NEG_SIGNAL_NAN)) {
category = MSK_NEG_SNAN;
} else if (WITHIN64(v, NEG_QUIET_NAN)) {
category = MSK_NEG_QNAN;
} else if (v == NEG_INFINITY_MIN64) {
category = MSK_NEG_INF;
} else if (v == NEG_ZERO_MIN64) {
category = MSK_NEG_ZERO;
} else if (v == INDETERMINATE_MIN64) {
category = MSK_INDETERM;
} else {
category = MSK_BUG;
}
} else {
if (WITHIN64(v, POS_NORMALIZED)) {
category = MSK_POS_NOR;
} else if (WITHIN64(v, POS_DENORMALIZED)) {
category = MSK_POS_DEN;
} else if (WITHIN64(v, POS_SIGNAL_NAN)) {
category = MSK_POS_SNAN;
} else if (WITHIN64(v, POS_QUIET_NAN)) {
category = MSK_POS_QNAN;
} else if (v == POS_INFINITY_MIN64) {
category = MSK_POS_INF;
} else if (v == POS_ZERO_MIN64) {
category = MSK_POS_ZERO;
} else {
category = MSK_BUG;
}
}
return (category & *mask) != 0;
}
static PyObject* IeeeSpecial64(PyObject* obj, PyObject *args)
{
Int32 mask;
Bool b;
Float64 value;
PyObject* result;
if (!PyArg_ParseTuple(args, "di:IeeeSpecial64", &value, &mask))
return NULL;
printf("%f %d\n", value, mask);
/* Seems to work. */
b = MY_IeeeSpecial64(&value, &mask);
printf("L75 %d\n", b);
/* The next line causes a segfault. */
b = NA_IeeeSpecial64(&value, &mask);
printf("L78 %d\n", b);
if (b)
result = Py_True;
else
result = Py_False;
Py_INCREF(result);
return result;
}
static PyMethodDef ieee_Methods[] = {
{"IeeeSpecial64", IeeeSpecial64, METH_VARARGS, ""},
{NULL, NULL, 0, NULL} /* sentinel */
};
PyMODINIT_FUNC initieee(void)
{
PyObject* m;
m = Py_InitModule("ieee", ieee_Methods);
PyModule_AddIntConstant(m, "POS_QUIET_NAN", (int) MSK_POS_QNAN);
}
|
|
From: Resume <ry...@ya...> - 2003-12-03 21:31:57
|
RIC SIE Tel (408) 482-2840 rz...@ya... OBJECTIVE: STRUCTURAL & MECHANICAL DESIGNER CIVIL, ARCHITECTURAL, TRANSPORTATION CAD Operator EXPERIENCE: 93 - present DESIGNER, ENGINEER, CAD MANAGER; "Mech-Tronic" Engineering & Design Service, Project Management & Development. Preparing technical documentation, calculations, layouts drawings & propositions. CAD Management and Operations, drafting & redesigning. Intergraph, MicroStation, Autodesk, ACAD, Win, Net, Softdesk Mgmt Civil, Bridges and Structural Design, Plans, Mapping, Detail Freeway & Roadway, data translation & inserting. Script & CAD automation. Geological Structures, Viaducts, Freeways, Highways, Shopping Center. Architectural and Environmental Projects and cooperation; military facilities and plans, Cities, Airports, remediation drawings upgrade, correcting and redesign. Traffic design & problem analyzes-reorganize. Freeway Design & Drafting Support, Site analyzing for Caltrans, Architectural, Archeotype & Electrical drawings, "as is" and initial design; Develop remediation procedure and equipment for lead painted buildings. Construction management, Job site inspection, civil & structural support Mechanical Evaluations - Design - Service and Maintenance; R&D. EDUCATION: Institute for Business & Technology, California CAD Engineer, Programming, Design, Management Electro - Mechanical College Mechanical Engineering - BS Degree DOS, UNIX, MAC, SUN computers; WP, dBASE, Lotus, Network, Lisp, Windows & Appl., PFS, Graphics, CAD/CAM, Basic, Fortran, Analyzes. METRIC, SOLAR, AutoCAD/Computer Instructor. Transportation Spec. Personal Designer, MS Project, MS Works, Excel, Access, C, Script, File Management, File transfer. Learn quickly, work independly, shift, overtime |
|
From: Todd M. <jm...@st...> - 2003-12-03 19:51:34
|
On Wed, 2003-12-03 at 13:47, Sebastian Haase wrote:
> Hi,
> I would like to use memmap array more often - here are some comments:
> (Please look for lines with $$$$)
>
> >>> from numarray import memmap as mm
> >>> m = mm.open("C:/mm1", mode='w+', len=0)
> >>> n = m.insert(0,0)
> >>> a = na.array(buffer=n)
> X:\PrWin\wxPython\lib\PyCrust\PyCrustApp.py:1: DeprecationWarning: The
> 'buffer' keyword is deprecated. Use 'sequence' instead.
> Exception exceptions.AttributeError: "Memmap instance has no attribute
> '_mode'" in Traceback (most recent call last):
> File "<input>", line 1, in ?
> File "X:\PrWin\numarray\numarraycore.py", line 279, in array
> type = getTypeObject(sequence, type, typecode)
> File "X:\PrWin\numarray\numarraycore.py", line 223, in getTypeObject
> return Py2NumType[ _maxtype(sequence) ]
> KeyError
>
> $$$$ Is this a mistake on my part or should the error message be "better"
> ???
How's this?:
Traceback (most recent call last):
File "sabby1.py", line 5, in ?
a = na.array(buffer=n)
File
"/home/jmiller/lib/python2.3/site-packages/numarray/numarraycore.py",
line 282, in array
type = getTypeObject(sequence, type, typecode)
File
"/home/jmiller/lib/python2.3/site-packages/numarray/numarraycore.py",
line 226, in getTypeObject
raise TypeError("Can't determine a reasonable type from sequence")
TypeError: Can't determine a reasonable type from sequence
>
> >>> a = na.array(buffer=n, type=na.UInt16, shape=(0,0,0))
> >>> a.shape
> (0, 0, 0)
> >>> m
> <Memmap on file 'C:/mm1' with mode='w+', length=0, 1 slices>
> >>> a.resize((100,100,100))
> >>> a.shape
> (100, 100, 100)
> >>> m.sync()
> >>> m.flush()
> Traceback (most recent call last):
> File "<input>", line 1, in ?
> File "X:\PrWin\numarray\memmap.py", line 501, in flush
> self._consolidate(filename)
> File "X:\PrWin\numarray\memmap.py", line 469, in _consolidate
> f.write(self._buffer(m, mlen))
> File "X:\PrWin\numarray\memmap.py", line 317, in _buffer
> raise RuntimeError("Memmap no longer valid. (closed?)")
> RuntimeError: Memmap no longer valid. (closed?)
> >>> m
> <Memmap on file 'C:/mm1' with mode='w+', length=0, 1 slices>
>
> $$$$ Is this a bug ?
Evidently. I logged it on SF.
Switching to a length 1 map seems to "fix" the problem so I think you've
discovered an interesting edge case bug in _consolidate(). I'm still
looking for the fix.
>
> My idea is to "prepare" the memmap file before I actually know the array
> dimensions that should go into it. Is that a good idea ?
In theory, yes. In reality... apparently not.
>
> Thanks,
> Sebastian Haase
Regards,
Todd
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive? Does it
> help you create better code? SHARE THE LOVE, and help us help
> YOU! Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
--
Todd Miller
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576
|
|
From: Nils W. <wag...@vd...> - 2003-12-03 19:20:37
|
Dear experts, Please, can someone explain the reason for using squeeze in Matrix.py http://cvs.sourceforge.net/viewcvs.py/numpy/Numerical/Lib/ Matrix.py?r1=1.20&r2=1.21 http://cvs.sourceforge.net/viewcvs.py/numpy/Numerical/Lib/ Matrix.py?r1=1.18&r2=1.19 Thanks in advance. Nils |
258 messages has been excluded from this view by a project administrator.
