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: dHering <vel...@gm...> - 2005-12-29 00:41:35
|
[Sorry for the mis-post]
Hi Travis,
I really hope that the future brings Scipy and Pytables together.
Thank you very much for your contributions and motivation Travis.
Dieter Hering
On 12/28/05, dHering <vel...@gm...> wrote:
> On 12/26/05, Travis Oliphant <oli...@ie...> wrote:
> >
> >
> > I'd like more people to know about the new power that is in scipy core
> > due to the general data-type descriptors that can now be used to define
> > numeric arrays. Towards that effort here is a simple example (be sure
> > to use latest SVN -- there were a coupld of minor changes that improve
> > usability made recently). Notice this example does not use a special
> > "record" array subclass. This is just a regular array. I'm kind of
> > intrigued (though not motivated to pursue) the possibility of accessing
> > (or defining) databases directly into scipy_core arrays using the recor=
d
> > functionality.
> >
> > # Define a new data-type descriptor
> > >>> import scipy
> >
> > >>> dtype =3D scipy.dtypedescr({'names': ['name', 'age', 'weight'],
> > 'formats': ['S30', 'i2', 'f4']})
> > >>> a =3D scipy.array([('Bill',31,260),('Fred',15,135)], dtype=3Ddtype=
)
> > # the argument to dtypedescr could have also been placed here as the
> > argument to dtype
> >
> > >>> print a['name']
> > [Bill Fred]
> >
> > >>> print a['age']
> > [31 15]
> >
> > >>> print a['weight']
> > [ 260. 135.]
> >
> > >>> print a[0]
> > ('Bill', 31, 260.0)
> >
> > >>> print a[1]
> > ('Fred', 15, 135.0)
> >
> > It seems to me there are some very interesting possibilities with this
> > new ability. The record array subclass adds an improved scalar type
> > (the record) and attribute access to get at the fields: (e.g. a.name,
> > a.age, and a.weight). But, if you don't need attribute access you ca=
n
> > use regular arrays to do a lot of what you might need a record array to
> > accomplish for you. I'd love to see what people come up with using thi=
s
> > new facility.
> >
> > The new array PEP for Python basically proposes adding a very simple
> > array object (just the basic PyArrayObject * of Numeric with a
> > bare-bones type-object table) plus this new data-type descriptor object
> > to Python and a very few builtin data-type descriptors (perhaps just
> > object initially). This would basically add the array interface to
> > Python directly and allow people to start using it generally. The PEP
> > is slow going because it is not on my priority list right now because i=
t
> > is not essential to making scipy_core work well. But, I would love to
> > have more people ruminating on the basic ideas which I think are
> > crystallizing.
> >
> > Best wishes for a new year,
> >
> > -Travis Oliphant
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> > _______________________________________________
> > Numpy-discussion mailing list
> > Num...@li...
> > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> >
>
|
|
From: dHering <vel...@gm...> - 2005-12-29 00:38:58
|
On 12/26/05, Travis Oliphant <oli...@ie...> wrote:
>
>
> I'd like more people to know about the new power that is in scipy core
> due to the general data-type descriptors that can now be used to define
> numeric arrays. Towards that effort here is a simple example (be sure
> to use latest SVN -- there were a coupld of minor changes that improve
> usability made recently). Notice this example does not use a special
> "record" array subclass. This is just a regular array. I'm kind of
> intrigued (though not motivated to pursue) the possibility of accessing
> (or defining) databases directly into scipy_core arrays using the record
> functionality.
>
> # Define a new data-type descriptor
> >>> import scipy
>
> >>> dtype =3D scipy.dtypedescr({'names': ['name', 'age', 'weight'],
> 'formats': ['S30', 'i2', 'f4']})
> >>> a =3D scipy.array([('Bill',31,260),('Fred',15,135)], dtype=3Ddtype)
> # the argument to dtypedescr could have also been placed here as the
> argument to dtype
>
> >>> print a['name']
> [Bill Fred]
>
> >>> print a['age']
> [31 15]
>
> >>> print a['weight']
> [ 260. 135.]
>
> >>> print a[0]
> ('Bill', 31, 260.0)
>
> >>> print a[1]
> ('Fred', 15, 135.0)
>
> It seems to me there are some very interesting possibilities with this
> new ability. The record array subclass adds an improved scalar type
> (the record) and attribute access to get at the fields: (e.g. a.name,
> a.age, and a.weight). But, if you don't need attribute access you can
> use regular arrays to do a lot of what you might need a record array to
> accomplish for you. I'd love to see what people come up with using this
> new facility.
>
> The new array PEP for Python basically proposes adding a very simple
> array object (just the basic PyArrayObject * of Numeric with a
> bare-bones type-object table) plus this new data-type descriptor object
> to Python and a very few builtin data-type descriptors (perhaps just
> object initially). This would basically add the array interface to
> Python directly and allow people to start using it generally. The PEP
> is slow going because it is not on my priority list right now because it
> is not essential to making scipy_core work well. But, I would love to
> have more people ruminating on the basic ideas which I think are
> crystallizing.
>
> Best wishes for a new year,
>
> -Travis Oliphant
>
>
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
|
|
From: Christopher B. <Chr...@no...> - 2005-12-28 02:01:42
|
Hi all,
I just built numarray with atlas on Fedora core 4 Linux. I used the copy
of atlas in extras (yum install atlas-sse2). To get it to build, I
edited cfg_packages.py this way:
elif os.path.exists('/usr/local/lib/atlas'):
# uses atlas, installed in /usr/local/lib
lapack_dirs = ['/usr/local/lib/atlas']
lapack_include_dirs += ["/usr/local/include/atlas"]
lapack_libs = ['lapack', 'cblas', 'f77blas', 'atlas', 'g2c', 'm']
elif os.path.exists('/usr/lib/sse2/'):
# uses atlas, installed in /usr/lib/sse2 ( Fedora Core4
extras )
lapack_dirs = ['/usr/lib/sse2']
lapack_include_dirs += ["/usr/include/atlas"]
lapack_libs = ['lapack_atlas','lapack', 'blas']
Did I do that right? would you like to add that stanza to the distribution?
I do think it's a good idea to check for the existence of the atlas dir
before assuming that it's there.
Maybe an exception could be raised if nothing is found?
I did find it odd that I couldn't find instructions for how to do this.
did I miss something?
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
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: Travis O. <oli...@ie...> - 2005-12-26 09:00:26
|
I'd like more people to know about the new power that is in scipy core
due to the general data-type descriptors that can now be used to define
numeric arrays. Towards that effort here is a simple example (be sure
to use latest SVN -- there were a coupld of minor changes that improve
usability made recently). Notice this example does not use a special
"record" array subclass. This is just a regular array. I'm kind of
intrigued (though not motivated to pursue) the possibility of accessing
(or defining) databases directly into scipy_core arrays using the record
functionality.
# Define a new data-type descriptor
>>> import scipy
>>> dtype = scipy.dtypedescr({'names': ['name', 'age', 'weight'],
'formats': ['S30', 'i2', 'f4']})
>>> a = scipy.array([('Bill',31,260),('Fred',15,135)], dtype=dtype)
# the argument to dtypedescr could have also been placed here as the
argument to dtype
>>> print a['name']
[Bill Fred]
>>> print a['age']
[31 15]
>>> print a['weight']
[ 260. 135.]
>>> print a[0]
('Bill', 31, 260.0)
>>> print a[1]
('Fred', 15, 135.0)
It seems to me there are some very interesting possibilities with this
new ability. The record array subclass adds an improved scalar type
(the record) and attribute access to get at the fields: (e.g. a.name,
a.age, and a.weight). But, if you don't need attribute access you can
use regular arrays to do a lot of what you might need a record array to
accomplish for you. I'd love to see what people come up with using this
new facility.
The new array PEP for Python basically proposes adding a very simple
array object (just the basic PyArrayObject * of Numeric with a
bare-bones type-object table) plus this new data-type descriptor object
to Python and a very few builtin data-type descriptors (perhaps just
object initially). This would basically add the array interface to
Python directly and allow people to start using it generally. The PEP
is slow going because it is not on my priority list right now because it
is not essential to making scipy_core work well. But, I would love to
have more people ruminating on the basic ideas which I think are
crystallizing.
Best wishes for a new year,
-Travis Oliphant
|
|
From: Todd M. <jm...@st...> - 2005-12-22 16:29:39
|
Dr. Hans Georg Krauthaeuser wrote: > Tim Churches schrieb: > >> Hans Georg Krauthaeuser wrote: >> >>> Hans Georg Krauthaeuser schrieb: >>> >>> >>>> Hi All, >>>> >>>> I was playing with scipy.stats.itemfreq when I observed the >>>> following overflow: >>>> >>>> In [119]:for i in [254,255,256,257,258]: >>>> .....: l=[0]*i >>>> .....: print i, stats.itemfreq(l), l.count(0) >>>> .....: >>>> 254 [ [ 0 254]] 254 >>>> 255 [ [ 0 255]] 255 >>>> 256 [ [0 0]] 256 >>>> 257 [ [0 1]] 257 >>>> 258 [ [0 2]] 258 >>>> >>>> itemfreq is pretty small (in stats.py): >>>> >>>> ---------------------------------------------------------------------- >>>> def itemfreq(a): >>>> """ >>>> Returns a 2D array of item frequencies. Column 1 contains item >>>> values, >>>> column 2 contains their respective counts. Assumes a 1D array is >>>> passed. >>>> >>>> Returns: a 2D frequency table (col [0:n-1]=scores, col n=frequencies) >>>> """ >>>> scores = _support.unique(a) >>>> scores = sort(scores) >>>> freq = zeros(len(scores)) >>>> for i in range(len(scores)): >>>> freq[i] = add.reduce(equal(a,scores[i])) >>>> return array(_support.abut(scores, freq)) >>>> ---------------------------------------------------------------------- >>>> >>>> It seems that add.reduce is the source for the overflow: >>>> >>>> In [116]:from scipy import * >>>> >>>> In [117]:for i in [254,255,256,257,258]: >>>> .....: l=[0]*i >>>> .....: print i, add.reduce(equal(l,0)) >>>> .....: >>>> 254 254 >>>> 255 255 >>>> 256 0 >>>> 257 1 >>>> 258 2 >>>> >>>> Is there any possibility to avoid the overflow? >>> >> >> >> Apropos the preceding, herewith a thread on the Numpy list from a more >> than a few months ago. The take-home message is that for integer arrays, >> add.reduce is very fast at producing results which fall into two >> categories: a) correct or b) incorrect due to overflow. Unfortunately >> there is no equally quick method of determining into which of these two >> categories any specific result returned by add.reduce falls. >> >> Tim C > Hi Tim, There are already tools in place which let you accomplish what you want, they're just not the default. I have a few suggestions: 1. Ask scipy newcore (Travis) for long term changes like the default behavior of add.reduce. 2. Look at numarray's sum() method for better overflow behavior and reduction on all axes. >>> import numarray as na >>> a = na.arange(100, type='Int8') >>> na.add.reduce(a) # yeah, it overflows... 86 >>> a.sum() # but this doesn't (well, not if Int64 is enough) and always reduces on all axes at once... 4950L 3. Mimic the sum() method and specifiy the type of your output array in add.reduce. >>> na.add.reduce(a, type=na.MaximumType(a.type())) 4950L 4. Or, just explicitly specify the type of your reduction with something you're happy with: >>> na.add.reduce(a, type='Int16') 4950 Hopefully one of these solutions will work for you. Regards, Todd >> >> From: Tim Churches <tc...@op...> >> To: Todd Miller <jm...@st...> >> Date: Apr 12 2005 - 7:51am >> >> Todd Miller wrote: >> >>> On Sun, 2005-04-10 at 10:23 +1000, Tim Churches wrote: >>> >>> >>>> I just got caught by code equivalent to this (with NumPy 23.8 on 32 >>>> bit >>>> Linux): >>>> >>>> >>>>>>> import Numeric as N >>>>>>> a = N.array((2000000000,1000000000),typecode=N.Int32) >>>>>>> N.add.reduce(a) >>>>>> >>>> >>>> -1294967296 >>>> >>>> OK, it is an elementary mistake, but the silent overflow caught me >>>> unawares. casting the array to Float64 before summing it avoids the >>>> error, but in my instance the actual data is a rank-1 array of 21 >>>> million integers with a mean value of about 140 (which adds up more >>>> than >>>> sys.maxint), and casting to Float64 will use quite a lot of memory (as >>>> well as taking some time). >>>> >>>> Any advice for catching or avoiding such overflow without always >>>> incurring a performance and memory hit by always casting to Float64? >>> >>> >>> >>> Here's what numarray does: >>> >>> >>> >>>>>> import numarray as N >>>>>> a = N.array((2000000000,1000000000),typecode=N.Int32) >>>>>> N.add.reduce(a) >>>>> >>> >>> -1294967296 >>> >>> So basic reductions in numarray have the same "careful while you're >>> shaving" behavior as Numeric; it's fast but easy to screw up. >> >> >> >> Sure, but how does one be careful? It seems that for any array of two >> integers or more which could sum to more than sys.maxint or less than >> -sys.maxint, add.reduce() in both NumPy and Numeric will give either a) >> the correct answer or b) the incorrect answer, and short of adding up >> the array using a safer but much slower method, there is no way of >> determining if the answer provided (quickly) by add.reduce is right or >> wrong? Which seems to make it fast but useless (for integer arrays, at >> least? Is that an unfair summary? Can anyone point me towards a method >> for using add.reduce() on small arrays of large integers with values in >> the billions, or on large arrays of fairly small integer values, which >> will not suddenly and without warning give the wrong answer? >> >> >>> But: >>> >>> >>> >>>>>> a.sum() >>>>> >>> >>> 3000000000L >>> >>> >>>>>> a.sum(type='d') >>>>> >>> >>> 3000000000.0 >>> >>> a.sum() blockwise upcasts to the largest type of kind on the fly, in >>> this case, Int64. This avoids the storage overhead of typecasting the >>> entire array. >> >> >> >> That's on a 64-bit platform, right? The same method could be used to >> cast the accumulator to a Float64 on a 32-bit platform to avoid casting >> the entire array? >> >> >>> A better name for the method would have been sumall() since it sums all >>> elements of a multi-dimensional array. The flattening process reduces >>> on one dimension before flattening preventing a full copy of a >>> discontiguous array. It could be smarter about choosing the dimension >>> of the initial reduction. >> >> >> >> OK, thanks. Unfortunately it is not possible for us to port our >> application to numarray at the moment. But the insight is most helpful. >> >> Tim C > > Tim, > > Thank you very much for your answer. I posted two follow-ups to my own > post on c.l.p > (http://groups.google.de/group/comp.lang.python/browse_thread/thread/a96c404d73d71259/7769fca1fa562718?hl=de#7769fca1fa562718) > > > A least for scipy version '0.3.2' the problem comes directly from the > ufunc 'add' for bool arrays: > > In [178]:array(array([1],'b')*2) > Out[178]:array([2],'i') > > In [179]:array(array([1],'b')+array([1],'b')) > Out[179]:array([2],'b') > > 'multiply' changes the typecode. > > So, in this case > > a+a != a*2 if a is an array with bytecode 'b'. > > Regards > Hans Georg Krauthäuser |
|
From: Francesc A. <fa...@ca...> - 2005-12-22 09:10:19
|
=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 Announcing PyTables 1.2.1 =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 I'm happy to announce a new version of PyTables. This is a maintenance version and only bugs has been fixed in it. In particular, the documentation has not change at all, so it is not necessary that you look at it for changes. Go to the PyTables web site for downloading the beast: http://pytables.sourceforge.net/ or keep reading for more info about the bugs fixed in this version. I take the opportunity to announce as well that PyTables is adopting the bazaar-ng (http://www.bazaar-ng.org/) distributed version control, in order to easy the contributions from developers throughout the world. See more info about this new facility (currently in beta) in: http://sourceforge.net/mailarchive/forum.php?thread_id=3D9253854&forum_id= =3D13760 Changes more in depth =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Bug fixes: =2D Table.flush() is called automatically before disposing a table object from the user space. This avoids a problem that appears when the user does not explicitely do the flush and the table is unbounded and rebounded after on (using h5file.getNode() for example). =2D A small typo has been fixed in the ptrepack utility. This prevented ptrepack from working correctly when asking for statistics on operations done (-v flag). Known issues: =2D Time datatypes are non-portable between big-endian and little-endian architectures. This is ultimately a consequence of an HDF5 limitation. See SF bug #1234709 for more info. Backward-incompatible changes: =2D None. Important note for MacOSX users =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 =46rom PyTables 1.2 on, the UCL compressor seems to work well again on MacOSX platforms. We don't know exactly why, but the fact is that all the test suite passes (using UCL) executes flawlessly. So, from now on, support for UCL in MacOSX is enabled again by default (i.e. you don't need to use the flag ``--force-ucl``, which has disappeared). Important note for Python 2.4 and Windows users =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 If you are willing to use PyTables with Python 2.4 in Windows platforms, you will need to get the HDF5 library compiled for MSVC 7.1, aka .NET 2003. It can be found at: ftp://ftp.ncsa.uiuc.edu/HDF/HDF5/current/bin/windows/5-165-win-net.ZIP Users of Python 2.3 on Windows will have to download the version of HDF5 compiled with MSVC 6.0 available in: ftp://ftp.ncsa.uiuc.edu/HDF/HDF5/current/bin/windows/5-165-win.ZIP What it is =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D **PyTables** is a package for managing hierarchical datasets and designed to efficiently cope with extremely large amounts of data (with support for full 64-bit file addressing). It features an object-oriented interface that, combined with C extensions for the performance-critical parts of the code, makes it a very easy-to-use tool for high performance data storage and retrieval. PyTables runs on top of the HDF5 library and numarray (Numeric is also supported) package for achieving maximum throughput and convenient use. Besides, PyTables I/O for table objects is buffered, implemented in C and carefully tuned so that you can reach much better performance with PyTables than with your own home-grown wrappings to the HDF5 library. PyTables sports indexing capabilities as well, allowing doing selections in tables exceeding one billion of rows in just seconds. Platforms =3D=3D=3D=3D=3D=3D=3D=3D=3D This version has been extensively checked on quite a few platforms, like Linux on Intel32 (Pentium), Win on Intel32 (Pentium), Linux on Intel64 (Itanium2), FreeBSD on AMD64 (Opteron), Linux on PowerPC and MacOSX on PowerPC. For other platforms, chances are that the code can be easily compiled and run without further issues. Please, contact us in case you are experiencing problems. Resources =3D=3D=3D=3D=3D=3D=3D=3D=3D Go to the PyTables web site for more details: http://pytables.sourceforge.net/ About the HDF5 library: http://hdf.ncsa.uiuc.edu/HDF5/ About numarray: http://www.stsci.edu/resources/software_hardware/numarray To know more about the company behind the PyTables development, see: http://www.carabos.com/ Acknowledgments =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thanks to various the users who provided feature improvements, patches, bug reports, support and suggestions. See THANKS file in distribution package for a (necessarily incomplete) list of contributors. Many thanks also to SourceForge who have helped to make and distribute this package! And last but not least, a big thank you to THG (http://www.hdfgroup.org/) for sponsoring many of the new features recently introduced in PyTables. Share your experience =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Let us know of any bugs, suggestions, gripes, kudos, etc. you may have. =2D--- **Enjoy data!** -- The PyTables Team |
|
From: Dr. H. G. K. <Han...@E-...> - 2005-12-22 07:53:44
|
Tim Churches schrieb: > Hans Georg Krauthaeuser wrote: > >>Hans Georg Krauthaeuser schrieb: >> >> >>>Hi All, >>> >>>I was playing with scipy.stats.itemfreq when I observed the following >>>overflow: >>> >>>In [119]:for i in [254,255,256,257,258]: >>> .....: l=[0]*i >>> .....: print i, stats.itemfreq(l), l.count(0) >>> .....: >>>254 [ [ 0 254]] 254 >>>255 [ [ 0 255]] 255 >>>256 [ [0 0]] 256 >>>257 [ [0 1]] 257 >>>258 [ [0 2]] 258 >>> >>>itemfreq is pretty small (in stats.py): >>> >>>---------------------------------------------------------------------- >>>def itemfreq(a): >>> """ >>>Returns a 2D array of item frequencies. Column 1 contains item values, >>>column 2 contains their respective counts. Assumes a 1D array is passed. >>> >>>Returns: a 2D frequency table (col [0:n-1]=scores, col n=frequencies) >>>""" >>> scores = _support.unique(a) >>> scores = sort(scores) >>> freq = zeros(len(scores)) >>> for i in range(len(scores)): >>> freq[i] = add.reduce(equal(a,scores[i])) >>> return array(_support.abut(scores, freq)) >>>---------------------------------------------------------------------- >>> >>>It seems that add.reduce is the source for the overflow: >>> >>>In [116]:from scipy import * >>> >>>In [117]:for i in [254,255,256,257,258]: >>> .....: l=[0]*i >>> .....: print i, add.reduce(equal(l,0)) >>> .....: >>>254 254 >>>255 255 >>>256 0 >>>257 1 >>>258 2 >>> >>>Is there any possibility to avoid the overflow? > > > Apropos the preceding, herewith a thread on the Numpy list from a more > than a few months ago. The take-home message is that for integer arrays, > add.reduce is very fast at producing results which fall into two > categories: a) correct or b) incorrect due to overflow. Unfortunately > there is no equally quick method of determining into which of these two > categories any specific result returned by add.reduce falls. > > Tim C > > From: Tim Churches <tc...@op...> > To: Todd Miller <jm...@st...> > Date: Apr 12 2005 - 7:51am > > Todd Miller wrote: > >>On Sun, 2005-04-10 at 10:23 +1000, Tim Churches wrote: >> >> >>>I just got caught by code equivalent to this (with NumPy 23.8 on 32 bit >>>Linux): >>> >>> >>>>>>import Numeric as N >>>>>>a = N.array((2000000000,1000000000),typecode=N.Int32) >>>>>>N.add.reduce(a) >>> >>>-1294967296 >>> >>>OK, it is an elementary mistake, but the silent overflow caught me >>>unawares. casting the array to Float64 before summing it avoids the >>>error, but in my instance the actual data is a rank-1 array of 21 >>>million integers with a mean value of about 140 (which adds up more than >>>sys.maxint), and casting to Float64 will use quite a lot of memory (as >>>well as taking some time). >>> >>>Any advice for catching or avoiding such overflow without always >>>incurring a performance and memory hit by always casting to Float64? >> >> >>Here's what numarray does: >> >> >> >>>>>import numarray as N >>>>>a = N.array((2000000000,1000000000),typecode=N.Int32) >>>>>N.add.reduce(a) >> >>-1294967296 >> >>So basic reductions in numarray have the same "careful while you're >>shaving" behavior as Numeric; it's fast but easy to screw up. > > > Sure, but how does one be careful? It seems that for any array of two > integers or more which could sum to more than sys.maxint or less than > -sys.maxint, add.reduce() in both NumPy and Numeric will give either a) > the correct answer or b) the incorrect answer, and short of adding up > the array using a safer but much slower method, there is no way of > determining if the answer provided (quickly) by add.reduce is right or > wrong? Which seems to make it fast but useless (for integer arrays, at > least? Is that an unfair summary? Can anyone point me towards a method > for using add.reduce() on small arrays of large integers with values in > the billions, or on large arrays of fairly small integer values, which > will not suddenly and without warning give the wrong answer? > > >>But: >> >> >> >>>>>a.sum() >> >>3000000000L >> >> >>>>>a.sum(type='d') >> >>3000000000.0 >> >>a.sum() blockwise upcasts to the largest type of kind on the fly, in >>this case, Int64. This avoids the storage overhead of typecasting the >>entire array. > > > That's on a 64-bit platform, right? The same method could be used to > cast the accumulator to a Float64 on a 32-bit platform to avoid casting > the entire array? > > >>A better name for the method would have been sumall() since it sums all >>elements of a multi-dimensional array. The flattening process reduces >>on one dimension before flattening preventing a full copy of a >>discontiguous array. It could be smarter about choosing the dimension >>of the initial reduction. > > > OK, thanks. Unfortunately it is not possible for us to port our > application to numarray at the moment. But the insight is most helpful. > > Tim C Tim, Thank you very much for your answer. I posted two follow-ups to my own post on c.l.p (http://groups.google.de/group/comp.lang.python/browse_thread/thread/a96c404d73d71259/7769fca1fa562718?hl=de#7769fca1fa562718) A least for scipy version '0.3.2' the problem comes directly from the ufunc 'add' for bool arrays: In [178]:array(array([1],'b')*2) Out[178]:array([2],'i') In [179]:array(array([1],'b')+array([1],'b')) Out[179]:array([2],'b') 'multiply' changes the typecode. So, in this case a+a != a*2 if a is an array with bytecode 'b'. Regards Hans Georg Krauthäuser -- Otto-von-Guericke-Universitaet Magdeburg IGET | fon: +49 391 67 12195 Postfach 4120 | fax: +49 391 67 11236 39016 Magdeburg | email: hg...@et... Germany | www: www.uni-magdeburg.de/krauthae |
|
From: Tim C. <tc...@op...> - 2005-12-21 20:38:21
|
Hans Georg Krauthaeuser wrote: > Hans Georg Krauthaeuser schrieb: > >>Hi All, >> >>I was playing with scipy.stats.itemfreq when I observed the following >>overflow: >> >>In [119]:for i in [254,255,256,257,258]: >> .....: l=[0]*i >> .....: print i, stats.itemfreq(l), l.count(0) >> .....: >>254 [ [ 0 254]] 254 >>255 [ [ 0 255]] 255 >>256 [ [0 0]] 256 >>257 [ [0 1]] 257 >>258 [ [0 2]] 258 >> >>itemfreq is pretty small (in stats.py): >> >>---------------------------------------------------------------------- >>def itemfreq(a): >> """ >>Returns a 2D array of item frequencies. Column 1 contains item values, >>column 2 contains their respective counts. Assumes a 1D array is passed. >> >>Returns: a 2D frequency table (col [0:n-1]=scores, col n=frequencies) >>""" >> scores = _support.unique(a) >> scores = sort(scores) >> freq = zeros(len(scores)) >> for i in range(len(scores)): >> freq[i] = add.reduce(equal(a,scores[i])) >> return array(_support.abut(scores, freq)) >>---------------------------------------------------------------------- >> >>It seems that add.reduce is the source for the overflow: >> >>In [116]:from scipy import * >> >>In [117]:for i in [254,255,256,257,258]: >> .....: l=[0]*i >> .....: print i, add.reduce(equal(l,0)) >> .....: >>254 254 >>255 255 >>256 0 >>257 1 >>258 2 >> >>Is there any possibility to avoid the overflow? Apropos the preceding, herewith a thread on the Numpy list from a more than a few months ago. The take-home message is that for integer arrays, add.reduce is very fast at producing results which fall into two categories: a) correct or b) incorrect due to overflow. Unfortunately there is no equally quick method of determining into which of these two categories any specific result returned by add.reduce falls. Tim C From: Tim Churches <tc...@op...> To: Todd Miller <jm...@st...> Date: Apr 12 2005 - 7:51am Todd Miller wrote: > On Sun, 2005-04-10 at 10:23 +1000, Tim Churches wrote: > >>I just got caught by code equivalent to this (with NumPy 23.8 on 32 bit >>Linux): >> >> >>> import Numeric as N >> >>> a = N.array((2000000000,1000000000),typecode=N.Int32) >> >>> N.add.reduce(a) >>-1294967296 >> >>OK, it is an elementary mistake, but the silent overflow caught me >>unawares. casting the array to Float64 before summing it avoids the >>error, but in my instance the actual data is a rank-1 array of 21 >>million integers with a mean value of about 140 (which adds up more than >>sys.maxint), and casting to Float64 will use quite a lot of memory (as >>well as taking some time). >> >>Any advice for catching or avoiding such overflow without always >>incurring a performance and memory hit by always casting to Float64? > > > Here's what numarray does: > > >>>>import numarray as N >>>>a = N.array((2000000000,1000000000),typecode=N.Int32) >>>>N.add.reduce(a) > > -1294967296 > > So basic reductions in numarray have the same "careful while you're > shaving" behavior as Numeric; it's fast but easy to screw up. Sure, but how does one be careful? It seems that for any array of two integers or more which could sum to more than sys.maxint or less than -sys.maxint, add.reduce() in both NumPy and Numeric will give either a) the correct answer or b) the incorrect answer, and short of adding up the array using a safer but much slower method, there is no way of determining if the answer provided (quickly) by add.reduce is right or wrong? Which seems to make it fast but useless (for integer arrays, at least? Is that an unfair summary? Can anyone point me towards a method for using add.reduce() on small arrays of large integers with values in the billions, or on large arrays of fairly small integer values, which will not suddenly and without warning give the wrong answer? > > But: > > >>>>a.sum() > > 3000000000L > >>>>a.sum(type='d') > > 3000000000.0 > > a.sum() blockwise upcasts to the largest type of kind on the fly, in > this case, Int64. This avoids the storage overhead of typecasting the > entire array. That's on a 64-bit platform, right? The same method could be used to cast the accumulator to a Float64 on a 32-bit platform to avoid casting the entire array? > A better name for the method would have been sumall() since it sums all > elements of a multi-dimensional array. The flattening process reduces > on one dimension before flattening preventing a full copy of a > discontiguous array. It could be smarter about choosing the dimension > of the initial reduction. OK, thanks. Unfortunately it is not possible for us to port our application to numarray at the moment. But the insight is most helpful. Tim C |
|
From: <kh...@ce...> - 2005-12-15 12:40:57
|
On Dec 15, 2005, at 13:20, Janne Sinkkonen wrote: > With Numeric 24.2 one gets the following error: > >>>> innerproduct(ones((10,3),Float), ones((10,3),Float)) > ldc must be >=3D MAX(N,1): ldc=3D3 N=3D10Parameter 14 to routine = cblas_dgemm > was incorrect I have submitted a patch for this in the bug tracker on SourceForge a =20= few weeks ago. 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: Janne S. <jan...@gm...> - 2005-12-15 12:20:29
|
With Numeric 24.2 one gets the following error:
>>> innerproduct(ones((10,3),Float), ones((10,3),Float))
ldc must be >=3D MAX(N,1): ldc=3D3 N=3D10Parameter 14 to routine cblas_dgem=
m
was incorrect
It seems to be fixed by the following patch to
Packages/dotblas/dotblas/_dotblas.c :
--- _dotblas.c~ 2005-04-07 08:15:47.000000000 +0300
+++ _dotblas.c 2005-12-15 11:31:46.148482242 +0200
@@ -530,28 +530,28 @@
ap1->dimensions[0], ap2->dimensions[0], ap1->dimensions[1=
],
1.0, (double *)ap1->data, lda,
(double *)ap2->data, ldb,
- 0.0, (double *)ret->data, ldb);
+ 0.0, (double *)ret->data, ap1->dimensions[0]);
}
else if (typenum =3D=3D PyArray_FLOAT) {
cblas_sgemm(CblasRowMajor, CblasNoTrans, CblasTrans,
ap1->dimensions[0], ap2->dimensions[0], ap1->dimensions[1=
],
1.0, (float *)ap1->data, lda,
(float *)ap2->data, ldb,
- 0.0, (float *)ret->data, ldb);
+ 0.0, (float *)ret->data, ap1->dimensions[0]);
}
else if (typenum =3D=3D PyArray_CDOUBLE) {
cblas_zgemm(CblasRowMajor, CblasNoTrans, CblasTrans,
ap1->dimensions[0], ap2->dimensions[0], ap1->dimensions[1=
],
oneD, (double *)ap1->data, lda,
(double *)ap2->data, ldb,
- zeroD, (double *)ret->data, ldb);
+ zeroD, (double *)ret->data, ap1->dimensions[0]);
}
else if (typenum =3D=3D PyArray_CFLOAT) {
cblas_cgemm(CblasRowMajor, CblasNoTrans, CblasTrans,
ap1->dimensions[0], ap2->dimensions[0], ap1->dimensions[1=
],
oneF, (float *)ap1->data, lda,
(float *)ap2->data, ldb,
- zeroF, (float *)ret->data, ldb);
+ zeroF, (float *)ret->data, ap1->dimensions[0]);
}
}
else {
--
Janne Sinkkonen, PhD
Xtract Ltd
|
|
From: Greg E. <gre...@ca...> - 2005-12-14 23:37:29
|
On Wednesday 14 December 2005 1:28 am, Peter Verveer wrote: > I would most likely release such a package using the GPL. > In addition, that would allow me to use other GPL > licensed software such as GSL with it. If you combine your package with something GPL and release the result, then of course you would have to release that combination under the GPL. But that doesn't prevent you from releasing your own package separately under a different licence if you want. The question you need to ask yourself is whether you really want to impose all the restrictions of the GPL on users of your package. If you have no desire to be that restrictive, then use a more liberal licence. -- Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | gre...@ca... +--------------------------------------+ |
> On Wednesday 14 December 2005 1:28 am, Peter Verveer wrote: > Sofar I have been very comfortable to make my package > available under the license that is used by numarray. The > same would be true for a scipy_core/scipy version. > However, for a general C package that could have a much > broader audience in the same way, I feel different. > I would most likely release such a package using the GPL. > In addition, that would allow me to use other GPL > licensed software such as GSL with it. "Use with" means many things. You write it, you choose the license, of course. But as an academic user/observer, rather than a substantial contributor, I have noticed that if your goal is to see your code used and improved, it is not clear that the GPL is the best way to pursue that goal. See e.g. the history of Matplotlib and MayaVi. (Or Python itself, for that matter, for a larger example.) Each case is individual, of course. If you need extant GPL code to be an *integral* part of your code, that makes the GPL natural. fwiw, Alan |
|
From: Christopher B. <Chr...@no...> - 2005-12-14 18:25:36
|
On Wednesday 14 December 2005 1:28 am, Peter Verveer wrote:
> Sofar I have been very comfortable to make my package available under
> the license that is used by numarray. The same would be true for a
> scipy_core/scipy version. However, for a general C package that could
> have a much broader audience in the same way, I feel different. I
> would most likely release such a package using the GPL. In addition,
> that would allow me to use other GPL licensed software such as GSL
> with it.
You could release it under two licenses, GPL for a C package that uses other
GPL software, and the SciPy license for the python extension.
The only thing that would kill that plan is if you use GPL code in the Python
extension.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
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: Peter V. <ve...@em...> - 2005-12-14 09:28:23
|
On 13 Dec, 2005, at 23:39, Travis Oliphant wrote: > >> However, even though I am the author, I am most likely not going >> to support it outside numarray. I do realize that at some point >> numarray may be retired, but I have not decided yet if I will be >> using/supporting nd_image beyond that point. It would be nice to >> have a common code-base with the numarray version so that all can >> profit from any bug-fixes that I am still doing in the numarray >> version. > > > So, do I take this to mean that you are not enthusiastic about a > merger between the Numeric and numarray communities? I would love > to hear why you feel this way. > From my perspective, it just makes unification that much harder to > have important third-party authors make these kinds of statements, > so I'm curious as to why you don't want to convert to a common code- > base. Because others may have the same feelings, it would help all > of us if we could address them. Don't worry about offending me or > others in the scipy world. We have pretty thick skins by this point. I think I should clarify what I intent to do with nd_image in the future. It affects current nd_image users and the numarray package also, so I am also sending this to the numpy list. First of all, I should stress that I am quite happy about a possible merger. It is quite likely that I will be using python for numerical work in the future, and a merger of numarray and Numeric into a package of equal or better quality will only make my life easier. Currently I am the only software developer within a scientific laboratory, but software development is not my main focus. I used python with numarray for virtual all of my numerical work, and nd_image was sort of a side effect of that. Right now I do not have the time to make a switch to a new package, nor can I really further expand nd_image. It would be nice to try moving to scipy_core now, which would help the community too I guess, but I just cannot affort it at the moment, so I am sticking with numarray for the time being. My situation will most likely change next year, since our group will move and expand a lot, and I will hopefully be able to have other people working on software development. I guess around that time we will see scipy_core mature, so that would be a good time to switch. I understand the numarray people take a wait-and-see approach, but intent to switch when scipy_core matures and fulfills their requirements. I guess I am following their example. So next year I will might be in the position of having more resources and I then will start thinking about developing some open-source scientific software. An imaging package like nd_image would be one of them. However, in contrast to the current design, I would like to move to a package that is fully written in C, with a thin interface layer to numarray/scipy_core for use with python. That would allow me to use the routines in other environments than python,. Sofar I have been very comfortable to make my package available under the license that is used by numarray. The same would be true for a scipy_core/scipy version. However, for a general C package that could have a much broader audience in the same way, I feel different. I would most likely release such a package using the GPL. In addition, that would allow me to use other GPL licensed software such as GSL with it. However, that would mean that a python package based on it would also be released with that license. I am not complete sure what the implications for distribution with a package like scipy would be, this may not be possible. But it would be freely available as a separate module which we would maintain ourself. If it pans out this way, it means that nd_image will not be further developed at some point. I am currently doing bug-fixes in the numarray version, and I certainly would not mind if there would be a common code-base allowing it to work with scipy_core. But if I am going to developer package as described above, I will to focus on that and recommend nd_image users to switch at some point. > > Even if your statement is made from the perspective of someone who > is moving away from Python altogether, I would still very-much > appreciate hearing your reasons. Now, perhaps, your just going to > experience a career-change altogether in which case, best wishes, > and thanks for all you've contributed. I will certainly stick with Python :-) > > Regardless of whether or not you have time to respond, I do > appreciate all your efforts. The nd_image package is very nice as > I've told you before. Thank you! Thanks! nd_image seems to find some users, and I would like to continue to provide something like nd_image. It might be a while though until nd_image or a replacement will start moving again and further developing. Meanwhile I am committed to keep nd_image working with numarray and doing minor bug-fixes. If we can at some point find a solution for a single code-base which would work with scipy_core, I am happy to expand this commitment to scipy_core. I cannot promise indefinite support, but as long as I am in the field and as long as I do not release a 'successor' package, I will try... Cheers, Peter |
|
From: Edward C. J. <edc...@co...> - 2005-12-14 04:27:23
|
I have an Athlon 64 chip. I use Debian unstable but I compile all Python
related programs myself. They go into /usr/local. I have Python 2.4.2
and numarray 1.5.0.
I got the following error from testall.test():
File
"/usr/local/lib/python2.4/site-packages/numarray/random_array/dtest.py",
line 57, in numarray.random_array.dtest
Failed example:
x = multivariate_normal(num.array([10,20]),
num.array(([1,2],[2,4]))); x
Expected:
array([ 9.95170432, 19.90340867])
Got:
array([ 9.95170432, 19.90340866])
|
|
From: Peter V. <ve...@em...> - 2005-12-13 08:26:56
|
On Dec 12, 2005, at 23:49, Travis Oliphant wrote: > >> That certainly would be nice. We are starting to look migrating >> some Python code. It may be a little while >> (a couple months?) before we can start tackling migrating some of >> the C extension code so we won't be exercising that right away >> (but maybe someone else can). >> > I think I will have something basic in-place by then. We can add > needed API calls as extensions get ported. > > On a related note, where should the Packages (like nd_image) from > numarray go? Should they all go into scipy core, full scipy, or be > separately downloadable as scipy_core addons? Regarding nd_image, I would guess that it should be an addon, or go at some point in scipy. However, even though I am the author, I am most likely not going to support it outside numarray. I do realize that at some point numarray may be retired, but I have not decided yet if I will be using/supporting nd_image beyond that point. It would be nice to have a common code-base with the numarray version so that all can profit from any bug-fixes that I am still doing in the numarray version. peter |
|
From: Travis O. <oli...@ie...> - 2005-12-12 23:35:12
|
>That certainly would be nice. We are starting to look migrating some >Python code. It may be a little while >(a couple months?) before we can start tackling migrating some of the C >extension code so we won't be exercising that right away (but maybe >someone else can). > > I think I will have something basic in-place by then. We can add needed API calls as extensions get ported. On a related note, where should the Packages (like nd_image) from numarray go? Should they all go into scipy core, full scipy, or be separately downloadable as scipy_core addons? -Travis |
|
From: Peter V. <ve...@em...> - 2005-12-12 21:35:09
|
Hi Travis, I am curious about your experience with moving nd_image to scipy_core. I have not had the time to look at scipy_core, so I have not tried to do it myself, although it was on my very-long-term list of things to do. Did it require a lot of changes and did you get it to pass the unit tests? Cheers, Peter > A few days ago I played with nd_image and was able to make it > compile for scipy_core. In the process, I had some ideas for > making the transition to scipy_core easier for numarray users: > > 1) It would be nice if there was someway to document on the Python > level any needed changes. In the process, we might find things > that need to be added to scipy_core. I would like to have some > kind of program for automatically making most of those needed > changes before a 1.0 release of scipy_core. > > 2) On the C-API side, my experience with nd_image showed me that > quite a few of the numarray C-API calls can be written as macros > while some will need to be additional functions. I think we could > easily write a numcompatmodule.c and associated numcompat.h file so > that users needing the numarray C-API could include the numcompat.h > file and then the import_libnumarray() command would load the > numcompatmodule.c with it's compatibility functions. > > In this way, the transition for C-API users could be as easy as > changing the include file to numcompat.h? > -Travis > > > > ------------------------------------------------------- > 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://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Numpy-discussion mailing list > Num...@li... > https://lists.sourceforge.net/lists/listinfo/numpy-discussion |
|
From: Travis O. <oli...@ie...> - 2005-12-12 20:48:48
|
A few days ago I played with nd_image and was able to make it compile for scipy_core. In the process, I had some ideas for making the transition to scipy_core easier for numarray users: 1) It would be nice if there was someway to document on the Python level any needed changes. In the process, we might find things that need to be added to scipy_core. I would like to have some kind of program for automatically making most of those needed changes before a 1.0 release of scipy_core. 2) On the C-API side, my experience with nd_image showed me that quite a few of the numarray C-API calls can be written as macros while some will need to be additional functions. I think we could easily write a numcompatmodule.c and associated numcompat.h file so that users needing the numarray C-API could include the numcompat.h file and then the import_libnumarray() command would load the numcompatmodule.c with it's compatibility functions. In this way, the transition for C-API users could be as easy as changing the include file to numcompat.h? -Travis |
|
From: Travis O. <oli...@ie...> - 2005-12-12 04:37:17
|
Ed Schofield wrote: >On 11/12/2005, at 8:53 AM, Travis Oliphant wrote: > > >Is there any chance of including type checking for this release for >unsafe in-place operations? Several people supported the idea in the >thread [In-place operators and casting] a few weeks ago. In summary, >the existing behaviour would still be achievable with an explicit cast: > >>> my_int_array += my_float_array.astype(int) > > Actually, this would not do the same thing because it would force the entire float array into memory as an integer array and then add it. The current behavior creates only bufsize memories for this kind of copying. So, for large-array performance this approach would be worse, which is a big reason I'm not really supportive of a switch. I'm also hesitant to change this because it is the default behavior of numarray, so I'd like to receive more feedback from members of that community who are coming over to scipy_core before doing something different. I think, however, Numeric raises an error in this circumstance. So, I would advise changing this behavior in the current release, but I don't see this issue as closed. While I would never support changing the data-type of the array when using an inplace operator, I could see the logic in raising an error when the type cannot be cast safely. -Travis |
|
From: Travis O. <oli...@ie...> - 2005-12-11 20:53:55
|
Christian Kristukat wrote: >Hi, >I noticed that using the new core together with older packages that are based on >numeric, like the plotting module from wxPython, matplotlib, grace_np.py, etc. >is problematic since numeric seems to be unable to recognize new core arrays as >equivalent to the numeric ones. > If you get a recent version (>=24.0) of Numeric then it shouldn't be a problem. One of the purposes of the array interface is to ease the transition, but only recent versions of Numeric use it properly. If there are problems with recent versions of Numeric and the array interface then please post them. Older versions of Numeric would need to use tostring and fromstring (better than tolist...) >In some cases it is sufficient to add a >.tolist() to array parameters but that is not really satisfactory. >Will a final version of new core have solved these incompatibilities? > > Unfortunately, I don't know how to solve incompatibilities with older versions of Numeric. All third-party libraries should either start using only the array interface or switch to scipy_core. I've noticed there is some confusion still circulating on the net that the new arrayobject in scipy_core is going to get into Python at some point, and some people are holding off making any changes until that happens. I am probably the source of that confusion since at one time I did have that goal. However, early on (in March) after discussions with Paul, Perry, and Guido we decided that trying to force an arrayobject into Python would place us on a release cycle that would be constraining. So, don't wait to try out scipy_core because there is nothing going into Python any time soon that is even as capable as Numeric. There are plans for getting a very simple arrayobject into Python (largely to enshrine the array interface), but we really need help moving that forward. With the recent changes to scipy_core, I think we have a very good design for a generic array object with associated data-descriptor that could go into Python. For python itself, I would only say that descriptors should only be written for Object, integer, float, and complex-float arrays. A PEP has been started and sits at http://svn.scipy.org/svn/PEP waiting for more people to help push it forward. Best, -Travis |
|
From: ghkkuk <df...@45...> - 2005-12-11 18:13:18
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=gb2312"> <title>无标题文档</title> <style type="text/css"> <!-- .style2 { color: #FFFFFF; font-weight: bold; font-size: 24px; } .style3 {color: #006666} .style4 {color: #FFFFFF; } .style7 {color: #CC0000} .style8 {color: #CC0000; font-weight: bold; } .style9 { color: #006666; font-weight: bold; font-size: 12px; } .style12 {font-size: 12px} .style13 {color: #006666; font-size: 12px; } .style14 {color: #CC0000; font-weight: bold; font-size: 12px; } .style15 {color: #CC0000; font-size: 12px; } .style16 {color: #FFFFFF; font-weight: bold; font-size: 12px; } --> </style> </head> <body> <table width="685" align="center" height="2738"> <tr> <td width="679" height="2734" bgcolor="#006666"><table width="672" align="center" bgcolor="#F7FFFF" height="2692"> <tr> <td width="794" height="113" bgcolor="#009999"><div align="left" class="style4"><span class="style12">【电 话】 0755/82129135 82128600 82128650 </span><br> </div> <p align="center" class="style2">★★<span class="style4"><font face="黑体">《<span style="font-size: 22.0pt; mso-ascii-font-family: Times New Roman; mso-hansi-font-family: Times New Roman; mso-bidi-font-family: Times New Roman; mso-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA; mso-bidi-font-weight: normal">[朗咸平] 中国企业战略突围研讨会</span> 》</font></span>★★</p> <p align="center" class="style16"> </p></td> </tr> <tr> <td height="85" width="794"><p align="center" class="style13">★<b>开课时间：2005年12月30-31日 （地点：深圳）★<br> </b> <br> <b> <br> ★主办：众人行管理咨询 ★</b></p> </td> </tr> <tr> <td height="18" bgcolor="#009966" width="794"></td> </tr> <tr> <td height="380" width="794"><p class="style3 style12"><font size="3"><b style="mso-bidi-font-weight:normal"><span lang="EN-US"></o:p> </span></b></font></p> <p class="MsoNormal"><font size="2"><span style="mso-ascii-font-family: Times New Roman; mso-hansi-font-family: Times New Roman"><b style="mso-bidi-font-weight: normal; mso-ascii-font-family: Times New Roman; mso-hansi-font-family: Times New Roman"><font face="黑体"> </font></b></span><font face="黑体"><b style="mso-bidi-font-weight: normal; mso-ascii-font-family: Times New Roman; mso-hansi-font-family: Times New Roman"><span style="mso-ascii-font-family: Times New Roman; mso-hansi-font-family: Times New Roman"><font color="#FF0000"> </font></span></b><font color="#FF0000"></font></font></font><span lang="EN-US"><b style="mso-bidi-font-weight:normal"><font color="#FF0000" size="2" face="隶书">微利年景：我们从哪儿来，到哪儿去？</font><font face="仿宋_GB2312" color="#FF0000" size="4"> </font><font color="#008080" face="仿宋_GB2312" size="1"><br> <br> </font><font color="#008080" face="仿宋_GB2312" size="2">目前，以中国为主的世界经济、产业链和消费者发生了彻底的改变。中国和日本的相当一批优秀企业出现了某种程度的停滞，比如索尼和松下均陷入了亏损，海尔在各种质疑中增长出现徘徊，联想在业绩连续增长迟缓后宣布收缩业务，TCL并购后正在步履艰难地谋求突破。<br> <br> 当优秀企业的停滞是以群体现象出现的时候，我们只能跳出具体的企业，只能跳出具体现象看问题。“做大做强”几乎是目前所有中国企业的目标和口号，为了做大做强可以不惜一切代价，这才是问题的根源。中国企业需要经过五大步骤实现突围：<br> <br> 1、对外部市场和经济环境进行整体评估；<br> 2、认识整体性的战略迷失；<br> 3、实施产业整合实现成本控制；<br> 4、实施内部垂直整合实现成本控制；<br> 5、企业战略性风险控制实现持续经营。</font><font color="#008080" face="仿宋_GB2312" size="1"><br> <br> </font><font color="#FF0000" size="2"><font face="仿宋_GB2312">本次</font><font face="黑体">论</font><font face="仿宋_GB2312">坛研究的内容――郎咸平教授首次系统性讲解最新的战略成果</font></font><font color="#008080" face="仿宋_GB2312" size="2"><br> <br> ◆第一，中国企业在成本控制不够规范、技术同化、资金获取的难度增大的情况下，能否找到市场需求而生存下来？</font></b><font size="2"> </font> </span></p> <p class="MsoNormal"><font face="仿宋_GB2312" size="2" color="#008080"><span lang="EN-US"><b style="mso-bidi-font-weight: normal"> <b style="mso-bidi-font-weight:normal">如何把握新经济时代突来的财富规律？商业机会在哪里产生？ </b></b> </span></font></p> <p class="MsoNormal"><span lang="EN-US"><b style="mso-bidi-font-weight:normal"> <font color="#008080" face="仿宋_GB2312" size="2"><br> ◆第二，为什么中国和日本等相当一批优秀企业陷入了整体性困境？</font></b><font size="2"> </font> </span></p> <p class="MsoNormal"><span lang="EN-US"><b style="mso-bidi-font-weight: normal"> <font face="仿宋_GB2312" size="2" color="#008080"> <b style="mso-bidi-font-weight:normal">比如：海尔在各种质疑中增长出现徘徊，TCL并购后正在步履艰难地谋求突破，索尼和松下均陷入了亏损。 <br> <br> </b></font><b style="mso-bidi-font-weight:normal"> <font size="2" color="#008080" face="宋体">◆</font></b><font face="宋体"><b style="mso-bidi-font-weight:normal"><font color="#008080" size="2">第三，以中国为主的世界经济、产业链和消费者发生了彻底的改变，各个代表性公司的公司战略有何变化？</font></b></font></b><font size="2"> </font> </span></p> <p class="MsoNormal"><span lang="EN-US"><b style="mso-bidi-font-weight: normal"> <font face="仿宋_GB2312" size="2" color="#008080"> <b style="mso-bidi-font-weight:normal">变化的过程是怎么样的？如何在危机中实现转机？ <br> <br> </b></font><b style="mso-bidi-font-weight:normal"> <font size="2" color="#008080" face="宋体">◆第四，对比各个环节的盈利能力，上下游厂商之间、制造商与经销商之间如何整合？企业内部如何进行整合？</font></b></b><font size="2"> </font> </span></p> <p class="MsoNormal"><span lang="EN-US"><b style="mso-bidi-font-weight: normal"> <font face="仿宋_GB2312" size="2" color="#008080"> <b style="mso-bidi-font-weight:normal">最终会到达什么样的程度？如何对盈利产生决定性影响？ <br> <br> </b></font><font color="#008080" face="宋体" size="2">◆第五，专业化和多元化的两项不同业务形态如何进行风险控制？</font></b><font size="2"> </font> </span></p> <p class="MsoNormal"><font face="仿宋_GB2312" size="2" color="#008080"><span lang="EN-US"><b style="mso-bidi-font-weight: normal"> <b style="mso-bidi-font-weight:normal">在各类型的企业中，哪类企业的治理架构对其未来的发展会有帮助？谁将会是最后的胜利者？ </b></b> </span></font></p> <p class="MsoNormal"><span lang="EN-US"><b style="mso-bidi-font-weight:normal"> <font color="#008080" face="仿宋_GB2312" size="2"><br> <br> </font><font face="仿宋_GB2312" size="2" color="#FF0000">我们处在什么位置？我们未来向哪里突围？</font></b></span><font color="#FF0000" size="2"> </font><span lang="EN-US"><b style="mso-bidi-font-weight:normal"> <font face="仿宋_GB2312" size="2" color="#FF0000">四大核心模块，两天讲解演练</font><font color="#008080" face="仿宋_GB2312" size="2"><br> <br> ◆核心内容：讲授战略突围整体框架、经济环境变化导致的战略取向、经营手段和经营管理思维变化，以及寻找新的利润规律和特点。<br> <br> 成果：寻找新利润点和财富规律 确定战略思维突破方案<br> <br> <br> ◆核心内容：详细阐述中国企业专业化和多元化运作的不同的风险控制方法，以及实现战略目标的股市和融资操纵。<br> <br> 成果：战略风险控制操作方案战略财务管控操作方案<br> <br> <br> ◆核心内容：打破惯性思维带给中国企业的普遍性战略迷失，以真实的案例分析告诉企业如何避免战略失败，如何在战略迷失中实现战略转型。<br> <br> 成果：破解战略失败或困境之迷解读企业的战略路线图<br> <br> <br> ◆核心内容：通过国内外标干型企业案例研究，指导中国企业建立世界级竞争能力和中国化的战略突围之路――横向产业整合、纵向垂直整合。<br> <br> 成果：横向产业整合操作方案纵向内部垂直整合操作方案</font></b></span></p> <p class="MsoNormal"><span lang="EN-US"><b style="mso-bidi-font-weight:normal"> <font color="#008080" face="仿宋_GB2312" size="2"><br> <br> </font><font face="仿宋_GB2312" color="#FF0000" size="2">时代已经变化，如果企业不懂得经济变化规律和世界级的公司治理规律，那么企业的衰败、甚至倒闭都只是时间的问题！</font><font color="#008080" face="仿宋_GB2312" size="2"><br> <br> 邓小平带领我们走完20年，谁告诉你未来20年――如何把握新经济时代突来的财富规律？<br> <br> 为什么中国的多数产业和企业都陷入了整体性的同质化竞争，利润率不断降低，增长停滞？<br> <br> 为什么三星、LG、中兴通讯等公司能不断扩张，背后机理和可以直接学习的操作方法是什么？<br> <br> 为什么有些企业可以长盛不衰――优秀企业是如何实现风险控制？企业持续的基理是什么？</font><font size="2"></o:p> </font></b></span></p> <p class="style13"> </p> </td> </tr> <tr> <td height="18" bgcolor="#009966" width="794"></td> </tr> <tr> <td width="794" height="609"><p class="style8">★课程提<b style="mso-bidi-font-weight:normal"><span style="font-size:12.0pt;font-family:宋体;mso-ascii-font-family:"Times New Roman"; mso-hansi-font-family:"Times New Roman";mso-bidi-font-family:"Times New Roman"; mso-font-kerning:1.0pt;mso-ansi-language:EN-US;mso-fareast-language:ZH-CN; mso-bidi-language:AR-SA">纲</span></b></p> <table width="637"> <tr> <td vAlign="top" width="72"> <div align="center"> <b><font size="2" color="#008080">课程分段</font></b> </div> </td> <td vAlign="top" width="399"> <div align="center"> <b><font size="2" color="#008080">核 心 内 容</font></b> </div> </td> <td vAlign="top" width="146"> <div align="center"> <b><font size="2" color="#008080">授课时间</font></b> </div> </td> </tr> <tr> <td width="72"> <div align="center"> <font size="2" color="#008080"><b>第一部分</b></font> </div> </td> <td width="399"> <div> <font size="2" color="#008080"><b>如何真正的突围：战略突破构成，经营思维、经营环境分析</b></font> </div> </td> <td width="146"> <div> <font size="2" color="#008080"><b>30日9：00-10：20</b></font> </div> </td> </tr> <tr> <td width="72"> <div align="center"> <font size="2" color="#008080"><b>第二部分</b></font> </div> </td> <td width="399"> <div> <font size="2" color="#008080"><b>为什么陷入困境：剖析中日失败企业实际案例走出错误战略</b></font> </div> </td> <td width="146"> <div> <font size="2" color="#008080"><b>30日10：40-12：00</b></font> </div> </td> </tr> <tr> <td width="72"> <div align="center"> <font size="2" color="#008080"><b>第三部分</b></font> </div> </td> <td width="399"> <div> <font size="2" color="#008080"><b>危机中寻找转机：剖析韩国标干企业实际案例启发突围之路</b></font> </div> </td> <td width="146"> <div> <font size="2" color="#008080"><b>30日14：00-15：20</b></font> </div> </td> </tr> <tr> <td width="72"> <div align="center"> <font size="2" color="#008080"><b>第四部分</b></font> </div> </td> <td width="399"> <div> <font size="2" color="#008080"><b>真正的中国成功：剖析中国标干企业实际案例确定企业战略</b></font> </div> </td> <td width="146"> <div> <font size="2" color="#008080"><b>30日15：40-17：00</b></font> </div> </td> </tr> <tr> <td width="72"> <div align="center"> <font size="2" color="#008080"><b>第五部分</b></font> </div> </td> <td width="399"> <div> <font size="2" color="#008080"><b>我们凭什么不死：向高风险地产业学习风险控制的持续战略</b></font> </div> </td> <td width="146"> <div> <font size="2" color="#008080"><b>31日9：00-10：20</b></font> </div> </td> </tr> <tr> <td width="72"> <div align="center"> <font size="2" color="#008080"><b>第六部分</b></font> </div> </td> <td width="399"> <div> <font size="2" color="#008080"><b>我们凭什么不死：向高风险地产业学习风险控制的持续战略</b></font> </div> </td> <td width="146"> <div> <font size="2" color="#008080"><b>31日10：40-12：00</b></font> </div> </td> </tr> <tr> <td width="72"> <div align="center"> <font size="2" color="#008080"><b>第七部分</b></font> </div> </td> <td width="399"> <div> <font size="2" color="#008080"><b>现场企业的演练：郎教授现场分析指导贵宾企业的战略选择</b></font> </div> </td> <td width="146"> <div> <font size="2" color="#008080"><b>31日14：00-15：20</b></font> </div> </td> </tr> <tr> <td width="72"> <div align="center"> <font size="2" color="#008080"><b>第八部分</b></font> </div> </td> <td width="399"> <div> <font size="2" color="#008080"><b>现场问题的解答：郎教授解答现场企业家提出的问题</b></font> </div> </td> <td width="146"> <div> <font size="2" color="#008080"><b>31日15：40-17：00</b></font> </div> </td> </tr> </table> <p class="MsoNormal"><span lang="EN-US"><b style="mso-bidi-font-weight: normal"> </o:p></b><font face="仿宋_GB2312" size="2"><span style="mso-bidi-font-weight: normal"><strong><font color="#dd0000"><b style="mso-bidi-font-weight: normal">第一部分：战略分析――我们在哪里，未来财富规律是什么？</b></font></strong></span></font><font size="2"> </font> </span></p> <p class="MsoNormal"><span lang="EN-US"><span style="mso-bidi-font-weight: normal"> <font face="仿宋_GB2312" size="2"><strong><font color="#dd0000"><b style="mso-bidi-font-weight: normal"><br> </b></font></strong></font> <b style="mso-bidi-font-weight: normal"><font face="仿宋_GB2312" size="2"><font color="#008080">战略突围要点：当优秀企业的停滞是以群体现象出现的时候，我们只能跳出具体的企业，放到经济大环境中来分析――我们现在在哪里，我们未来如何转变竞争，实现突围、获取利润。<br> <br> <strong>第一节：为什么陷入整体性困境――从标杆性企业中寻找问题</strong><br> 案例研究（1）：为什么联想在业绩连续增长迟缓后宣布收缩业务<br> 案例研究（2）：为什么TCL在国际化并购后正在步履艰难地谋求突破<br> <br> 柳传志和杨元庆的思维：中国企业家普遍性错位的战略思维<br> -我有资金，哪个行业有潜力，就投资哪个行业<br> -企业不大哪会作强呢，做大才会作强<br> <br> 联想进入500强的措施――中国企业战略突围面临的普遍问题<br> -国际化：缺乏国际化的战略视野和与之相对应的人才和文化<br> -进入新业务：与公司核心业务在发展阶段和管理模式上有差异<br> -战略突围方案：没有搞清楚什么叫做企业经营战略<br> -企业跨区域扩张：企业做大导致成本失控，没有成本机制<br> <br> <strong>第二节：谁告诉你未来20年――新财富规律产生的因素及影响<br> </strong>案例研究（1）：中国经济环境变化及与日韩等国经济发展过程对比<br> 案例研究（2）：成熟市场下的企业竞争――美国欧洲的企业经营研究<br> <br> 企业经营大环境的变化――新财富的规律是什么？<br> -中国经济、产业链和消费者发生了哪些改变，对企业的影响是什么？<br> -布满鲜花的陷阱：中国企业的股权改革、董事会职权改革方案<br> -中国的汇率制度掌握企业家的财富，企业要如何应对？<br> -日本和韩国的经济演变过程对中国企业的启示是什么？<br> <br> 什么是真正做大做强思维，企业家经营思维需要如何转变？<br> -管理精细化：用精细化的运营思维建立系统管理力实现不断做大做强<br> -运营程序化：程序化是大规模复制的基础，只有程序化才有规模化<br> -经营责任化：所有的管理都可以归结成为一句话，叫“责权利对等”<br> <br> <br> </font></font> <font face="仿宋_GB2312"><strong><font color="#FF0000" size="2">第二部分：战略转型――检查战略路线，制定战略转型方案</font></strong></font></b></span><font size="2"> </font> </span></p> <p class="MsoNormal"><span lang="EN-US"> <font face="仿宋_GB2312" size="2"><span style="mso-bidi-font-weight: normal"><b style="mso-bidi-font-weight: normal"><strong><font color="#008080"><br> </font></strong><font color="#008080">战略突围要点：时代变了，企业竞争的本质也发生了变化。原先成功的经验可能成为阻碍我们发展的力量，时刻检查自己的战略，引入危机思维，在危机中实现转机。<br> <br> <strong>第一节：战略风标――认清战略危机的本质，判断公司战略状况</strong> <br> 案例研究（1）：索尼如何在错误战略思维和业务模式指导下陷入困境<br> 案例研究（2）：松下电器为什么战略失误下依然有可能实现战略突围<br> <br> 战略思维错位：在战略层面，我们的总裁必须面对的三个陷阱<br> -原先成功的理念和文化到最后会让你陷入困境，对公司产生某种制约<br> -研发出前所未有，触动消费者心弦的产品，创造出全新的市场需求<br> -有很好的市场机会和资金，就可以进入自己一个完全不熟悉的领域<br> <br> 战略运营错位：如何通过我们对业务的检查来判断战略的迷失<br> -失去了核心技术，获取的成本比其他人高<br> -要向竞争对手买入技术<br> -对手形势大好，合作围攻<br> -业务间的互相冲突使得业务互相拖垮，减低了公司对投资的价值 <br> <br> <strong>第二节：战略转型――在危机中实现转机，制定战略转型方案<br> </strong>案例研究（1）：法国总裁格恩如何带领日产实现战略转型<br> 案例研究（2）：金志国如何带领青岛啤酒走出过渡扩张带来的危险<br> <br> 我们在哪里陷入困境：企业战略缺失的普遍性表象<br> -缺乏竞争原因：以和为贵的文化、墨守成规、缺乏沟通、没有危机感<br> -直接对经营的威胁：业务成本高昂、财务管理不善、产品开发迟缓<br> <br> 战略转型的“白纸策略”：碰到危机时候能上下一心接受新观念<br> -第一步，抛弃过去，不带成绩，从一张白纸开始<br> -第二步，聆听、不避讳，广纳良言，营造开放的公司形态<br> -第三步，建立跨部门小组，公司人员解决自己的问题<br> -第四步，复兴计划让员工直接参与<br> -第五步，同舟共济，如果做不成，总经理首先辞职<br> <br> <br> </font><strong><font color="#FF0000">第三部分：战略整合――建立世界级竞争能力和中国化战略</font></strong></b></span></font><font size="2"> </font> </span></p> <p class="MsoNormal"><span lang="EN-US"> <font face="仿宋_GB2312" size="2"><span style="mso-bidi-font-weight: normal"><b style="mso-bidi-font-weight: normal"><font color="#008080"><br> <span lang="EN-US" style="mso-bidi-font-size: 12.0pt; mso-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA; mso-fareast-font-family: 宋体; mso-bidi-font-family: Times New Roman; mso-bidi-font-weight: normal">4</span>战略突围要点：不要向世界级公司学习，要学习具备世界级做法和能力的公司，如何进行垂直整合和侧向整合，在产业链和价值链里实现战略突围。<br> <br> <strong>第一节：企业垂直整合战略――以逆向思维构建内部协同竞争力<br> </strong>案例研究（1）：三星电子如何建立超一流的竞争力系统，席卷全球<br> 案例研究（2）：雅戈尔集团用垂直整合进行“逆向突破”<br> <br> 战略思维突破：要进入一个行业，就要理解事物的本质<br> -第一，转变成一个放弃寻找潜力行业，注重危机的管理意识<br> -第二，技术不创造利润，科技只能创造一个固定的回报<br> -第三，IT的技术是不可被隐藏的和不可能超越的<br> <br> 运营手段突破：注重价值链的创新，而不是产品本身的创新<br> -操作要点①：生产规模最大化――把对手的生产成本变成自己的利润<br> -操作要点②：稳定零部件供应――下游供应链系统的垂直整合<br> -操作要点③：反向工程――引入技术，改造成适合自己的研发方向<br> <br> <strong>第二节：企业侧向整合战略――以逆向思维构建利润整合系统</strong><br> 案例研究（1）：“新秀”中兴通讯――如何赶超巨龙通信、大唐电信<br> 案例研究（2）：“新秀”华为技术――如何在围堵中崛起<br> <br> 思维突破：技术研究速度第一，成本第二<br> -操作要点：技术研发影响――以产品结构策略提升研究成果利用率<br> <br> 思维突破：用主营业务周期互补的特质，将总盈利增长平稳化<br> -操作要点：利润影响――以企业内部资源或外部环境的变动施予不同的操作，以应对不同的模仿产品竞争及市场顾客喜好作多样性变动<br> <br> 思维突破：内部营运影响――经营要素的整合，提高收益<br> -操作要点①：材料和厂房共享，弹性运用资源，控制成本，增加利润<br> -操作要点②：资源共享的另一个效益是工作人员生产力的提升，原因是整合使人手调配更加容易<br> <br> <br> </font><strong><font color="#FF0000">第四部分：战略控制――保证不死的风险控制和融资操纵</font></strong></b></span></font><font size="2"> </font> </span></p> <p class="MsoNormal"><span lang="EN-US"> <font face="仿宋_GB2312" size="2"><span style="mso-bidi-font-weight: normal"><b style="mso-bidi-font-weight: normal"><font color="#008080"><strong><br> </strong>战略突围要点：战略突围的本质是保证公司不死，万科董事长王石做演讲时他一定不忘记讲香港的地产，向世界一流的风险控制和融资操纵高手学习战略控制。课程将详细分析和指导。<br> <br> <strong>第一节：专业化公司的风险控制和融资操纵战略<br> </strong>案例研究（1）：恒基兆业如何走到高利润、高风险、股价低<br> 案例研究（2）：新鸿基如何做到稳健经营<br> <br> 战略思维突破：不应该用高负债来经营<br> -必须减低负债率、缩小成长、提高现金流<br> -市盈率就是市场信心指数，市场对你的信心跟公司的借债是有关系<br> -如果你现在还非常激进，你将来被淘汰的风险是非常大的<br> <br> 运营手段突破：如何在运营中实现风险控制<br> -不同业务的组合，形成互补作用<br> -通过不同业务的周期减低集团的整体风险<br> -好的项目而且尽量压低价格进行私有化，如何应对股民反对<br> -项目有风险就搞分拆上市，如何应对股民反应<br> <br> <strong>第二节：多元化公司的风险控制和融资操纵战略<br> </strong>案例研究（1）：新世界如何从危机中实现专机<br> 案例研究（2）：长江实业多元化下的风险控制和融资策略<br> <br> 战略风险：行业大萧条，毛利大幅下跌，运营现金入不敷出<br> -直接表现：负债急升 / 收入不足以应付支出 / 每股盈利持续下跌 / 市值大跌 / 股价大跌，使得股价长期低于帐面值 <br> <br> 如何在危险的市场状况中拟定公司的风险控制和融资<br> -第一步曲，分析业务性质，评估有潜力的企业进行重组<br> -第二步曲，重组产生协动效应――提供稳定的现金流支援下滑行业<br> -第三步曲，包装上市，重新估价</font><br> <br> <br> <strong><font color="#dd0000">第五部分：现场企业战略规划与指导、郎教授答企业家问</font></strong></b></span></font><b style="mso-bidi-font-weight: normal"><br> </b> </span></p> <p class="style14"> </p> </td> </tr> <tr> <td height="18" bgcolor="#009966" width="794"></td> </tr> <tr> <td width="794" height="208"><p class="style13"> </p> <p class="style13"><span class="style7">【培训地点】 </span> <span style="mso-ascii-font-family: Times New Roman; mso-hansi-font-family: Times New Roman; mso-bidi-font-family: Times New Roman; mso-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA"><b style="mso-bidi-font-weight: normal; mso-ascii-font-family: Times New Roman; mso-hansi-font-family: Times New Roman; mso-bidi-font-family: Times New Roman; mso-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA"><font face="仿宋_GB2312" size="2">深圳市</font></b></span></p> <p class="style13"><span class="style7">【培训费用】 </span>5800元/人，（包含教材、茶点水果、两天午餐）此次课程限200人，报满即止，所有的位置安排均按照报名先后排序。<br> 贵宾票：8800元 包含1）贵宾席就座；2）与郎教授用餐一次；3）与郎教授对话；4）与郎教授单独合影；5）赠送郎教授亲笔签名著作；6）免费2晚住宿。<br> <br> <span class="style7">【电 话】 </span> 0755-82129135 82128600 82128650</p> <p class="style13"><span class="style7">【传 真】 </span> 0755-61351396 82129209 邮箱：xia...@12...</p> <p class="style13"> </p></td> </tr> <tr> <td height="9" bgcolor="#009966" width="794"></td> </tr> <tr> <td valign="top" width="794" height="202"><p class="style3"><br> <span class="style14">★ </span><font size="2"><b><font color="#FF0000">培训讲师：</font></b></font><strong><font size="2" color="#FF0000">郎咸平</font></strong><font size="2"><br> </font><font color="#008080"><font size="2"><br> 美国沃顿商学院博士、世界级的公司治理和金融专家<br> 长江商学院（首席）教授，兼任香港中文大学首席教授<br> 长江实业董事局主席李嘉诚、万科集团董事长王石、<br> 长江商学院院长项兵的一致推荐公司治理顾问；<br> 世界银行、深圳证券交易所公司治理顾问<br> <br> <br> <strong>部分参会人员名单：</strong><br> <br> 招商局国际有限公司 王 宏 董事副总裁 <br> 北京金吉列企业集团公司 张世杰 总裁 <br> 华映光电股份有限公司 彭耀铭 总经理 <br> 深圳市东部开发集团公司 张淑云 副总经理 <br> 北京万通集团有限公司 胡加方 执行董事 <br> 北京万通集团有限公司 孙晓明 总裁 <br> 香港南洋国际物流集团公司 蔡 敏 总经理 <br> 中国长城计算机股份公司 周庚申 总裁 <br> 许继电气股份有限公司 李富生 总经理 <br> 中国机械设备进出口总公司 谢 彪 董事长 <br> BＰ石油（中国）公司 柴建生 北亚太区总坚 <br> 香港中国近海石油服务公司 相庆生 总经理 <br> 天津万科房地产有限公司 周成辉 总经理 <br> 新加坡国立大学 王披恩 博士 <br> 百江投资集团 胡 强 副总裁 </font><br> </font></p> </td> </tr> <tr> <td height="42" bgcolor="#F7FFFF" width="794"><p class="style14"><font color="#008080"> 企业董事长、总裁、副总裁、总经理、副总经理等企业高层管理人士.</font><br> </p> </td> </tr> <tr> <td height="18" bgcolor="#009966" width="794"></td> </tr> <tr> <td width="794" height="211"> <p class="style13"><span class="style7">【培训地点】 </span> <span style="mso-ascii-font-family: Times New Roman; mso-hansi-font-family: Times New Roman; mso-bidi-font-family: Times New Roman; mso-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA"><b style="mso-bidi-font-weight: normal; mso-ascii-font-family: Times New Roman; mso-hansi-font-family: Times New Roman; mso-bidi-font-family: Times New Roman; mso-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA"><font face="仿宋_GB2312" size="2">深圳市</font></b></span></p> <p class="style13"><span class="style7">【培训费用】 </span>5800元/人，（包含教材、茶点水果、两天午餐）此次课程限200人，报满即止，所有的位置安排均按照报名先后排序。<br> 贵宾票：8800元 包含1）贵宾席就座；2）与郎教授用餐一次；3）与郎教授对话；4）与郎教授单独合影；5）赠送郎教授亲笔签名著作；6）免费2晚住宿。<br> <br> <span class="style7">【电 话】 </span> 0755-82129135 82128600 82128650</p> <p class="style13"><span class="style7">【传 真】 </span> 0755-61351396 82129209 邮箱：xia...@12...</p> </td> </tr> <tr> <td valign="top" width="794" height="709"><DIV> <DIV><FONT size=2><FONT color=#666666><BR> <BR> </FONT></FONT></DIV> <DIV><DIV><FONT size=2><FONT color=#666666> <TABLE width="100%"> <TBODY> <TR> <TD width="100%"><BLOCKQUOTE style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px"> <DIV align=center> <TABLE height=576 cellSpacing=0 width="96%" border=0> <CENTER> <TR> <TD width="100%" colSpan=2 height=1><P align=center>---------------------------------------------------------------------------------------------- </P> <P class="style12" style="LINE-HEIGHT: 150%"><BR> 培 训 回 执 表 （此表复制有效）<BR> <BR> <B>传真至：(0755)61351396 / 82129209<BR> </B><BR> 我单位共＿＿＿ 人报名参加<SPAN lang=EN-US>2005年</SPAN>在<B> </B><font size="2"><b style="mso-bidi-font-weight:normal"><span style="font-family: 宋体; mso-ascii-font-family: Times New Roman; mso-hansi-font-family: Times New Roman; mso-bidi-font-family: Times New Roman; mso-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA">深圳</span></b></font><B> </B>举办的</FONT></FONT><font color="#008080" size="3">；<BR> </font><FONT color=#666666 size="2"> <BR> 单位名称：＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿<BR> <BR> 培训联系人：＿＿＿＿＿＿＿＿＿ 联系电话：＿＿＿＿＿＿＿＿＿ 联系传真：＿＿＿＿＿＿＿＿＿＿＿ <BR> <BR> 移动电话：＿＿＿＿＿＿＿＿＿＿＿＿ 电子邮箱：＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ <BR> <BR> 参加人数：＿＿＿＿ 人 费用总计：＿＿＿＿＿＿ 元<BR> <BR> 参 会 人：＿＿＿＿＿＿＿＿ 所任职务：＿＿＿＿＿＿＿＿＿＿ 移动电话：＿＿＿＿＿＿＿＿＿＿＿＿ <BR> <BR> 参 会 人：＿＿＿＿＿＿＿＿ 所任职务：＿＿＿＿＿＿＿＿＿＿ 移动电话：＿＿＿＿＿＿＿＿＿＿＿＿ <BR> <BR> 参 会 人：＿＿＿＿＿＿＿＿ 所任职务：＿＿＿＿＿＿＿＿＿＿ 移动电话：＿＿＿＿＿＿＿＿＿＿＿＿ <BR> <BR> <B>报名热线：0755/82129135 82128600 82128650<BR> 传真电话：61351396 / 82129209 <BR> 联 系人：<font color="#666666">林</font>小姐、彭<font color="#666666">小姐</font> </B><BR> <B>参会方式：</B>请您把培训回执表填写好回传，课前一星期您将会收到传真函，包括培训注意事项及详细安排。</P></FONT></TD> </TR> </center> </TABLE> </DIV> </BLOCKQUOTE></TD> </TR> </TABLE> </DIV> </DIV> </DIV></td> </tr> <tr> <td height="1" bgcolor="#009966" width="794"></td> </tr> </table></td> </tr> </table> </body> </html> |
|
From: Colin J. W. <cj...@sy...> - 2005-12-11 14:52:12
|
Travis,
This is intended to restore the context of your response. TO is Travis
Oliphant, CW is Colin Williams
TO:
The dtype parameter is still used and it is still called the same
thing. It's just that what constitutes a data-type has changed
significantly.
For example now tuples and dictionaries can be used to describe a
data-type. These definitions are recursive so that whenever
data-type is used it means anything that can be interpreted as a
data-type. And I really mean data-descriptor, but data-type is in
such common usage that I still use it.
CW:
This would appear to be a good step forward but with all of the
immutable types (int8, FloatType, TupleType, etc.) the data is
stored in the ArrayType instance (array_data?) whereas, with a
dictionary, it would appear to be necessary to store the items
outside the array. Is that desirable?
TO:
I don't even understand what you are questioning here. Perhaps you
misunderstood me. Items are always stored in the array. Even
records "items" are stored in the array. The descriptor just
allows you to describe what kind of data and how it is stored in the
array.
Response:
Yes, I had assumed that int8 and FloatType are equally
data-descriptors, i.e. objects which describe the elements of a
numeric array. Wrongly, I assumed that TupleType or DictType are
also a data descriptors.
Mea culpa.
On another subject, it would help, for those of us who are not
afficionados of C, if you provided the equivalent Python def
statement for those function implemented in C, especially the
ArrayType's __new__ method. perhaps in the docstrings.
Colin W.
Travis Oliphant wrote:
> Colin J. Williams wrote:
>
>>
>> This would appear to be a good step forward but with all of the
>> immutable types (int8, FloatType, TupleType, etc.) the data is stored
>> in the ArrayType instance (array_data?) whereas, with a dictionary,
>> it would appear to be necessary to store the items outside the
>> array. Is that desirable?
>
>
> I don't even understand what you are questioning here. Perhaps you
> misunderstood me. Items are always stored in the array. Even records
> "items" are stored in the array. The descriptor just allows you to
> describe what kind of data and how it is stored in the array.
>
>>
>> Even the tuple can have its content modified, as the example below
>> shows:
>>
> I don't understand what you mean to show by the
> tuple-content-modifying example.
>
>>> dtype=(int32, (5,5)) --- a 5x5 array of int32 is the description
>>> of this item.
>>> dtype=(str, 10) --- a length-10 string
>>
>>
>>
>> So dtype now contains both the data type of each element and the
>> shape of the array? This seems a significant change from numarray or
>> Numeric.
>
>
> No, no. Standard usage is the same. In normal usage you would not
> create an array this way. You could, of course, but it's not the
> documented procedure. The reason for this descriptor is to allow
> you to have a field-element that itself is an array of items.
>
>>
>>
>>> dtype=(int16, {'real':(int8,0),'imag':(int8,4)} --- a descriptor
>>> that acts
>>>
>>> like an int16 array mathematically
>>>
>>> (in ufuncs) but has real and imag
>>>
>>>
>>> fields.
>>>
>>>
>> This adds complexity, is there a compensating benefit? Do all of the
>> complex operations apply?
>
>
> I'm only showing what is possible and that the notion of data-type
> descriptor is complete.
>
>>
>> Why not clean things up by dropping typechar? These seemed to be one
>> of the warts in numarray, only carried forward for
>> compatibility reasons. Could the compatibility objectives of the
>> project not be achieved, outside the ArrayType object, with a wrapper
>> of some sort?
>
>
> Too hard to do at this point. Too much code uses the characters. I
> also don't mind the characters so much (the struct module and the
> Python array module use them).
>
>>
>> Couldn't the use of records avoid the cumbersome use of keys?
>
>
> Yes. But, this is how you specify fields generally.
>
>>
>>> format2 (and how it's stored internally)
>>>
>>> {key1 : (data-type1, offset1 [, title1]),
>>> key2 : (data-type2, offset2 [, title2]),
>>> ...
>>> keyn : (data-typen, offsetn [, titlen])
>>> }
>>>
>> This is cleaner, but couldn't this inormation be contained within the
>> Record instance?
>
>
>
> Yes, but I am describing a general concept of data-type description
> not just something applicable to records.
>
>>> Thus, you can do something like this:
>>>
>>> >>> a = ones((4,3), dtype=(int16, {'real':(int8, 0), 'imag':(int8,
>>> 1)}))
>>> >>> a['imag'] = 2
>>> >>> a['real'] = 1
>>> >>> a.tostring()
>>> '\x01\x02\x01\x02\x01\x02\x01\x02\x01\x02\x01\x02\x01\x02\x01\x02\x01\x02\x01\x02\x01\x02\x01\x02'
>>>
>>>
>> Or, one could have something like:
>> class SmallComplex(Record):
>> ..''' This class typically has no instances in user code. '''
>> ..real= (int8, )
>> ..imag= (int8)
>> ..def __init__(self):
>> ....
>> ..def __new__(self):
>> ....
>>
>> >>> a = ones((4,3), dtype= SmallComplex)
>> >>> a.imag = 2
>> >>> a.real = 1
>> >>> a.tostring()
>> '\x01\x02\x01\x02\x01\x02\x01\x02\x01\x02\x01\x02\x01\x02\x01\x02\x01\x02\x01\x02\x01\x02\x01\x02'
>>
>
>
> Yes, something like this should be possible, though I have not fleshed
> out the user-interface at all. I've just been working on the basic
> structure that would support such things. Do:
>
> class small_complex(record):
> dtypedescr = {'r':(int8,0),'i':(int8,1)}
>
> a = ndrecarray((4,3), formats=small_complex)
> a.r = 1
> a.i = 2
> a.tostring()
>
> and your example would work (with current SVN...)
>
> The ndrecarray subclass allows the attribute-to-field conversion,
> regular arrays do not.
>
> -Travis
>
>
>
>
>
>
>
>
>
> -Travis
>
>
|
|
From: Christos S. <chr...@ul...> - 2005-12-10 18:31:59
|
On Tue, Dec 06, 2005 at 06:37:11PM -0500, Alan G Isaac wrote: > On Tue, 6 Dec 2005, Christos Siopis apparently wrote: > > > As a side note, i am wondering if there is a semantic > > asymmetry in using min() and max() to signify the min/max > > element in the entire array while argmin() and argmax() > > signify the min/max element along each axis. > > SciPy arrays function as "expected" in this sense: > >>> import scipy > >>> x=scipy.array([[1,2],[3,4]]) > >>> x.max() > 4 > >>> x.argmax() > 3 > > Note that, as I understand, argmax gives the index from x.flat Thanks for the note. I do not have SciPy installed to test this, and i am not sure which version of SciPy you are using. I believe in the (remote?) past, SciPy was using Numeric as a core, but using the latest Numeric available on Gentoo AMD64 i obtain different results: Python 2.4.2 (#1, Nov 19 2005, 12:30:12) [GCC 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)] on linux2 >>> import Numeric >>> Numeric.__version__ '23.7' >>> x=Numeric.array([[1,2],[3,4]]) >>> x.max() Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: max >>> x.argmax() Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: argmax i.e., these methods are not supported for Numeric arrays. The max() function does not exist either: >>> Numeric.max(x) Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'module' object has no attribute 'max' (i think one would have to use MA.Maximum() to find the global array maximum back at those days...). And: >>> Numeric.argmax(x) array([1, 1]) i.e., it does not flatten the array. --- Now, using numarray: >>> import numarray >>> numarray.__version__ '1.3.1' >>> x=numarray.array([[1,2],[3,4]]) >>> x.max() 4 >>> x.argmax() array([1, 1]) i.e., these methods for the array object now do exist, but the behavior of argmax() is not the same as in your SciPy. My conjencture is that your SciPy uses some "intermediate" version between the old Numeric and the current scipy.core which, as i understand from what Travis said, supports the above numarray behavior. > Also, the scipy ufuncs max and argmax have the symmetry you > seek, if I understand correctly. With so many versions of things floating around, i think it's hard to tell what has what any more... One more reason to look forward to the outcome of Travis' work, and hope that things (or at least the API) will stabilize... Thanks, Christos |
|
From: Darren D. <dd...@co...> - 2005-12-07 11:30:29
|
On Wednesday 07 December 2005 5:07 am, Arnd Baecker wrote: > Hi, > > has anyone figured out how to use dotblas > with the AMD Core Math Library (ACML, http://developer.amd.com/acml.aspx)? > Darren Dale asked this a month ago here > http://aspn.activestate.com/ASPN/Mail/Message/numpy-discussion/2886285 > but I could not find any answer. I don't have any progress to report, sorry. Darren |
258 messages has been excluded from this view by a project administrator.
