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: David M. C. <co...@ph...> - 2006-01-31 23:41:50
|
On Jan 24, 2006, at 14:36 , Pearu Peterson wrote: > On Tue, 24 Jan 2006, Robert Kern wrote: > >> Pearu Peterson wrote: >>> Could you try recent version of numpy from SVN? __config__.py is now >>> generated via py_modules list. >> >> It doesn't build an egg, yet, because setuptools expects >> Distribution.py_modules >> to contain only strings, not tuples. Modifying setuptools to >> handle tuples in >> Distribution.py_modules seems to work. Is there any way you can do >> it without >> tuples? > > Source generators in numpy.distutils are extensions to distutils > and if setuptools assumes std distutils then source generators will > remain a problem for setuptools. However, if you call build_src > then all source generators will be resolved (including 3-tuples in > py_modules list) and the file lists in distribution instance should > not cause any problems for setuptools. > > So, would calling `setup.py build_src bdist_egg` be an acceptable > solution? Fixed in svn. I added a wrapper around the setuptools.command.egg_info.egg_info.run method that runs the build_src command first. -- |>|\/|< /------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |co...@ph... |
|
From: Fernando P. <Fer...@co...> - 2006-01-31 21:24:53
|
O'Keefe, Michael wrote: >> Now, the data-type object itself is the preferred way. I need to figure >> out what to do with these functions now and see if they even have any >> use anymore. > > > Thanks Travis. > > With regard to what to do with the functions, I only ended up trying them > because they were there. From my point of view, I'd love to learn how to > code the "right" way. To that end, any means of informing the user of > "deprecated" functions (or just taking them out) would be fine with me. > However, I realize some may have legacy code and so I would defer to their > opinions. Python has a proper framework for deprecation warnings. I'd say we use that, and Travis can ruthlessly deprecate anything that's just compatibility noise. Perhaps 1.0 can keep old but deprecated things around (numpy will see a LOT of use once 1.0 comes out, far more than the current svn testing crowd). Then, as of 1.1 or 1.2 or whatever, those can be removed. Cheers, f |
|
From: Travis O. <oli...@ie...> - 2006-01-31 21:22:27
|
O'Keefe, Michael wrote: >I was just migrating some working scipy/numeric code I'd been using to the newer numpy (0.9.4), python (2.4.2), and scipy (0.4.4). > >When I ran my unit-tests, one line that gave me problems was: > >import scipy as sp >... >assert( type(deltaTime_sec)==float ) > >This line of code was there to inform me if I was accidentally passing in an array type instead of a scalar. This no longer worked in the new environment. The type of deltaTime_sec came out as float64_arrtype which did not equal type float causing the assertion to trip which I believe to be caused by the following: > > Ah... This is something that needs to be added to the FAQ, because it is common. Basically, you should almost never test for type equality like this since with >Python2.2 the Python float can be inherited from (that's what a float64scalar does --- used to be called float64_arrtype). So, instead you should use assert (isinstance(deltaTime_sec, float)) which would still work with the new float scalar objects. The big advantage of the new scalar types and objects is that there is a 1-1 relationship between the scalar types and the basic array data-types and the new scalars have all the methods and attributes of arrays. So, in fact you could write: assert(deltaTime_sec.size == 1) and this would work whether deltaTime is a scalar or an array with only one element. -Travis |
|
From: O'Keefe, M. <Mic...@nr...> - 2006-01-31 21:06:56
|
> Now, the data-type object itself is the preferred way. I need to = figure=20 > out what to do with these functions now and see if they even have any=20 > use anymore. Thanks Travis.=20 With regard to what to do with the functions, I only ended up trying = them because they were there. From my point of view, I'd love to learn = how to code the "right" way. To that end, any means of informing the = user of "deprecated" functions (or just taking them out) would be fine = with me. However, I realize some may have legacy code and so I would = defer to their opinions. > What use were you making of them? I was just migrating some working scipy/numeric code I'd been using to = the newer numpy (0.9.4), python (2.4.2), and scipy (0.4.4). When I ran my unit-tests, one line that gave me problems was: import scipy as sp ... assert( type(deltaTime_sec)=3D=3Dfloat ) This line of code was there to inform me if I was accidentally passing = in an array type instead of a scalar. This no longer worked in the new = environment. The type of deltaTime_sec came out as float64_arrtype which = did not equal type float causing the assertion to trip which I believe = to be caused by the following: >>> a=3Dsp.array([1.],float) >>> type(a) <type 'numpy.ndarray'> >>> type(a[0]) # somewhere I assign deltaTime_sec =3D someArray[0] <type 'float64_arrtype'> I ended up fixing it with the following code which seems to do the trick = (though I'm always keen to learn better ways of doing things): assert( sp.size(deltaTime_sec)=3D=3D1 ) Thanks! Michael |
|
From: Travis O. <oli...@ie...> - 2006-01-31 20:33:04
|
O'Keefe, Michael wrote: >I was just updating my code to work with python 2.4.2 and numpy 0.9.4 and observed the following behavior with the function isarrtype. Just thought I would report it (see below). > > > Thanks for this report. I've fixed the problem, but you should probably not be using these functions anymore. These were put in place before the data-type objects materialized. In the past, what is now the typeobject of the array scalars was thought to be the basic way to determine the data-type of the array. Now, the data-type object itself is the preferred way. I need to figure out what to do with these functions now and see if they even have any use anymore. What use were you making of them? Best, -Travis |
|
From: Pearu P. <pe...@sc...> - 2006-01-31 20:20:13
|
Hi, numpy.distutils has already support for both g95 and gfortran compilers. Run python setup.py config_fc --help-fcompiler to see a list of supported Fortran compilers. Pearu On Tue, 31 Jan 2006, Bruce Southey wrote: > Hi, > Perhaps it would also make sense to add g95 (http://g95.sourceforge.net/ or > g95.org) which is different than gfortran ( > http://gcc.gnu.org/wiki/TheOtherGCCBasedFortranCompiler). > > Regards > Bruce > > On 1/31/06, Matthew Brett <mat...@gm...> wrote: >> >> Hi, >> >> I have the latest version of Mandrake, which has no g77, only gfortran >> - and needed the following patch to compile (with some added g77, >> gfortran outputs): >> >> Index: numpy/distutils/fcompiler/gnu.py >> =================================================================== >> --- numpy/distutils/fcompiler/gnu.py (revision 2033) >> +++ numpy/distutils/fcompiler/gnu.py (working copy) >> @@ -20,8 +20,13 @@ >> # GNU Fortran (GCC) 3.3.3 (Debian 20040401) >> # GNU Fortran 0.5.25 20010319 (prerelease) >> # Redhat: GNU Fortran (GCC 3.2.2 20030222 (Red Hat Linux >> 3.2.2-5)) 3.2.2 20030222 (Red Hat Linux 3.2.2-5) >> + # Mandrake: GNU Fortran (GCC) 3.3.6 (Mandrakelinux release 3.3.6-2mdk >> ) >> + # >> + # 'gfortran --version' results >> + # Redhat: GNU Fortran 95 (GCC 4.0.2 20051125 (Red Hat 4.0.2-8)) >> + # Mandrake: GNU Fortran 95 (GCC 4.0.1 (4.0.1-5mdk for Mandriva >> Linux release 2006.0)) >> >> - for fc_exe in map(find_executable,['g77','f77']): >> + for fc_exe in map(find_executable,['g77','f77','gfortran']): >> if os.path.isfile(fc_exe): >> break >> executables = { >> @@ -41,7 +46,10 @@ >> if os.name != 'nt' and sys.platform!='cygwin': >> pic_flags = ['-fPIC'] >> >> - g2c = 'g2c' >> + if os.path.basename(fc_exe) == 'gfortran': >> + g2c = 'gfortran' >> + else: >> + g2c = 'g2c' >> >> #def get_linker_so(self): >> # # win32 linking should be handled by standard linker >> >> Can I suggest this a patch to svn numpy? >> >> Thanks, >> >> Matthew >> >> >> > |
|
From: Bruce S. <bso...@gm...> - 2006-01-31 20:04:44
|
Hi, Perhaps it would also make sense to add g95 (http://g95.sourceforge.net/ or g95.org) which is different than gfortran ( http://gcc.gnu.org/wiki/TheOtherGCCBasedFortranCompiler). Regards Bruce On 1/31/06, Matthew Brett <mat...@gm...> wrote: > > Hi, > > I have the latest version of Mandrake, which has no g77, only gfortran > - and needed the following patch to compile (with some added g77, > gfortran outputs): > > Index: numpy/distutils/fcompiler/gnu.py > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- numpy/distutils/fcompiler/gnu.py (revision 2033) > +++ numpy/distutils/fcompiler/gnu.py (working copy) > @@ -20,8 +20,13 @@ > # GNU Fortran (GCC) 3.3.3 (Debian 20040401) > # GNU Fortran 0.5.25 20010319 (prerelease) > # Redhat: GNU Fortran (GCC 3.2.2 20030222 (Red Hat Linux > 3.2.2-5)) 3.2.2 20030222 (Red Hat Linux 3.2.2-5) > + # Mandrake: GNU Fortran (GCC) 3.3.6 (Mandrakelinux release 3.3.6-2md= k > ) > + # > + # 'gfortran --version' results > + # Redhat: GNU Fortran 95 (GCC 4.0.2 20051125 (Red Hat 4.0.2-8)) > + # Mandrake: GNU Fortran 95 (GCC 4.0.1 (4.0.1-5mdk for Mandriva > Linux release 2006.0)) > > - for fc_exe in map(find_executable,['g77','f77']): > + for fc_exe in map(find_executable,['g77','f77','gfortran']): > if os.path.isfile(fc_exe): > break > executables =3D { > @@ -41,7 +46,10 @@ > if os.name !=3D 'nt' and sys.platform!=3D'cygwin': > pic_flags =3D ['-fPIC'] > > - g2c =3D 'g2c' > + if os.path.basename(fc_exe) =3D=3D 'gfortran': > + g2c =3D 'gfortran' > + else: > + g2c =3D 'g2c' > > #def get_linker_so(self): > # # win32 linking should be handled by standard linker > > Can I suggest this a patch to svn numpy? > > Thanks, > > Matthew > > > |
|
From: Travis O. <oli...@ie...> - 2006-01-31 19:35:49
|
Francesc Altet wrote: >Hi, > >I've detected a couple of issues in records.py. For the first one, the >next should fix it: > > Thanks for the patch. Also thank you for catching that we weren't allowing field access on the record objects. This is now fixed (by simply getting rid of the specialized getitem call and leeting the base-class take care of it). -Travis |
|
From: Francesc A. <fa...@ca...> - 2006-01-31 17:16:36
|
Hi,
I've detected a couple of issues in records.py. For the first one, the
next should fix it:
Index: numpy/core/records.py
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=2D-- numpy/core/records.py (revision 2033)
+++ numpy/core/records.py (working copy)
@@ -410,7 +410,8 @@
offset=3Doffset)
elif isinstance(obj, sb.ndarray):
res =3D obj.view(recarray)
=2D if issubclass(res.dtype, nt.void):
+ if issubclass(res.dtype.type, nt.void):
res.dtype =3D sb.dtype((record, res.dtype))
+ return res
else:
raise ValueError("Unknown input type")
Now, another curious thing (sorry, no patch this time):
In [6]: for i in numpy.rec.array([(1,2)], formats=3D'u4,u4'): print i
...:
(1L, 2L)
[No problem with this]
In [7]: for i in numpy.rec.array([(1,2)], formats=3D'u4,u4')[0]: print i
...:
=2D------------------------------------------------------------------------=
=2D-
exceptions.KeyError Traceback (most recent=
=20
call last)
/home/faltet/computacio.nobackup/hdf5-1.7.51/test/<console>
/usr/lib/python2.3/site-packages/numpy/core/records.py in __getitem__(self,=
=20
obj)
126
127 def __getitem__(self, obj):
=2D-> 128 return self.getfield(*(self.dtype.fields[obj][:2]))
129
130 def __setitem__(self, obj, val):
KeyError: 0
I'd expect something like
1L
2L
Cheers,
=2D-=20
>0,0< Francesc Altet =A0 =A0 http://www.carabos.com/
V V C=E1rabos Coop. V. =A0=A0Enjoy Data
"-"
|
|
From: Matthew B. <mat...@gm...> - 2006-01-31 17:00:06
|
Hi,
I have the latest version of Mandrake, which has no g77, only gfortran
- and needed the following patch to compile (with some added g77,
gfortran outputs):
Index: numpy/distutils/fcompiler/gnu.py
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- numpy/distutils/fcompiler/gnu.py (revision 2033)
+++ numpy/distutils/fcompiler/gnu.py (working copy)
@@ -20,8 +20,13 @@
# GNU Fortran (GCC) 3.3.3 (Debian 20040401)
# GNU Fortran 0.5.25 20010319 (prerelease)
# Redhat: GNU Fortran (GCC 3.2.2 20030222 (Red Hat Linux
3.2.2-5)) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
+ # Mandrake: GNU Fortran (GCC) 3.3.6 (Mandrakelinux release 3.3.6-2mdk)
+ #
+ # 'gfortran --version' results
+ # Redhat: GNU Fortran 95 (GCC 4.0.2 20051125 (Red Hat 4.0.2-8))
+ # Mandrake: GNU Fortran 95 (GCC 4.0.1 (4.0.1-5mdk for Mandriva
Linux release 2006.0))
- for fc_exe in map(find_executable,['g77','f77']):
+ for fc_exe in map(find_executable,['g77','f77','gfortran']):
if os.path.isfile(fc_exe):
break
executables =3D {
@@ -41,7 +46,10 @@
if os.name !=3D 'nt' and sys.platform!=3D'cygwin':
pic_flags =3D ['-fPIC']
- g2c =3D 'g2c'
+ if os.path.basename(fc_exe) =3D=3D 'gfortran':
+ g2c =3D 'gfortran'
+ else:
+ g2c =3D 'g2c'
#def get_linker_so(self):
# # win32 linking should be handled by standard linker
Can I suggest this a patch to svn numpy?
Thanks,
Matthew
|
|
From: Travis O. <oli...@ie...> - 2006-01-31 14:55:23
|
Johannes Löhnert wrote: >Hi, > >I just found out that the dot function which multiplies matrices gives >strange results for a 3-dimensional array. Consider the following example: > > You just found two bugs in numpy.dot one of which is also there in Numeric. I just committed a fix to both bugs by using the ever-useful N-d array iterator (it sure makes it easier to write algorithms for strided arrays...). All three of your tests now produce the same answer. Thank you for finding this problem. -Travis |
|
From: Christopher F. <ch...@tr...> - 2006-01-31 14:47:54
|
I have added a OS X 10.4 build of numpy 0.9.4 to the sourceforge site. For (approximately) bi-weekly builds of numpy and scipy for OS X, go to http://trichech.us. Chris -- Christopher J. Fonnesbeck Population Ecologist, Marine Mammal Section Fish & Wildlife Research Institute (FWC) St. Petersburg, FL Adjunct Assistant Professor Warnell School of Forest Resources University of Georgia Athens, GA T: 727.235.5570 E: chris at trichech.us |
|
From: dHering <vel...@gm...> - 2006-01-31 10:55:09
|
On 1/31/06, Francesc Altet <fa...@ca...> wrote:
>
> A Dimarts 31 Gener 2006 10:46, dHering va escriure:
> > Hi all,
> >
> > I need to cast fields of type 'Bool' to type 'Int32'.
> > I'm not sure how to do this.
> >
> > Thank you,
> > Dieter
> >
> >
> > import numarray.records as rec
> >
> > b =3D rec.array([[23, 0],[45, 1]], names=3D' integer,
> boolean',formats=3D'Int32,
> > Bool')
> >
> > print b.field(1).type()
> > # following line is not permissable
> > # b.field(1) =3D b.field(1).astype('Int32')
> > b.field(1)[:] =3D b.field(1).astype('Int32')
> > print b.field(1).type()
>
> You can't do this because this implies a change on the column type
> definition (and also in the type size) of the recarray.
>
> One way that works for me, but that implies a complete data copy, is:
>
> In [15]: c =3D rec.array([b.field(0),b.field(1)], formats=3D'Int32,Int32'=
)
>
> In [16]: c.field(1)
> Out[16]: array([0, 1])
>
> HTH,
>
> --
> >0,0< Francesc Altet http://www.carabos.com/
> V V C=E1rabos Coop. V. Enjoy Data
> "-"
Yes it helps very much Francesc.
Thank you.
Dieter
|
|
From: Gerard V. <ger...@gr...> - 2006-01-31 10:52:50
|
On Tue, 31 Jan 2006 21:32:14 +1100 Lito Kusnadi <lit...@gm...> wrote: > Hi, I'm running RHEL 4.0 2.6.9-5.EL with Python 2.3.4. > I managed to compile NumPy from src.rpm and make an i386 rpm from it. > Version of NumPy is numpy-0.9.4-1. > When I run Python interactive line and try to import NumPy, it aborts and > kicks me to the command prompt. > The following error is generated: > > Python 2.3.4 (#1, Nov 4 2004, 14:06:56) > [GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> from numpy import * > import core -> failed: > /usr/lib/python2.3/site-packages/numpy/core/multiarray.so: undefined symbol: > PyOS_ascii_strtod > import random -> failed: 'module' object has no attribute 'dtype' > import lib -> failed: > /usr/lib/python2.3/site-packages/numpy/core/multiarray.so: undefined symbol: > PyOS_ascii_strtod > Fatal Python error: can't initialize module lapack_lite > Aborted > > Anyone knows what package I am missing? > There is a patch for Python-2.3 (PyOS_ascii_strtod does not exist in Python-2.3): http://sourceforge.net/project/showfiles.php?group_id=1369&package_id=175103 Look for: patch-for-py2.3 Gerard |
|
From: Francesc A. <fa...@ca...> - 2006-01-31 10:45:09
|
A Dimarts 31 Gener 2006 10:46, dHering va escriure:
> Hi all,
>
> I need to cast fields of type 'Bool' to type 'Int32'.
> I'm not sure how to do this.
>
> Thank you,
> Dieter
>
>
> import numarray.records as rec
>
> b =3D rec.array([[23, 0],[45, 1]], names=3D' integer, boolean',formats=3D=
'Int32,
> Bool')
>
> print b.field(1).type()
> # following line is not permissable
> # b.field(1) =3D b.field(1).astype('Int32')
> b.field(1)[:] =3D b.field(1).astype('Int32')
> print b.field(1).type()
You can't do this because this implies a change on the column type
definition (and also in the type size) of the recarray.
One way that works for me, but that implies a complete data copy, is:
In [15]: c =3D rec.array([b.field(0),b.field(1)], formats=3D'Int32,Int32')
In [16]: c.field(1)
Out[16]: array([0, 1])
HTH,
=2D-=20
>0,0< Francesc Altet =A0 =A0 http://www.carabos.com/
V V C=E1rabos Coop. V. =A0=A0Enjoy Data
"-"
|
|
From: Lito K. <lit...@gm...> - 2006-01-31 10:32:17
|
Hi, I'm running RHEL 4.0 2.6.9-5.EL with Python 2.3.4. I managed to compile NumPy from src.rpm and make an i386 rpm from it. Version of NumPy is numpy-0.9.4-1. When I run Python interactive line and try to import NumPy, it aborts and kicks me to the command prompt. The following error is generated: Python 2.3.4 (#1, Nov 4 2004, 14:06:56) [GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from numpy import * import core -> failed: /usr/lib/python2.3/site-packages/numpy/core/multiarray.so: undefined symbol= : PyOS_ascii_strtod import random -> failed: 'module' object has no attribute 'dtype' import lib -> failed: /usr/lib/python2.3/site-packages/numpy/core/multiarray.so: undefined symbol= : PyOS_ascii_strtod Fatal Python error: can't initialize module lapack_lite Aborted Anyone knows what package I am missing? Thanks. |
|
From: dHering <vel...@gm...> - 2006-01-31 09:46:40
|
Hi all,
I need to cast fields of type 'Bool' to type 'Int32'.
I'm not sure how to do this.
Thank you,
Dieter
import numarray.records as rec
b =3D rec.array([[23, 0],[45, 1]], names=3D' integer, boolean',formats=3D'I=
nt32,
Bool')
print b.field(1).type()
# following line is not permissable
# b.field(1) =3D b.field(1).astype('Int32')
b.field(1)[:] =3D b.field(1).astype('Int32')
print b.field(1).type()
##########################
##########################
/usr/bin/python -u
Bool
Bool
|
|
From: Travis O. <oli...@ie...> - 2006-01-31 03:28:51
|
Christopher Barker wrote: > > Which perhaps helps answer Travis' original question. > > Did it make much difference in this case, Travis? Some difference in that case. For 10**6 elements, the relevant loops went from about 34 msec/loop (using the timeit module) to about 31 msec/loop. For a savings of about 3 msec/loop on my AMD platform. -Travis |
|
From: Christopher B. <Chr...@no...> - 2006-01-31 00:47:44
|
Sasha wrote: > I would recommend to take a look at > <http://www.amd.com/us-en/assets/content_type/white_papers_and_tech= _docs/22007.pdf> Nice reference, thanks. From that: """ Copy Frequently Dereferenced Pointer Arguments to Local Variables: Avoid frequently dereferencing pointer arguments inside a function. Since the compiler has no knowledge of whether aliasing exists between the pointers, such dereferencing cannot be optimized away by the compiler. This prevents data from being kept in registers and significantly increases memory traffic. Note that many compilers have an =93assume no aliasing=94 optimization switch. This allows the compiler to assume that two different pointers always have disjoint contents and does not require copying of pointer arguments to local variables. Otherwise, copy the data pointed to by the pointer arguments to local variables at the start of the function and if necessary copy them back at the end of the function. """ Which perhaps helps answer Travis' original question. Did it make much difference in this case, Travis? -Chris --=20 Christopher Barker, Ph.D. Oceanographer =09=09 NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no... |
|
From: Alan G I. <ai...@am...> - 2006-01-30 23:35:25
|
On Mon, 30 Jan 2006, Christopher Barker apparently wrote: > The SciPy community is not a "user" group, it's > a developer group. there are other open source projects > worth of representation, such as the GNU Scientific > Library. It would not hurt to ask for a waiver for open source developers. Whichever way it goes might contain a lot of information. Cheers, Alan |
|
From: Joe H. <jh...@oo...> - 2006-01-30 22:58:09
|
Currently the NMC membership is tiny. Likely the linalg focus is due to the biases of that group. Getting an open-source project involved in something like this isn't so terrible, if the vendors allow it (i.e., if it isn't a sham for one set of vendors to gang up on another, as the Open Software Foundation was about 15 years ago). I notice that Research Systems (IDL) conspicuously isn't on their list (they'd definitely be more array-oriented). Also conspicuous by their absences are prominent groups like NAG and netlib. As for coming up with the fee, I think that it wouldn't be a huge investment for STScI and Enthought to split. If successful, NMC will impact both organizations quite a bit, so it should be worth it to them. Of course, I don't work for either organization so that's easy for me to say. Note that these people expect their members to do a lot of work, so the greater commitment might be time. However, the group is conveniently located in Austin... Alternatively, we could petition for a waiver based on our lack of profit. That's been done successfully in the past, too, for example by the Gutenprint folks (who then proceeded to teach the developers at Lexmark et al. a thing or two about dithering). XFree86.org had to beat on the X Consortium (or whatever they were called then) a bit, but eventually got in. I'm not sure what the deal was with fees for them. --jh-- |
|
From: Sasha <nd...@ma...> - 2006-01-30 22:38:48
|
On 1/30/06, Travis Oliphant <oli...@ee...> wrote: > Are there other ways to > get C-compilers to produce faster code on modern machines? I would recommend to take a look at <http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/22= 007.pdf> if you have not seen it before. Although wtitten by AMD, many recommendations apply to most modern CPUs. I've found Chapter 3 particulary informative. In fact I've changed my coding habits after reading some of their recommendations (for example "Use Array-Style Instead of Pointer-Style Code"). -- sasha |
|
From: Travis O. <oli...@ee...> - 2006-01-30 21:58:29
|
Gerard Vermeulen wrote: >>In current SVN, I think improved on the current state by only calling a >>scalar a signed integer if it is actually negative (previously only it's >>data-type was checked and all Python integers get converted to >>PyArray_LONG data-types which are signed integers). >> >>This fixes the immediate problem, I think. >> >>What are opinions on this scalar-coercion rule? >> >> >> > >Hmm, this is a consequence of your rule: > > > >>>>from numpy import *; core.__version__ >>>> >>>> >'0.9.5.2024' > > >>>>a = arange(3, dtype=uint32) >>>>a-3 >>>> >>>> >array([4294967293, 4294967294, 4294967295], dtype=uint32) > > >>>>a+-3 >>>> >>>> >array([-3, -2, -1], dtype=int64) > > >>>>(a-3) == (a+-3) >>>> >>>> >array([False, False, False], dtype=bool) > >Do you think that the speed-up justifies this? I don't think so. > > > It's still hard to say if it justifies it or not. One way of writing a-3 causes automatic upcasting while the other way doesn't. This might be a good thing, depending on your point of view. I could see people needing both situations. These things are never as clear as we'd like them to be. But, I could also accept a rule that treated *all* integers as the same kind in which case a-3 and a+(-3) would always return the same thing. I'm fine with it either way. So what are other opinions? -Travis |
|
From: Fernando P. <Fer...@co...> - 2006-01-30 21:56:19
|
Travis Oliphant wrote: > Jonathan Taylor wrote: > >>I am wondering what needs to happen before a 1.0 release of both numpy >>and scipy? > > > For a 1.0 release of numpy: Small suggestion: I think this info would make an excellent 'timetable' page on our new wiki. It will give people a sense of where things stand, and what needs done before we go 1.0. I know people can always search the list, but something like this I think deserves more prominent mention. Cheers, f |
|
From: Travis O. <oli...@ie...> - 2006-01-30 21:52:34
|
Jonathan Taylor wrote: > I am wondering what needs to happen before a 1.0 release of both numpy > and scipy? For a 1.0 release of numpy: In terms of features. The only thing I see as necessary is that array scalars have their own math defined so that they don't go through the full ufunc machinery. This is probably about 20-40 hours of work. I would also like to see a numcompat module that allows numarray users to compile their C-extensions with a simple include file change. Also, a convert_numarraycode.py module would be useful for converting Python code. Mostly, though, I would like to see more people using NumPy in different circumstances so that we get the bugs worked out and needed C-API changes before going to 1.0. This is the process that may take several months as I see it. -Travis |
258 messages has been excluded from this view by a project administrator.