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: Travis O. <oli...@ie...> - 2006-01-17 21:48:24
|
Christopher Hanley wrote: > Travis Oliphant wrote: > >> Yes, I think it would be possible. Please keep me informed of other >> possible compatibility improvements. >> >> Does the shape parameter just control the size of the resulting >> array? Is it equivalent to a >> .reshape(newshape) at the end? >> >> -Travis >> > > The shape parameter does control the size of the resulting array (so > you wouldn't need any information from the existing count parameter). > > The resulting array is the equivalent of what you would get if you > were to use the reshape method on the array currently returned by > fromfile. I prefer to us the array.shape = (newshape) since it is an > inplace operation instead of reshape. At least this is what I am > doing in the pyfits port. > What do you think about the sizing paramter of Numarray? Is that important? If so, I would suggest a wrapper function in Python that uses the current fromfile function. We could rename the builtin to _fromfile in that case.. -Travis |
|
From: Travis O. <oli...@ie...> - 2006-01-17 21:48:09
|
Christopher Hanley wrote: > Travis Oliphant wrote: > >> Yes, I think it would be possible. Please keep me informed of other >> possible compatibility improvements. >> >> Does the shape parameter just control the size of the resulting >> array? Is it equivalent to a >> .reshape(newshape) at the end? >> >> -Travis >> > > The shape parameter does control the size of the resulting array (so > you wouldn't need any information from the existing count parameter). > > The resulting array is the equivalent of what you would get if you > were to use the reshape method on the array currently returned by > fromfile. I prefer to us the array.shape = (newshape) since it is an > inplace operation instead of reshape. At least this is what I am > doing in the pyfits port. > What do you think about the sizing paramter of numpy? Is that important? If so, I would suggest a wrapper function in Python that uses the current fromfile function. We could rename the builtin to _fromfile in that case.. -Travis |
|
From: Travis O. <oli...@ie...> - 2006-01-17 21:45:39
|
Sasha wrote: >>>>bool_(0) is bool_(0) >>>> >>>> >False > > >>>>bool(0) is bool(0) >>>> >>>> >True > >Is there any reason not to intern numpy's bool_'s? > > No, it just hasn't been done. It would be a good idea... but require some code in PyArray_Scalar and in the bool_new method.. -Travis |
|
From: Sasha <nd...@ma...> - 2006-01-17 21:33:09
|
I would like to propose to change the default value of the mask array of the ma objects from None to bool_(0). This will allow ma to take advantage of numpy scalars providing array interface. For example a check that now has to be written as "a.mask is not None and a.mask.any()" can become just a.mask.any(). Ma will still use a singleton value for an empty mask so that the code that relies on "a.mask is None" check can be changed to "a.mask is nomask". Any objections? -- sasha PS: Somewhat related: >>> from numpy import * >>> bool_(0) is bool_(0) False >>> bool(0) is bool(0) True Is there any reason not to intern numpy's bool_'s? -- sasha |
|
From: Christopher H. <ch...@st...> - 2006-01-17 21:24:39
|
Hi Travis, Would it be possible to allow numpy's fromfile method to accept a shape parameter? This would make it similar to numarray's fromfile method and be one less thing for people making the switch to worry about. Chris |
|
From: Travis O. <oli...@ie...> - 2006-01-17 21:10:03
|
Paulo J. S. Silva wrote: >Travis, > >It is good that my code was helpful. > >I have just tested your code and it seems to be OK now. I have written a >script to test the dot function. I am sending it attached. Think of the >script as a unit test for dot. (It tests correctness of the computations >and verify the dimensional integrity check). > > Thanks for the tests. I'll make them unit tests and put them in the test suite.. >I am using the svn version of numpy now (revision 1923). I am still >seeing slow matrix times vector multiplications if the matrix is >transposed: > >What is going on? > > Hmm.. I'm not sure. What I expect to get called is the cblas_Xgemv function with Order CblasColMajor if A has been transposed... Perhaps this is a slower operation? -Travis |
|
From: Sasha <nd...@ma...> - 2006-01-17 20:18:59
|
> This is new to me. Sofar I know that numpy has been succesfully built on > various unix systems, on Windows, and on OSX. The end-of-lines of numpy > headers have never caused any breakage afaik and numpy header files do no= t > require pre-compilation. Could you give more specific examples of python > platforms where building numpy extension modules could fail? > No, I cannot and as I've just checked as of python 2.4 distutils do not process headers in any way. In fact install_data and install_headers commands are almost identical (both just copy files) and that's why your code happens to work. I did not say your code does not work on all platforms, I said it is not guaranteed to work. Any change to distutils that makes install_data and install_headers commands differ will break your code. When I first installled numpy (it was still scipy_core back then) my build scripts stopped working once I've changed #includes in my source. I tried to restore the old include location by changing install_headers setting, but that had no effect. Then I've dicovered that numpy does not use install_headers command at all. Surely everything was fixed by adding "include_dirs =3D [numpy.get_numpy_include()]" to my setup scripts, but it took several posts to various forums to discover that option. (I started by filing a bug report on SF.) Given that distutils manual specifically discouraged setting custom include_dirs, many future users of numpy are bound to relive my experience. Also, imagine if more third party packages follow numpy lead --- will I have to append an entry for each package to include_dirs? -- sasha |
|
From: Pearu P. <pe...@ce...> - 2006-01-17 19:09:17
|
On Tue, 17 Jan 2006, Sasha wrote:
> My main concern is not with the non-standard default location, but
> with the way distutils are tricked into placing headers into that
> location. Currently this is done by mislabeling the header files as
> "data files" in setup.py as follows:
>
> config.add_data_files(join('include','numpy','*.h'))
>
> This looks like a hack that just happens to work on platforms where
> headers do not require any special treatement such as end-of-line
> conversion or pre-compilation. This is not guaranteed to work on every
> python platform now and may certainly break in the future.
This is new to me. Sofar I know that numpy has been succesfully built on
various unix systems, on Windows, and on OSX. The end-of-lines of numpy
headers have never caused any breakage afaik and numpy header files do not
require pre-compilation. Could you give more specific examples of python
platforms where building numpy extension modules could fail?
Pearu
|
|
From: Pearu P. <pe...@ce...> - 2006-01-17 19:00:59
|
On Tue, 17 Jan 2006, Alexander Belopolsky wrote: > On 1/17/06, Andrew Straw <str...@as...> wrote: >> ... >> Also, as for as I know, the only packages that install things into >> /usr/include/python2.x/packagename are Numeric and numarray, so I would >> argue it's not "standard", (although it may have lots of history). > > I don't know what would qualify as "standard", but Numeric's header > location is specifically mentioned in the distutils manual: > """ > If you need to include header files from some other Python extension, > you can take advantage of the fact that header files are installed in > a consistent way by the Distutils install_header command. For example, > the Numerical Python header files are installed (on a standard Unix > installation) to /usr/local/include/python1.5/Numerical. (The exact > location will differ according to your platform and Python > installation.) Since the Python include > directory--/usr/local/include/python1.5 in this case--is always > included in the search path when building Python extensions, the best > approach is to write C code like > > #include <Numerical/arrayobject.h> > """ As I read this section, I have two thoughts: (i) it was written in Python 1.5 days when distutils was first introduced, and back then I doubt that anyone thought about emergence of setuptools kind of tools - maybe future distutils will support setuptools better so that we treat header files like above, until then we can use the current working solution; and (ii) it all sounds like a recommendation, not a must-follow-or-something-will-break. Pearu |
|
From: Francesc A. <fa...@ca...> - 2006-01-17 18:49:38
|
A Dimarts 17 Gener 2006 19:23, Szymon Jaroszewicz va escriure: > I'm using multidimensional arrays (numarray currently) for storing > conditional probability distributions in Bayesian networks, in which > case a number of dimensions in the range of 20 or more can happen > easily. Obviously for this reason I think its not a good idea to limit > the dimensionality, especially that its not clear if the gain is worth > it. Also I don't think my application to be particularly unusual, see > for example Python Bayesian Network toolkit > http://elliotpbnt.blogspot.com/ funded by Google summer of code. Provided your example and that the minimum dimension size is 2 (1 does not increase the space requeriments) for such arrays, that a boolean would be saved on each element of the array, and that 2**32 =3D 4 GB (an amount of memory that is getting common in modern machines) I would say that allowing 32 dimensions (at least) would sound reasonable. Cheers, =2D-=20 >0,0< Francesc Altet =A0 =A0 http://www.carabos.com/ V V C=E1rabos Coop. V. =A0=A0Enjoy Data "-" |
|
From: Alexander B. <ale...@gm...> - 2006-01-17 18:26:33
|
On 1/17/06, Andrew Straw <str...@as...> wrote: > ... > Also, as for as I know, the only packages that install things into > /usr/include/python2.x/packagename are Numeric and numarray, so I would > argue it's not "standard", (although it may have lots of history). I don't know what would qualify as "standard", but Numeric's header location is specifically mentioned in the distutils manual: """ If you need to include header files from some other Python extension, you can take advantage of the fact that header files are installed in a consistent way by the Distutils install_header command. For example, the Numerical Python header files are installed (on a standard Unix installation) to /usr/local/include/python1.5/Numerical. (The exact location will differ according to your platform and Python installation.) Since the Python include directory--/usr/local/include/python1.5 in this case--is always included in the search path when building Python extensions, the best approach is to write C code like #include <Numerical/arrayobject.h> """ (see http://docs.python.org/dist/describing-extensions.html#SECTION00232000= 0000000000000) The same section also criticises the idea of specifying include path explicitely: """ If you must put the Numerical include directory right into your header search path, though, you can find that directory using the Distutils distutils.sysconfig module: from distutils.sysconfig import get_python_inc incdir =3D os.path.join(get_python_inc(plat_specific=3D1), 'Numerical') setup(..., Extension(..., include_dirs=3D[incdir]), ) Even though this is quite portable--it will work on any Python installation, regardless of platform--it's probably easier to just write your C code in the sensible way. """ -- sasha |
|
From: Szymon J. <sj...@cs...> - 2006-01-17 18:23:30
|
I'm using multidimensional arrays (numarray currently) for storing conditional probability distributions in Bayesian networks, in which case a number of dimensions in the range of 20 or more can happen easily. Obviously for this reason I think its not a good idea to limit the dimensionality, especially that its not clear if the gain is worth it. Also I don't think my application to be particularly unusual, see for example Python Bayesian Network toolkit http://elliotpbnt.blogspot.com/ funded by Google summer of code. -- Szymon Jaroszewicz <sj...@cs...> |
|
From: Andrew S. <str...@as...> - 2006-01-17 17:29:38
|
The main advantage of the current situation for me is that it's easy to
use with .eggs (for the reasons given). The symlink idea won't break
this, but the "let's make it like it was" solution would break it (which
was why it was changed). Can anyone think of a solution that would
please both the old-way-preferers and the .egg users?
Also, as for as I know, the only packages that install things into
/usr/include/python2.x/packagename are Numeric and numarray, so I would
argue it's not "standard", (although it may have lots of history).
Sasha wrote:
>My main concern is not with the non-standard default location, but
>with the way distutils are tricked into placing headers into that
>location. Currently this is done by mislabeling the header files as
>"data files" in setup.py as follows:
>
> config.add_data_files(join('include','numpy','*.h'))
>
>This looks like a hack that just happens to work on platforms where
>headers do not require any special treatement such as end-of-line
>conversion or pre-compilation. This is not guaranteed to work on every
>python platform now and may certainly break in the future.
>
>-- sasha
>
>On 1/17/06, Robert Hetland <he...@ta...> wrote:
>
>
>>On Jan 17, 2006, at 9:08 AM, kon...@la... wrote:
>>
>>
>>What good is that symlink if no one can rely on its presence?
>>
>>True.
>>
>>I think putting the include files in a non-standard place should be the
>>exception, rather than the rule. The standard install should behave itself,
>>and put things in the right place.
>>
>>-Rob
>>
>>
>>-----
>>Rob Hetland, Assistant Professor
>>Dept of Oceanography, Texas A&M University
>>p: 979-458-0096, f: 979-845-6331
>>e: he...@ta..., w: http://pong.tamu.edu
>>
>>
>>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>for problems? Stop! Download the new AJAX search engine that makes
>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
>http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642
>_______________________________________________
>Numpy-discussion mailing list
>Num...@li...
>https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
>
|
|
From: Sasha <nd...@ma...> - 2006-01-17 17:09:55
|
My main concern is not with the non-standard default location, but
with the way distutils are tricked into placing headers into that
location. Currently this is done by mislabeling the header files as
"data files" in setup.py as follows:
config.add_data_files(join('include','numpy','*.h'))
This looks like a hack that just happens to work on platforms where
headers do not require any special treatement such as end-of-line
conversion or pre-compilation. This is not guaranteed to work on every
python platform now and may certainly break in the future.
-- sasha
On 1/17/06, Robert Hetland <he...@ta...> wrote:
>
>
> On Jan 17, 2006, at 9:08 AM, kon...@la... wrote:
>
>
> What good is that symlink if no one can rely on its presence?
>
> True.
>
> I think putting the include files in a non-standard place should be the
> exception, rather than the rule. The standard install should behave itse=
lf,
> and put things in the right place.
>
> -Rob
>
>
> -----
> Rob Hetland, Assistant Professor
> Dept of Oceanography, Texas A&M University
> p: 979-458-0096, f: 979-845-6331
> e: he...@ta..., w: http://pong.tamu.edu
>
|
|
From: Colin J. W. <cj...@sy...> - 2006-01-17 16:37:07
|
John Byrnes wrote: >On Tue, Jan 17, 2006 at 02:24:33PM +0200, Rudolph van der Merwe wrote: > > >>What is the correct importing order if one wants to use the full >>capabilities of numpy+scipy+matplotlib? >> >> >I believe the correct way to import the packages is to not use > >from blah import * > >but rather to use: >import numpy as np >import scipy as S >import pylab as pl > >This keeps the namespace clean and prevents function collisions. > >HTH, >John > > +1 |
|
From: Joe H. <jh...@oo...> - 2006-01-17 16:25:56
|
For reasons that were laid out when this topic came up a month or so ago (perhaps on another of our infinitude of email lists), I'm opposed to reducing the number of dimensions to even 10. A sizeable chunk of the community does use many dimensions. I routinely use more than 5 dimensions, and I'm pretty good at reducing the number for performance where it's practical. There's an atmospheric sciences tool called vis5d (x,y,z,t,field parameter vector), which shows just how commonly meteorologists use 5 dimensions. I don't think of the atmospheric sciences as being a particularly dimension-heavy group, but you can easily think of adding a few more dimensions that let you choose model runs with varied initial parameters. Try tracking the variables of a complex medical trial in just 5 dimensions. IDL's limit is 7 dimensions, and many don't use it as a result. Having more in our default binary installs is a selling point. This is a pretty limiting change to be suggesting, so if there's a change to be made, it should come only after implementing and benchmarking to see what the actual performance benefits are, and then polling the community. If there is a really big improvement in having 4 or 8 dimensions max, and if "malloc and unlimit everything" isn't fast, then it may be worth supporting low-dim and high-dim versions of the binary installs. But, let's wait until we have more volunteers before doing that. --jh-- |
|
From: Francesc A. <fa...@ca...> - 2006-01-17 16:20:13
|
Hi,
When building recarrays in numpy following the numarray convention:
In [2]: numpy.zeros((3,), dtype=3D'u1')
Out[2]: array([0, 0, 0], dtype=3Duint8)
In [3]: numpy.zeros((3,), dtype=3D'u1,f4')
Out[3]: array([(0, 0.0), (0, 0.0), (0, 0.0)], dtype=3D(void,5))
In [4]: numpy.zeros((3,), dtype=3D'2u1,f4')
Out[4]:
array([(array([0, 0], dtype=3Duint8), 0.0),
(array([0, 0], dtype=3Duint8), 0.0), (array([0, 0], dtype=3Duint8), =
0.0)],=20
dtype=3D(void,6))
In [7]: numpy.zeros((3,), dtype=3D'(2,)u1,f4')
Out[7]:
array([(array([0, 0], dtype=3Duint8), 0.0),
(array([0, 0], dtype=3Duint8), 0.0), (array([0, 0], dtype=3Duint8), =
0.0)],=20
dtype=3D(void,6))
So far so good, but
In [5]: numpy.zeros((3,), dtype=3D'2u1')
=2D------------------------------------------------------------------------=
=2D-
exceptions.TypeError Traceback (most recent=
=20
call last)
/home/faltet/python.nobackup/numpy/<ipython console>
TypeError: data type not understood
Also:
In [6]: numpy.zeros((3,), dtype=3D'(2,)u1')
=2D------------------------------------------------------------------------=
=2D-
exceptions.ValueError Traceback (most recent=
=20
call last)
/home/faltet/python.nobackup/numpy/<ipython console>
/usr/lib/python2.4/site-packages/numpy/core/_internal.py in _commastring(as=
tr)
296 res =3D _split(astr)
297 if (len(res)) =3D=3D 1:
=2D-> 298 raise ValueError, "no commas present"
299 result =3D []
300 for k,item in enumerate(res):
ValueError: no commas present
Perhaps this is the same case as defining tables with just one column?
=2D-=20
>0,0< Francesc Altet =A0 =A0 http://www.carabos.com/
V V C=E1rabos Coop. V. =A0=A0Enjoy Data
"-"
|
|
From: Robert H. <he...@ta...> - 2006-01-17 16:06:53
|
On Jan 17, 2006, at 9:54 AM, John Byrnes wrote: > but rather to use: > import numpy as np > import scipy as S > import pylab as pl This may indeed be better (although I am generally lazy, and just import * them). I would certainly be willing to make the effort not to be lazy if there was a standard convention. Are there standard names for importing these packages? I have seen quite a few different conventions in various peoples code. E..g, why not import scipy as sp (instead of S)? From the Numeric days, people often import NumPy (et al.) as N, matplotlib as mpl, etc. -Rob ----- Rob Hetland, Assistant Professor Dept of Oceanography, Texas A&M University p: 979-458-0096, f: 979-845-6331 e: he...@ta..., w: http://pong.tamu.edu |
|
From: John B. <by...@bu...> - 2006-01-17 15:54:22
|
On Tue, Jan 17, 2006 at 02:24:33PM +0200, Rudolph van der Merwe wrote: > What is the correct importing order if one wants to use the full > capabilities of numpy+scipy+matplotlib? I believe the correct way to import the packages is to not use from blah import * but rather to use: import numpy as np import scipy as S import pylab as pl This keeps the namespace clean and prevents function collisions. HTH, John -- Courage and perseverance have a magical talisman, before which difficulties disappear and obstacles vanish into air. -- John Quincy Adams |
|
From: Robert H. <he...@ta...> - 2006-01-17 15:14:31
|
On Jan 17, 2006, at 9:08 AM, kon...@la... wrote: > What good is that symlink if no one can rely on its presence? True. I think putting the include files in a non-standard place should be the exception, rather than the rule. The standard install should behave itself, and put things in the right place. -Rob ----- Rob Hetland, Assistant Professor Dept of Oceanography, Texas A&M University p: 979-458-0096, f: 979-845-6331 e: he...@ta..., w: http://pong.tamu.edu |
|
From: <kon...@la...> - 2006-01-17 15:07:16
|
On Jan 17, 2006, at 15:55, Robert Hetland wrote: > Why not just have the install script 'try:' to put a symlink in the =20= > standard place. That way, the files will be installed in any case, =20= > but (if successful) they will also be accessible from the standard =20 > places. If the symlinks are not created, a warning could be =20 > issued, but the install would not fail. What good is that symlink if no one can rely on its presence? Konrad. -- --------------------------------------------------------------------- Konrad Hinsen Laboratoire L=E9on Brillouin, CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: kh...@ce... --------------------------------------------------------------------- |
|
From: Robert H. <he...@ta...> - 2006-01-17 14:54:53
|
On Jan 16, 2006, at 5:12 PM, <pe...@ce...> <pe...@ce...> wrote: > Also note that not all potential numpy users are able/willing/.. to > use > --prefix option. Why we should scare them away when we can provide > defaults that work for all situations, though the defaults are not > standard and require some tolerance from developers to follow numpy > docs.. Why not just have the install script 'try:' to put a symlink in the standard place. That way, the files will be installed in any case, but (if successful) they will also be accessible from the standard places. If the symlinks are not created, a warning could be issued, but the install would not fail. I have used this solution -- putting the simlink in by hand -- and it seems to work fine. -Rob ----- Rob Hetland, Assistant Professor Dept of Oceanography, Texas A&M University p: 979-458-0096, f: 979-845-6331 e: he...@ta..., w: http://pong.tamu.edu |
|
From: <kon...@la...> - 2006-01-17 14:44:54
|
On Jan 17, 2006, at 1:18, Sasha wrote: >> Also note that not all potential numpy users are able/willing/.. >> to use >> --prefix option. Why we should scare them away when we can provide >> defaults that work for all situations, though the defaults are not >> standard and require some tolerance from developers to follow >> numpy docs. > > Personally, I can tolerate any location less that 10 levels deep under > install prefix > and current location is only 8 :-). However, if there is a valid > reason to change the location of include files, this functionality > should be implemented as a (possibly default) option to distutils, not > by treating includes as "data_files" rather than "headers". I tend to agree, and I am a bit less tolerant about playing with header file location. The argument "just follow the NumPy docs, it's not difficult" ignores that NumPy, like many other Python library, is a software component that many people install without reading any documentation, just because some other component requires it. If NumPy header files end up in a non-standard place, the authors of all Python packages that depend on NumPy, no matter by how many levels of indirection, have to add obscure code to their installation scrips. If every popular Python library did the same, we'd soon have a big mess. Moreover, it is possible that other libraries implement the same API as NumPy, but use different header conventions (in fact, Numeric and Numarray are candidates). Then every author of a package that indirectly depends on this API must not only add NumPy-specific code to his setup.py, but also check which of the multiple implementations is actually installed. Standard locations, be it for Python code or for header files, have been created to avoid this kind of mess. The standard for Python is defined by distutils, and at the moment it's putting header files into $prefix/include/pythonX.Y. If that turns out to be a bad decision on some platform, then distutils should be modified. If individual packages start trying to outsmart distutils, we lose the advantages of a standard installation system. Konrad. |
|
From: Joachim S. <li...@js...> - 2006-01-17 12:48:05
|
Hello all, I have observed a weird behaviour with 24.2, which actually can break existing code: >>> import Numeric >>> Numeric.__version__ '23.8' >>> x=Numeric.zeros(5) >>> type(x[0]) <type 'int'> >>> x=Numeric.zeros(5,'f') >>> type(x[0]) <type 'float'> >>> This is what I would expect. However, using 24.2: >>> import Numeric >>> Numeric.__version__ '24.2' >>> x=Numeric.zeros(5) >>> type(x[0]) <type 'int'> >>> x=Numeric.zeros(5, 'f') >>> type(x[0]) <type 'array'> >>> print type(1*x[0]) <type 'float'> Strange, isn't it? Is there any rationale behind this inconsistent behaviour or is it just a bug? Cheers, Joachim |
|
From: Rudolph v. d. M. <rud...@gm...> - 2006-01-17 12:24:37
|
What is the correct importing order if one wants to use the full capabilities of numpy+scipy+matplotlib? I have all three packages installed and all of them import correctly. For Python code that makes use of all of these, should the import order be: from numpy import * from scipy import * from pylab import * ? I assume a certain amount of re-importing will occur since both scipy and matplotlib (pylab) uses numpy. How does one ensure that the correct objects don't get overwritten? -- Rudolph van der Merwe |
258 messages has been excluded from this view by a project administrator.