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

You can subscribe to this list here.

 2000 2001 2002 2003 2004 2005 2006 Jan (8) Feb (49) Mar (48) Apr (28) May (37) Jun (28) Jul (16) Aug (16) Sep (44) Oct (61) Nov (31) Dec (24) Jan (56) Feb (54) Mar (41) Apr (71) May (48) Jun (32) Jul (53) Aug (91) Sep (56) Oct (33) Nov (81) Dec (54) Jan (72) Feb (37) Mar (126) Apr (62) May (34) Jun (124) Jul (36) Aug (34) Sep (60) Oct (37) Nov (23) Dec (104) Jan (110) Feb (73) Mar (42) Apr (8) May (76) Jun (14) Jul (52) Aug (26) Sep (108) Oct (82) Nov (89) Dec (94) Jan (117) Feb (86) Mar (75) Apr (55) May (75) Jun (160) Jul (152) Aug (86) Sep (75) Oct (134) Nov (62) Dec (60) Jan (187) Feb (318) Mar (296) Apr (205) May (84) Jun (63) Jul (122) Aug (59) Sep (66) Oct (148) Nov (120) Dec (70) Jan (460) Feb (683) Mar (589) Apr (559) May (445) Jun (712) Jul (815) Aug (663) Sep (559) Oct (930) Nov (373) Dec
S M T W T F S

1
(13)
2
(1)
3
(10)
4
(11)
5
(18)
6
(42)
7
(34)
8
(19)
9
(5)
10
(2)
11
(3)
12
(2)
13
(1)
14
(4)
15
(9)
16
(4)
17
(1)
18
(4)
19
(2)
20
(4)
21
(1)
22
(1)
23

24

25
(2)
26
(4)
27
(2)
28

29
(6)
30

Showing results of 205

1 2 3 .. 9 > >> (Page 1 of 9)
 Re: [Numpy-discussion] numarray: lexicographical sort From: Todd Miller - 2005-04-29 19:39:21 ```On Fri, 2005-04-29 at 14:30, Edward C. Jones wrote: > Suppose arr is a two dimensional numarray. Can the following be done > entirely within numarray? > > alist = arr.tolist() > alist.sort() > arr = numarray.array(alist, arr.type()) > I'm pretty sure the answer is no. The comparisons in numarray's sort() functions are all single element numerical comparisons. The list sort() is using a polymorphic comparison which in this case is the comparison of two lists. There's nothing like that in numarray so I don't think it's possible. Todd ```
 [Numpy-discussion] numarray: lexicographical sort From: Edward C. Jones - 2005-04-29 18:29:55 ```Suppose arr is a two dimensional numarray. Can the following be done entirely within numarray? alist = arr.tolist() alist.sort() arr = numarray.array(alist, arr.type()) ```
 [Numpy-discussion] numarray: problem with numarray.records From: Edward C. Jones - 2005-04-29 18:21:24 ```#! /usr/bin/env python import numarray, numarray.strings, numarray.records doubles = numarray.array([1.0], 'Float64') strings = numarray.strings.array('abcdefgh', itemsize=8, kind=numarray.strings.RawCharArray) print numarray.records.array(buffer=[strings, strings]) print print numarray.records.array(buffer=[doubles, doubles]) print print numarray.records.array(buffer=[strings, doubles]) """ The output is: RecArray[ ('abcdefgh'), ('abcdefgh') ] RecArray[ (1.0, 1.0) ] Traceback (most recent call last): File "./mess.py", line 12, in ? print numarray.records.array(buffer=[strings, doubles]) File "/usr/local/lib/python2.4/site-packages/numarray/records.py", line 397, in array byteorder=byteorder, aligned=aligned) File "/usr/local/lib/python2.4/site-packages/numarray/records.py", line 106, in fromrecords raise ValueError, "inconsistent data at row %d,field %d" % (row, col) ValueError: inconsistent data at row 1,field 0 The numarray docs (11.2) say: The first argument, buffer, may be any one of the following: ... (5) a list of numarrays. There must be one such numarray for each field. What is going on here? """ ```
 Re: [Numpy-discussion] numarray dotblas problem on OSX From: Robert Kern - 2005-04-29 01:07:33 ```Robert Kern wrote: > Simon Burton wrote: > >> Hi, >> >> I have a colleague running Mac OS 10.3, running numarray-1.3.1 (from >> fink) >> who has managed to bomb on this little code example: >> >> >>>>> import numarray as na >>>>> import numarray.random_array as ra >>>>> a = ra.random(shape=(257,256)) >>>>> b = ra.random(shape=(1,256)) >>>>> na.innerproduct(a, b) >> >> >> >> He gets a blas error: >> >> ldc must be >= MAX(N,1): ldc=256 N=257Parameter 14 to routine >> cblas_dgemm was incorrect >> Mac OS BLAS parameter error in cblas_dgemm, parameter #0, >> (unavailable), is 0 > > > On OS X 10.3, numarray 1.3.0, self-compiled for the Apple-installed > Python with vecLib as the BLAS, I don't get an error. > > I don't get a result that's sensible to me, either; I get a > (257,1)-shape array with only the first and last entries non-zero. Oh yes, and apparently a segfault on exit, too. -- Robert Kern rkern@... "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter ```
 Re: [Numpy-discussion] numarray dotblas problem on OSX From: Robert Kern - 2005-04-29 01:03:12 ```Simon Burton wrote: > Hi, > > I have a colleague running Mac OS 10.3, running numarray-1.3.1 (from fink) > who has managed to bomb on this little code example: > > >>>>import numarray as na >>>>import numarray.random_array as ra >>>>a = ra.random(shape=(257,256)) >>>>b = ra.random(shape=(1,256)) >>>>na.innerproduct(a, b) > > > He gets a blas error: > > ldc must be >= MAX(N,1): ldc=256 N=257Parameter 14 to routine cblas_dgemm was incorrect > Mac OS BLAS parameter error in cblas_dgemm, parameter #0, (unavailable), is 0 On OS X 10.3, numarray 1.3.0, self-compiled for the Apple-installed Python with vecLib as the BLAS, I don't get an error. I don't get a result that's sensible to me, either; I get a (257,1)-shape array with only the first and last entries non-zero. Your colleague might want to reconsider whether he wants innerproduct() or dot(), with the appropriate change of shape for b. -- Robert Kern rkern@... "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter ```
 [Numpy-discussion] numarray dotblas problem on OSX From: Simon Burton - 2005-04-29 00:31:23 ```Hi, I have a colleague running Mac OS 10.3, running numarray-1.3.1 (from fink) who has managed to bomb on this little code example: >>> import numarray as na >>> import numarray.random_array as ra >>> a = ra.random(shape=(257,256)) >>> b = ra.random(shape=(1,256)) >>> na.innerproduct(a, b) He gets a blas error: ldc must be >= MAX(N,1): ldc=256 N=257Parameter 14 to routine cblas_dgemm was incorrect Mac OS BLAS parameter error in cblas_dgemm, parameter #0, (unavailable), is 0 Simon. -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 02 6249 6940 http://arrowtheory.com ```
 Re: [Numpy-discussion] numarray, Numeric and 64-bit platforms From: Todd Miller - 2005-04-27 15:29:42 ```On Wed, 2005-04-27 at 08:32, Francesc Altet wrote: > A Dimarts 26 Abril 2005 22:55, Todd Miller va escriure: > > > The problem is that, for 32-bit platforms, na.typecode() == 'i' as it > > > should be, but for 64-bit platforms na.typecode() == 'N' that is not a > > > valid type in Numeric. I guess that na.typecode() should be mapped to > > > 'l' in 64-bit platforms so that Numeric can recognize the Int64 > > > correctly. > > > > I agree that since the typecode() method exists for backward > > compatibility, returning 'N' rather than 'l' on an LP64 platform can be > > considered a bug. However, there are two problems I see: > > > > 1. Returning 'l' doesn't handle the case of converting a numarray Int64 > > array on a 32-bit platform. AFIK, there is no typecode that will work > > for that case. So, we're only getting a partial solution. > > One can always do a separate case for 64-bit platforms. This solution > is already used in Lib/numerictypes.py True. I'm just pointing out that doing this is still "half broken". On the other hand, it is also "half fixed". > if numinclude.hasUInt64: > _MaximumType = { > --------------------------------------------------------------- > > With that, we have on 64-bit platforms: > > >>> import Numeric > >>> Num=Numeric.array((3,),typecode='l') > >>> import numarray > >>> na=numarray.array(Num,typecode=Num.typecode()) > >>> Numeric.array(na,typecode=na.typecode()) > array([3]) > >>> Numeric.array(na,typecode=na.typecode()).typecode() > 'l' > > and on 32-bit: > > >>> Num=Numeric.array((3,),typecode='l') > >>> na=numarray.array(Num,typecode=Num.typecode()) > >>> Numeric.array(na,typecode=na.typecode()) > array([3],'i') > >>> Numeric.array(na,typecode=na.typecode()).typecode() > 'i' > > Which should be the correct behaviour. My point was that if you have a numarray Int64 array, there's nothing in 32-bit Numeric to convert it to. Round tripping from Numeric-to-numarray works, but not from numarray-to-Numeric. In this case, I think "half-fixed" still has some merit, I just wanted it to be clear what we're not doing. > > I think we may be butting up against the absolute/relative type > > definition problem. Comments? > > That may add some confusion, but if we want to be consistent with the > 'l' (long int) meaning for different platforms, I think the suggested > patch (or other more elegant) is the way to go, IMHO. I logged this on Source Forge and will get something in for numarray-1.4 so that the typecode() method gives a workable answer on LP64. Intersted parties should stick to using the typecode() method rather than any of numarray's typecode related mappings. Cheers, Todd ```
 Re: [Numpy-discussion] numarray, Numeric and 64-bit platforms From: Francesc Altet - 2005-04-27 12:33:07 ```A Dimarts 26 Abril 2005 22:55, Todd Miller va escriure: > > The problem is that, for 32-bit platforms, na.typecode() =3D=3D 'i' as = it > > should be, but for 64-bit platforms na.typecode() =3D=3D 'N' that is no= t a > > valid type in Numeric. I guess that na.typecode() should be mapped to > > 'l' in 64-bit platforms so that Numeric can recognize the Int64 > > correctly. > > I agree that since the typecode() method exists for backward > compatibility, returning 'N' rather than 'l' on an LP64 platform can be > considered a bug. However, there are two problems I see: > > 1. Returning 'l' doesn't handle the case of converting a numarray Int64 > array on a 32-bit platform. AFIK, there is no typecode that will work > for that case. So, we're only getting a partial solution. One can always do a separate case for 64-bit platforms. This solution is already used in Lib/numerictypes.py > 2. numarray uses typecodes internally to encode type signatures. There, > platform-independent typecodes are useful and making this change will > add confusion. Well, this is the root of the problem for 'l' (long int) types, that their meaning depends on the platform. Anyway, I've tried with the next patch, and everything seems to work well (i.e. it's done what it is itended): =2D------------------------------------------------------------- =2D-- Lib/numerictypes.py Wed Apr 27 07:13:08 2005 +++ Lib/numerictypes.py.modif Wed Apr 27 07:21:48 2005 @@ -389,7 +389,11 @@ # at code generation / installation time. from codegenerator.ufunccode import typecode for tname, tcode in typecode.items(): =2D typecode[ eval(tname)] =3D tcode + if tname =3D=3D "Int64" and numinclude.LP64: + typecode[ eval(tname)] =3D 'l' + else: + typecode[ eval(tname)] =3D tcode + if numinclude.hasUInt64: _MaximumType =3D { =2D-------------------------------------------------------------- With that, we have on 64-bit platforms: >>> import Numeric >>> Num=3DNumeric.array((3,),typecode=3D'l') >>> import numarray >>> na=3Dnumarray.array(Num,typecode=3DNum.typecode()) >>> Numeric.array(na,typecode=3Dna.typecode()) array([3]) >>> Numeric.array(na,typecode=3Dna.typecode()).typecode() 'l' and on 32-bit: >>> Num=3DNumeric.array((3,),typecode=3D'l') >>> na=3Dnumarray.array(Num,typecode=3DNum.typecode()) >>> Numeric.array(na,typecode=3Dna.typecode()) array([3],'i') >>> Numeric.array(na,typecode=3Dna.typecode()).typecode() 'i' Which should be the correct behaviour. > I think we may be butting up against the absolute/relative type > definition problem. Comments? That may add some confusion, but if we want to be consistent with the 'l' (long int) meaning for different platforms, I think the suggested patch (or other more elegant) is the way to go, IMHO. Cheers, =2D-=20 >0,0< Francesc Altet =A0 =A0 http://www.carabos.com/ V V C=E1rabos Coop. V. =A0=A0Enjoy Data "-" ```
 Re: [Numpy-discussion] numarray, Numeric and 64-bit platforms From: Todd Miller - 2005-04-26 20:55:52 ```On Tue, 2005-04-26 at 13:42, Francesc Altet wrote: > Hi, > > I'm having problems converting numarray objects into Numeric in 64-bit > platforms, and I think this is numarray fault, but I'm not completely > sure. > > The problem can be easily visualized in an example (I'm using numarray > 1.3.1 and Numeric 24.0b2). In a 32-bit platform (Intel32, Linux): > > >>> Num=Numeric.array((3,),typecode='l') > >>> na=numarray.array(Num,typecode=Num.typecode()) > >>> Numeric.array(na,typecode=na.typecode()) > array([3],'i') # The conversion has finished correctly > > In 64-bit platforms (AMD64, Linux): > > >>> Num=Numeric.array((3,),typecode='l') > >>> na=numarray.array(Num,typecode=Num.typecode()) > >>> Numeric.array(na,typecode=na.typecode()) > Traceback (most recent call last): > File "", line 1, in ? > TypeError: typecode argument must be a valid type. > > The problem is that, for 32-bit platforms, na.typecode() == 'i' as it > should be, but for 64-bit platforms na.typecode() == 'N' that is not a > valid type in Numeric. I guess that na.typecode() should be mapped to > 'l' in 64-bit platforms so that Numeric can recognize the Int64 > correctly. > > Any suggestion? I agree that since the typecode() method exists for backward compatibility, returning 'N' rather than 'l' on an LP64 platform can be considered a bug. However, there are two problems I see: 1. Returning 'l' doesn't handle the case of converting a numarray Int64 array on a 32-bit platform. AFIK, there is no typecode that will work for that case. So, we're only getting a partial solution. 2. numarray uses typecodes internally to encode type signatures. There, platform-independent typecodes are useful and making this change will add confusion. I think we may be butting up against the absolute/relative type definition problem. Comments? Todd ```
 [Numpy-discussion] numarray, Numeric and 64-bit platforms From: Francesc Altet - 2005-04-26 17:43:05 ```Hi, I'm having problems converting numarray objects into Numeric in 64-bit platforms, and I think this is numarray fault, but I'm not completely sure.=20 The problem can be easily visualized in an example (I'm using numarray 1.3.1 and Numeric 24.0b2). In a 32-bit platform (Intel32, Linux): >>> Num=3DNumeric.array((3,),typecode=3D'l') >>> na=3Dnumarray.array(Num,typecode=3DNum.typecode()) >>> Numeric.array(na,typecode=3Dna.typecode()) array([3],'i') # The conversion has finished correctly In 64-bit platforms (AMD64, Linux): >>> Num=3DNumeric.array((3,),typecode=3D'l') >>> na=3Dnumarray.array(Num,typecode=3DNum.typecode()) >>> Numeric.array(na,typecode=3Dna.typecode()) Traceback (most recent call last): File "", line 1, in ? TypeError: typecode argument must be a valid type. The problem is that, for 32-bit platforms, na.typecode() =3D=3D 'i' as it should be, but for 64-bit platforms na.typecode() =3D=3D 'N' that is not a valid type in Numeric. I guess that na.typecode() should be mapped to 'l' in 64-bit platforms so that Numeric can recognize the Int64 correctly. Any suggestion? =2D-=20 >0,0< Francesc Altet =A0 =A0 http://www.carabos.com/ V V C=E1rabos Coop. V. =A0=A0Enjoy Data "-" ```
 [Numpy-discussion] numarray problems on AIX From: Jeff Whitaker - 2005-04-26 14:55:04 ```Hi: I'm having problems with numarray 1.3.1/Python 2.4.1 on AIX 5.2: Python 2.4.1 (#3, Apr 26 2005, 10:34:56) [C] on aix5 Type "help", "copyright", "credits" or "license" for more information. >>> import numarray Traceback (most recent call last): File "", line 1, in ? File "/u/wx20wj/home/blue/lib/python2.4/site-packages/numarray/__init__.py", line 42, in ? from numarrayall import * File "/u/wx20wj/home/blue/lib/python2.4/site-packages/numarray/numarrayall.py", line 2, in ? from generic import * File "/u/wx20wj/home/blue/lib/python2.4/site-packages/numarray/generic.py", line 1116, in ? import numarraycore as _nc File "/u/wx20wj/home/blue/lib/python2.4/site-packages/numarray/numarraycore.py", line 1751, in ? import ufunc File "/u/wx20wj/home/blue/lib/python2.4/site-packages/numarray/ufunc.py", line 13, in ? import _converter ImportError: dynamic module does not define init function (init_converter) it works with AIX 4 - anyone seen this before? -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX : (303)497-6449 NOAA/OAR/CDC R/CDC1 Email : Jeffrey.S.Whitaker@... 325 Broadway Office : Skaggs Research Cntr 1D-124 Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg ```
 [Numpy-discussion] Please confirm your request to join IErussian From: Yahoo! Groups - 2005-04-26 10:08:33 ``` Hello numpy-discussion@..., We have received your request to join the IErussian group hosted by Yahoo! Groups, a free, easy-to-use community service. This request will expire in 7 days. TO BECOME A MEMBER OF THE GROUP: 1) Go to the Yahoo! Groups site by clicking on this link: http://groups.yahoo.com/i?i=anNSKqzsyA7slXUGUdYHvlkpsPI&e=numpy-discussion%40lists%2Esourceforge%2Enet (If clicking doesn't work, "Cut" and "Paste" the line above into your Web browser's address bar.) -OR- 2) REPLY to this email by clicking "Reply" and then "Send" in your email program If you did not request, or do not want, a membership in the IErussian group, please accept our apologies and ignore this message. Regards, Yahoo! Groups Customer Care Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ ```
 Re: [Numpy-discussion] Value selections? From: Robert Kern - 2005-04-25 18:56:30 ```Stephen Walton wrote: > I'm trying out Numeric 24b2. In numarray, the following code will plot > the values of an array which are not equal to 'flag': > > f = array!=flag > plot(array[f]) > > What is the equivalent in Numeric 24b2? compress(f, array) is the lowest common denominator. I'm not sure if Numeric 24 gets fancier like numarray. -- Robert Kern rkern@... "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter ```
 [Numpy-discussion] Value selections? From: Stephen Walton - 2005-04-25 18:49:37 ```I'm trying out Numeric 24b2. In numarray, the following code will plot the values of an array which are not equal to 'flag': f = array!=flag plot(array[f]) What is the equivalent in Numeric 24b2? ```
 Re: [Numpy-discussion] Numeric 24.0 From: Travis Oliphant - 2005-04-22 10:50:27 ```Alexander Schmolck wrote: >Travis Oliphant writes: > > > >>I've released Numeric 24.0 as a beta (2nd version) release. Right now it's >>just a tar file. >> >>Please find any bugs. I'll wait a week or two and release a final version >>unless I hear reports of problems. >> >> > > >I suspect some other problems I haven't tried to track down yet are due to >this: > > >>> a = num.array([[1],[2],[3]]) > >>> ~(a==a) > array([[-2], > [-2], > [-2]]) > > What is wrong with this? ~ is bit-wise not and gives the correct answer, here. > >Object array comparisons still produce haphazard behaviour: > > >>> a = num.array(["ab", "cd", "efg"], 'O') > >>> a == 'ab' > 0 > > You are mixing Object arrays and character arrays here and expecting too much. String arrays in Numeric and their relationship with object arrays have never been too useful. You need to be explicit about how 'ab' is going to be interpreted and do a == array('ab','O') to get what you were probably expecting. >Finally -- not necessarily a bug, but a change of behaviour that seems undocumented (I'm >pretty sure this used to give a float array as return value): > > >>> num.zeros((2.0,)) > *** TypeError: an integer is required > > > >'as > > I don't think this worked as you think it did (I looked at Numeric 21.3). num.zeros(2.0) works but it shouldn't. This is a bug that I'll fix. Shapes should be integers, not floats. If this was not checked before than that was a bug. It looks like it's always been checked differently for single-element tuples and scalars So, in short, I see only one small bug here. Thanks for testing things out. -Travis ```
 [Numpy-discussion] ANN: numarray-1.3.1 From: Todd Miller - 2005-04-21 15:10:47 ```Release Notes for numarray-1.3.1 Numarray is an array processing package designed to efficiently manipulate large multi-dimensional arrays. Numarray is modelled after Numeric and features c-code generated from python template scripts, the capacity to operate directly on arrays in files, arrays of heterogeneous records, string arrays, and in-place operation on memory mapped files. I. ENHANCEMENTS None. 1.3.1 fixes the problem with gcc-3.4.3 II. BUGS FIXED / CLOSED 1152323 /usr/include/fenv.h:96: error: conflicting types for 'fegete 1185024 numarray-1.2.3 fails to compile with gcc-3.4.3 1187162 Numarray 1.3.0 installation failure See http://sourceforge.net/tracker/?atid=450446&group_id=1369&func=browse for more details. ```
 [Numpy-discussion] Numeric 24.0 From: Travis Oliphant - 2005-04-20 19:04:47 ```I've released Numeric 24.0 as a beta (2nd version) release. Right now it's just a tar file. Please find any bugs. I'll wait a week or two and release a final version unless I hear reports of problems. Thanks to those who have found bugs already. David Cooke has been especially active in helping fix problems. Many kudos to him. -Travis ```
 Re: [Numpy-discussion] Installing Numeric3 using the Borland Compiler From: - 2005-04-20 18:59:48 ```On Wed, 20 Apr 2005, Colin J. Williams wrote: > I have tried: > > python setup.py install build_ext --compiler=bcpp > > It seems that the distutils call uses scipy.distutils, rather than the > standard, and that the scipy version is based on an older version of > distutils. > > Is there some way to work around this? So, what problems exactly to you experience with the above command? Using scipy.distutils should not be much different compared to std distutils when building std extension modules. Pearu ```
 [Numpy-discussion] Installing Numeric3 using the Borland Compiler From: Colin J. Williams - 2005-04-20 07:44:27 ```I have tried: python setup.py install build_ext --compiler=bcpp It seems that the distutils call uses scipy.distutils, rather than the standard, and that the scipy version is based on an older version of distutils. Is there some way to work around this? Colin W. ```
 [Numpy-discussion] job openings at Enthought From: eric jones - 2005-04-20 05:47:29 ```Hey group, We have a number of scientific/python related jobs open. If you have any interest, please see: http://www.enthought.com/careers.htm thanks, eric ```
 Re: [Numpy-discussion] Numeric 24.0 From: Francesc Altet - 2005-04-19 10:03:08 ```Hi, I was curious about the newly introduced array protocol in Numeric 24.0 (as well as in current numarray CVS), and wanted to check if there is better speed during Numeric <-> numarray objects conversion. There answer is "partially" affirmative: >>> import numarray >>> import Numeric >>> print numarray.__version__ 1.4.0 >>> print Numeric.__version__ 24.0 >>> from time import time >>> a =3D numarray.arange(100*1000) >>> t1=3Dtime();b=3DNumeric.array(a);time()-t1 # numarray --> Numeric 0.0021419525146484375 # It was 1.58109998703 with Numeric 23.8 ! So, numarray --> Numeric speed has been improved quite a lot On the other way round, Numeric to numarray is not as efficient: >>> Na =3D Numeric.arange(100*1000) >>> t1=3Dtime();c=3Dnumarray.array(Na);time()-t1 # Numeric --> numarray 0.15217900276184082 # It is much slower than numarray --> Numeric I guess that the numarray --> Numeric can be speed-up because: >>>=20 t1=3Dtime();Nb=3Dnumarray.array(buffer(Na),typecode=3DNa.typecode(),shape= =3DNa.shape);time()-t1 0.00017499923706054688 # Numeric --> numarray using the buffer protocol So, I guess CVS numarray is still refining the array protocol. But the thing that mostly shocks me is why the array protocol is still allowing doing conversions with memory copies because, as you can see in the last example that uses a buffer protocol, a non-copy memory conversion is indeed possible for numarray --> Numeric. So the question is: Would the array protocol bring numarray <-> Numeric <-> Numeric3 conversions without memory copies or this is more a wish on my half than an actual possibility? Thanks and keep the nice work! =2D-=20 >0,0< Francesc Altet =A0 =A0 http://www.carabos.com/ V V C=E1rabos Coop. V. =A0=A0Enjoy Data "-" ```
 [Numpy-discussion] Numeric 24.0 From: Travis Oliphant - 2005-04-19 00:06:57 ```I am going to release Numeric 24.0 today or tomorrow unless I hear from anybody about some changes that need to get made. -Travis ```
 Re: [Numpy-discussion] bytes object info From: Sebastian Haase - 2005-04-18 16:14:37 ```Hey, this _really_ is no SPAM ... ;-) (Maybe different wording next time) Thanks, Sebastian Haase On Saturday 16 April 2005 03:22, Florian Schulze wrote: > Hi! > > I just discovered this: > http://members.dsl-only.net/~daniels/Block.html > > I didn't try it out, but maybe it's helpful to you. > > Regards, > Florian Schulze > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion@... > https://lists.sourceforge.net/lists/listinfo/numpy-discussion ```
 Re: [Numpy-discussion] numarray cholesky solver ? From: Todd Miller - 2005-04-18 13:35:46 ```On Sun, 2005-04-17 at 23:43, Simon Burton wrote: > On Fri, 15 Apr 2005 06:44:02 -0400 > Todd Miller wrote: > > > On Fri, 2005-04-15 at 16:04 +1000, Simon Burton wrote: > > > Hi, > > > > > > I see there is a cholesky_decomposition routine in numarray, but we are also needing the corresponding cholesky solver. > > > Is this in the pipeline, > > > > No. Most of the add-on subpackages in numarray, with the exception of > > convolve, image, and nd_image, are ports from Numeric. > > > > Ok, thanks Todd; we will have a go at porting this solver then. If you have any more advice on how to get started with this > that would be much appreciated. If you're doing a port of something that already works for Numeric chances are good that numarray's Numeric compatibility API will make things "just work." In any case, be sure to use the compatibility API since it's the easiest path forward to Numeric3 should that effort prove successful (which I think it will). Usually what's involved in porting from Numeric to numarray is just making sure that the numarray files can be used rather than the Numeric header files. I think the style we used for matplotlib, while not fully general, is the simplest and best compromise: #ifdef NUMARRAY #include "numarray/arrayobject.h" #else #include "Numeric/arrayobject.h" #endif In setup.py, you have to pass extra_compile_args=["-DNUMARRAY=1"] or similar to the Extension() constructions to build for numarray. There are more details we could discuss if you want to build for both Numeric and numarray simultaneously. Two limitations of the numarray Numeric compatible C-API are: (1) a partially compatible array descriptor structure (PyArray_Descr) and (2) the UFunc C-API. Generally, neither of those is an issue, but for large projects (e.g. scipy) they matter. Good luck porting. Feel free to ask questions either on the list or privately if you run into trouble. Regards, Todd ```
 [Numpy-discussion] scipy.base - % and fmod segfault From: Arnd Baecker - 2005-04-18 07:29:27 ```Hi (in particular Travis), concerning my recent question on % on fmod for Numeric and numarray I was curious to see how scipy.base behaves. With a CVS check-out this morning I get: In [1]: from scipy.base import * In [2]: x=arange(10) In [3]: print x%4 array([0, 1, 2, 3, 0, 1, 2, 3, 0, 1], 'l') In [4]: print (-x)%4 zsh: 12391 segmentation fault ipython (The same holds for fmod, and also for x=arange(10.0) ). Personally I would prefer if in the end % behaves the same way for arrays as for scalars. Do you think that this is possible with scipy.base? Best, Arnd P.S.: I haven't tested much more of scipy.base this time (but the few things concerning array operations I looked at, seem fine. Ah there is one: Doing import scipy.base scipy.base.fmod? in ipython gives a segmentation fault (the same with .sin, .exp etc. ...) ) ```

Showing results of 205

1 2 3 .. 9 > >> (Page 1 of 9)