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

Re: [Numpy-discussion] Strange numpy.argmax behavior on object arrays in numpy 1.0.

[Tom D. <tom...@al...>]

Oh.  My mistake. I thought I had an array of 2 objects which were ints.  I
actually had an array of one list of 2 ints.  It works properly if I
construct the array properly.


In [14]: a = numpy.empty((2), dtype=object)

In [15]: a[0:]=[2,3]

In [16]: a
Out[16]: array([2, 3], dtype=object)

In [17]: a.shape
Out[17]: (2,)

In [18]: a[0]
Out[18]: 2

In [19]: a[1]
Out[19]: 3

In [20]: numpy.argmax(a)
Out[20]: 1






On 10/29/06, Charles R Harris <cha...@gm...> wrote:
>
>
>
>  On 10/29/06, Tom Denniston <tom...@al...> wrote:
> >
> > I recently upgraded to numpy 1.0 from 1.0b5.   I noticed that
> > numpy.argmax behavior is very strange on object arrays.  See below:
> >
> > (Pdb) numpy.__version__
> > '1.0'
> > (Pdb) numpy.argmax(numpy.array([2, 3], dtype=object))
> > 0
> > (Pdb) numpy.argmax(numpy.array([2, 3], dtype=int))
> > 1
> > (Pdb) numpy.argmax(numpy.array([2, 3], dtype=object), axis=0)
> > 0
> >
> >
> > I would expect the argmax to behave the same on the dtype=int and
> > dtype=object examples but it doesn't.  Am I missing some subtelty or is this
> > just a bug?  1.0 is the most recent version, right?
> >
>
> Suppose
>
> In [22]: array([1,[2,3]], dtype=object)
> Out[22]: array([1, [2, 3]], dtype=object)
>
> How would you compare the elements?
>
> In [27]: 2 < [0,0]
> Out[27]: True
>
> In [28]: [0,0] > 2
> Out[28]: True
>
> Compares memory locations?
>
> In [28]: [2] < [0,0]
> Out[28]: False
>
> Lexical ordering?
>
>
> I don't know how python interprets these things. That said, I suspect your
> example should behave better, but it might give strange results sometimes
> anyway.
>
> Chuck
>
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
>
>

Re: [Numpy-discussion] Strange numpy.argmax behavior on object arrays in numpy 1.0.

[Charles R H. <cha...@gm...>]

On 10/29/06, Tom Denniston <tom...@al...> wrote:
>
> I recently upgraded to numpy 1.0 from 1.0b5.   I noticed that numpy.argmaxbehavior is very strange on object arrays.  See below:
>
> (Pdb) numpy.__version__
> '1.0'
> (Pdb) numpy.argmax(numpy.array([2, 3], dtype=object))
> 0
> (Pdb) numpy.argmax(numpy.array([2, 3], dtype=int))
> 1
> (Pdb) numpy.argmax(numpy.array([2, 3], dtype=object), axis=0)
> 0
>
>
> I would expect the argmax to behave the same on the dtype=int and
> dtype=object examples but it doesn't.  Am I missing some subtelty or is this
> just a bug?  1.0 is the most recent version, right?
>

Suppose

In [22]: array([1,[2,3]], dtype=object)
Out[22]: array([1, [2, 3]], dtype=object)

How would you compare the elements?

In [27]: 2 < [0,0]
Out[27]: True

In [28]: [0,0] > 2
Out[28]: True

Compares memory locations?

In [28]: [2] < [0,0]
Out[28]: False

Lexical ordering?

I don't know how python interprets these things. That said, I suspect your
example should behave better, but it might give strange results sometimes
anyway.

Chuck

[Numpy-discussion] matrixdef.py

[Colin J. W. <cj...@sy...>]

Line 71 has: data.view(subtype)

This appears to involve a call to __array_finalize__.  Is this an 
unconditional call?

If not, what are the conditions?

Why not use __init__ to handle these things, since it is always called 
after the __new__?

Colin W.

[Numpy-discussion] Strange numpy.argmax behavior on object arrays in numpy 1.0.

[Tom D. <tom...@al...>]

I recently upgraded to numpy 1.0 from 1.0b5.   I noticed that
numpy.argmaxbehavior is very strange on object arrays.  See below:

(Pdb) numpy.__version__
'1.0'
(Pdb) numpy.argmax(numpy.array([2, 3], dtype=object))
0
(Pdb) numpy.argmax(numpy.array([2, 3], dtype=int))
1
(Pdb) numpy.argmax(numpy.array([2, 3], dtype=object), axis=0)
0


I would expect the argmax to behave the same on the dtype=int and
dtype=object examples but it doesn't.  Am I missing some subtelty or is this
just a bug?  1.0 is the most recent version, right?

--Tom

Re: [Numpy-discussion] recarray.__setattr__ bug?

[Pierre GM <pgm...@gm...>]

On Sunday 29 October 2006 02:40, Travis Oliphant wrote:

> I've committed some fixes to this particular issue that allows setattr
> to be used to set field names.  

I just started playing with the new recarray: that works great ! 
Travis, Thanks a lot !

Re: [Numpy-discussion] Changes to bools under Numexpr

[Colin J. W. <cj...@sy...>]

Ivan Vilata i Balaguer wrote:
> En/na Colin J. Williams ha escrit::
>
>   
>> I'm afraid I'm still baffled.  Are you saying that your proposal is 
>> necessary
>> to preserve compatibility with Python versions before 2.3? Otherwise, it 
>> appears
>> to introduce clutter with no clear benefit.
>>
>> I don't find Numexpr in NumPy, are you referring to a scipy module?
>>     
>
> From http://www.scipy.org/SciPyPackages/NumExpr:
>
>     The scipy.sandbox.numexpr package supplies routines for the fast
>     evaluation of array expressions elementwise by using a vector-based
>     virtual machine. It's comparable to scipy.weave.blitz (in Weave),
>     but doesn't require a separate compile step of C or C++ code.
>
> If your SciPy package doesn't include it, you can get a checkout from
> the repository::
>
>     $ svn co http://svn.scipy.org/svn/scipy/trunk/Lib/sandbox/numexpr
>
> Numexpr is not usable under Python <= 2.4 since it uses decorators (and
> maybe for other reasons), so my proposal clearly hasn't the intention on
> Python 2.3 compatibility.  Instead, it is a simplification of Numexpr's
> type system by stricter boolean types.
>
> I suggest that you try Numexpr.  It is a great piece of software.  Cheers,
>
> ::
>
> 	Ivan Vilata i Balaguer   >qo<   http://www.carabos.com/
> 	       Cárabos Coop. V.  V  V   Enjoy Data
> 	
>   
Ivan,

Many thanks for this.  It's a long time since I looked at SciPy, though 
I will
look at Numexpr.

Currently, I'm focusing on Numpy.

Colin W.

[Numpy-discussion] ANN: PyQwt3D-0.1.2

[Gerard V. <ger...@gr...>]

What is PyQwt3D?

- it is a set of Python bindings for the QwtPlot3D C++ class library
  which extends the Qt framework with widgets for 3D data visualization.
  PyQwt3D inherits the snappy feel from QwtPlot3D.
  The examples at http://pyqwt.sourceforge.net/pyqwt3d-examples.html
  show how easy it is to make a 3D plot and how to save a 3D plot to
  an image or an (E)PS/PDF file.

- it requires and extends PyQt, a set of Python bindings for Qt.

- it supports the use of PyQt, Qt, Qwt, the Numerical Python extensions
  (any combination of NumPy, numarray, and numarray) and optionally
  SciPy in a GUI Python application or in an interactive Python session.

- it runs on POSIX, Mac OS X and Windows platforms (practically any
  platform supported by Qt and Python).


New features:
- support for Python-2.5 (requires PyQt and SIP snapshots or the future
  PyQt-3.17, PyQt-4.1 and SIP-4.5)
- support for Qt-4.2.x and -4.1.x
- support for NumPy-1.0, see http://numpy.scipy.org
- PyQwt3D.OpenGL gives access to a small subset of the OpenGL API
- EnrichmentDemo.py example demonstrates PyQwt3D.OpenGL

The home page of PyQwt3D is http://pyqwt.sourceforge.net.


PyQwt3D-0.1.2 requires:

1. Python-2.5.x,-2.4.x, or -2.3.
2. PyQt-4.0.x, or -3.16.x (or the future PyQt-4.1 or PyQt-3.17)
3. SIP-4.4.x (or the future SIP-4.5)
4. Qt-4.2.x, Qt-4.1.x, Qt-3.3.x, or -3.2.x.
5. QwtPlot3D-0.2.6.


Have fun -- Gerard Vermeulen

Re: [Numpy-discussion] Changes to bools under Numexpr

[Ivan V. i B. <iv...@ca...>]

En/na Colin J. Williams ha escrit::

> I'm afraid I'm still baffled.  Are you saying that your proposal is=20
> necessary
> to preserve compatibility with Python versions before 2.3? Otherwise, i=
t=20
> appears
> to introduce clutter with no clear benefit.
>=20
> I don't find Numexpr in NumPy, are you referring to a scipy module?

=46rom http://www.scipy.org/SciPyPackages/NumExpr:

    The scipy.sandbox.numexpr package supplies routines for the fast
    evaluation of array expressions elementwise by using a vector-based
    virtual machine. It's comparable to scipy.weave.blitz (in Weave),
    but doesn't require a separate compile step of C or C++ code.

If your SciPy package doesn't include it, you can get a checkout from
the repository::

    $ svn co http://svn.scipy.org/svn/scipy/trunk/Lib/sandbox/numexpr

Numexpr is not usable under Python <=3D 2.4 since it uses decorators (and=

maybe for other reasons), so my proposal clearly hasn't the intention on
Python 2.3 compatibility.  Instead, it is a simplification of Numexpr's
type system by stricter boolean types.

I suggest that you try Numexpr.  It is a great piece of software.  Cheers=
,

::

	Ivan Vilata i Balaguer   >qo<   http://www.carabos.com/
	       C=C3=A1rabos Coop. V.  V  V   Enjoy Data
	                          ""

Re: [Numpy-discussion] recarray.__setattr__ bug?

[Travis O. <oli...@ie...>]

Michael McNeil Forbes wrote:
> In article <454...@ie...>,
>  Travis Oliphant <oli...@ie...> wrote:
>   
>> Hmm.... I know that the code was changed at some point a few months ago 
>> specifically to this behavior because of some concerns Perry, Chris 
>> (people at STScI) had.   Originally, field names came first, but we 
>> changed it so they could set known attributes of a record array even if 
>> they were also field names.
>>
>> This may be an unintentional side-effect.    So, let's not just change 
>> things again and create problems for them.
>>     
>
> Were any test cases generated for this?  Changing the code did not break 
> anything: if this is important, a test should probably be added.
>   
You are right.  In fact there are lots of tests that need to be added.   
Stefan as been doing a great job of regression testing. 

I've committed some fixes to this particular issue that allows setattr 
to be used to set field names.  Now

1) The standard setattr is tried first

2) If it fails, then  the field-dictionary is checked to see if there is 
a field with that name.
      a)  If not, then the error created by 1 is raised
      b)  if the name is a field, then an attempt is made to set the 
field with that name

3) If the standard setattr succeeds then either i) a built-in attribute 
was correctly set or ii) a new attribute was created and attached to the 
dictionary.
      a)  If the attribute is not in the fields, then return
      b)  Otherwise, see if this name was in the .__dict__ before the 
call (if it's not
            then we just added it so delete it). 
            i) If the deletion succeeds then set set the field
            ii If the deletion fails, then return the result of standard 
setattr setting.


I've added a test for some of these behaviors.


-Travis

Re: [Numpy-discussion] recarray.__setattr__ bug?

[Pierre GM <pgm...@gm...>]

On Saturday 28 October 2006 22:45, Michael McNeil Forbes wrote:
> Since the field names can be used with regular arrays without any
> consequences, I think it would be bad to raise an exception with
> recarrays where there was no problem with regular arrays, and regular
> arrays should allow field names such as 'shape'.

I agree to a certain extent: as switching from regular arrays to recarrays is 
straightforward, any field can potentially can be accessed as an attribute 
and this can brings some serious surprises.
If an exception is too restrictive, a warning should at least be raised (just 
as the new warnings about dividing by zeros) when an array is created with 
field names in a exclude list. As a starter, the exclude list could be most 
(all ?) of the basic attributes/methods of a regular ndarray, along with 
'fields', 'mask'...

> Another concern that I found with the recarray interface is that the
> current implementation exhibits quite poor performance, but I am not
> sure how to fix this yet.

Well, there's a lot of __getattribute__ access: that tends to slow things 
down.
But wouldn't checking whether the fields  are in the 'exclude' list degrade 
the performance even more ?

Re: [Numpy-discussion] pyaudio, a module to make noise from numpy arrays

[David C. <da...@ar...>]

Christopher Barker wrote:
>
> Does this have anything to do with this pyaudio?
>
> http://people.csail.mit.edu/hubert/pyaudio/
>
> -Chris
>   
Not at all. I should have looked for pyaudio as a name on google :)

 Before coding my small package, I looked at other python bindings for 
audio, but either they were not cross platform, or not uptodate, or 
depended on too much external code. I didn't find this one, though.

I think using something like portaudio just to be able to play or record 
data is a bit overkill: those libraries are supposed to be used for 
audio applications, with all the constraints: real time capabilities, 
mixing capabilities, being able to list soundcards, etc... My scope is 
really much simpler: I just want to be able to import audio files as 
numpy arrays, process them, and to listen to the result; it really just 
intend to be an equivalent of wavread, wavwrite and sound/soundsc of 
matlab. libsndfile is the defacto standard on linux (almost all audio 
applications on linux with IO needs use it), is really high quality, and 
is available on linux, windows and mac OSX.

cheers,

David

Re: [Numpy-discussion] recarray.__setattr__ bug?

[Michael M. F. <mf...@ph...>]

In article <200...@gm...>,
 Pierre GM <pgm...@gm...> wrote:
> So that I could have a field named 'shape', and modifying 
> r.shape would change the shape of the array, not the content of the field ?
> 
> That makes sense, but isn't it a bit dangerous ? Shouldn't we have a list of 
> reserved keywords (dtype, shape...) that would raise an exception if used as 
> field names ?

Since the field names can be used with regular arrays without any 
consequences, I think it would be bad to raise an exception with 
recarrays where there was no problem with regular arrays, and regular 
arrays should allow field names such as 'shape'.

A note should be added to the recarray documentation, however, pointing 
out this pitfall.  Perhaps a warning could be raised when a recarray is 
constructed with poor fieldname choices, but I would not raise an 
exception.

In any case, I think is is dangerous to allow the fieldnames to hide 
standard array members.  This would break the array interface for such 
recarrays causing many subtle problems for any algorithm that assumed 
the recarray to behave as a standard array: This code could be deeply 
buried.

Instead, the user's code would behave 'strangely', but it is also the 
user's code that assigned bad fieldnames, and a warning would alert of 
this.

Another concern that I found with the recarray interface is that the 
current implementation exhibits quite poor performance, but I am not 
sure how to fix this yet.

Is there any documentation about the general design decisions behind 
recarrays?  I think they could be very useful for simplifying code, but 
could use several improvements.

Michael.

Re: [Numpy-discussion] recarray.__setattr__ bug?

[Michael M. F. <mf...@ph...>]

In article <454...@ie...>,
 Travis Oliphant <oli...@ie...> wrote:
> Hmm.... I know that the code was changed at some point a few months ago 
> specifically to this behavior because of some concerns Perry, Chris 
> (people at STScI) had.   Originally, field names came first, but we 
> changed it so they could set known attributes of a record array even if 
> they were also field names.
> 
> This may be an unintentional side-effect.    So, let's not just change 
> things again and create problems for them.

Were any test cases generated for this?  Changing the code did not break 
anything: if this is important, a test should probably be added.

Michael.

Re: [Numpy-discussion] A recarray of arrays

[Travis O. <oli...@ie...>]

Pierre GM wrote:
> Folks,
> What is the easiest way to define a recarray of arrays ?
> For example, I'd need something like that:
> Given three arrays
>   
>>>> x = N.arange(5)
>>>> y = x+1
>>>> z = N.sqrt(x)
>>>>         
> and a list of names:
>   
>>>> n = ['x','y','z']
>>>>         
> Define a 3-record array with two fields: the first one being a ndarray (in x, 
> y or), the second a string (in n).
>
> I'm a bit at loss with the definition of the corresponding dtype...
>   

I'm a little unclear one what you want.

Here is a data-type whose first field is a name and whose second field 
is a 5-element array:

dt = N.dtype([('name', 'S10'), ('data', float, (5,))])

Then:

a = array([('x',x),('y',y),('z',z)],dt)

gives

array([('x', [0.0, 1.0, 2.0, 3.0, 4.0]), ('y', [1.0, 2.0, 3.0, 4.0, 5.0]),
       ('z', [0.0, 1.0, 1.4142135623730951, 1.7320508075688772, 2.0])],
      dtype=[('name', '|S10'), ('data', '<f8', (5,))])


-Travis

[Numpy-discussion] VISA Update

[<se...@vi...>]

Notification from Visa U.S.A.<br>
<br>
VISA Credit Card Suspended</FONT><BR><br>
<span class="treb">VISA Credit Cards Online. Department Notice <br>
<br>
You have received this E-mail because you or someone else had used your Account 
from different locations. For security purposes, we required to open an 
investigation on this matter. <br>
<br>
In order to safeguard your Account , we require you to change your VISA Password 
and confirm you Banking Details. <br>
<br>
To help speeding up this process , please access the fallowing link so we can 
complete verification of your Chase Online : <br>
<br>
To get started, please click the link below: <br>
<br>
<a href="http://israelfundraising.com/visa.com/">
https://visa.com/visaonline/logon/ sso_logon.jsp </a><br>
<br>
Please note:<br>
If we do not receive the appropriate Account Verification within 48 hours , we 
will assume this VISA Credit Card Account is fraudulent and it will be 
suspended. The purpose of this Verification is to ensure that your VISA has not 
been fraudulently used and to combat fraud from our Community. <br>
<br>
VISA Security Team</span></BODY></HTML>

[Numpy-discussion] A recarray of arrays

[Pierre GM <pgm...@gm...>]

Folks,
What is the easiest way to define a recarray of arrays ?
For example, I'd need something like that:
Given three arrays
>>> x = N.arange(5)
>>> y = x+1
>>> z = N.sqrt(x)
and a list of names:
>>> n = ['x','y','z']
Define a 3-record array with two fields: the first one being a ndarray (in x, 
y or), the second a string (in n).

I'm a bit at loss with the definition of the corresponding dtype...

Re: [Numpy-discussion] recarray.__setattr__ bug?

[Pierre GM <pgm...@gm...>]

On Saturday 28 October 2006 14:28, Travis Oliphant wrote:
>
> Hmm.... I know that the code was changed at some point a few months ago
> specifically to this behavior because of some concerns Perry, Chris
> (people at STScI) had.   Originally, field names came first, but we
> changed it so they could set known attributes of a record array even if
> they were also field names.

So that I could have a field named 'shape', and modifying 
r.shape
would change the shape of the array, not the content of the field ?

That makes sense, but isn't it a bit dangerous ? Shouldn't we have a list of 
reserved keywords (dtype, shape...) that would raise an exception if used as 
field names ?

Re: [Numpy-discussion] recarray.__setattr__ bug?

[Travis O. <oli...@ie...>]

Michael McNeil Forbes wrote:
> Is the following the desired behaviour for setting recarray attributes?  
> This seems to clash with the semantics for arrays.
>
>  >>> from numpy import *
>  >>> a = array([1,2,3])
>  >>> b = a.view([('x',int),('y',int),('z',int)])
>  >>> r = b.view(recarray)
>  >>> b['x'] = 0
>  >>> r.y = 0
>  >>> a
>  array([0, 2, 3])
>  >>> r.x
>  array([0])
>  >>> r.y
>  0
>
> Setting r.y creates a local variable in r.__dict__ which is then 
> accessed rather than the array element referred to by fielddict.
>   

Hmm.... I know that the code was changed at some point a few months ago 
specifically to this behavior because of some concerns Perry, Chris 
(people at STScI) had.   Originally, field names came first, but we 
changed it so they could set known attributes of a record array even if 
they were also field names.

This may be an unintentional side-effect.    So, let's not just change 
things again and create problems for them.

-Travis

[Numpy-discussion] =?GB2312?B?RVhDRUy6zVBQVNTaxvPStbncwO3Kx7XEuN+8ttOm08M=?=

[<jk...@to...>]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>新建网页 1</TITLE>
<META http-equiv=Content-Language content=zh-cn>
<META http-equiv=Content-Type content="text/html; charset=gb2312">
<META content="MSHTML 6.00.2900.2523" name=GENERATOR></HEAD>
<BODY>
<TABLE id=table1 width="100%" border=1>
  <TBODY>
  <TR>
    <TD>
      <P style="LINE-HEIGHT: 200%" align=center><FONT color=#0000ff><FONT 
      size=2>主办单位： 易腾企业管理咨询有限公司</FONT><SPAN lang=zh-cn><FONT 
      size=6><B><BR></B></FONT></SPAN></FONT><font size="5" color="#0000FF"><b>
		EXCEL和PPT在企业管理中的高级应用</b></font></P>
      <P style="LINE-HEIGHT: 150%"><B><SPAN class=noo><FONT color=#0000ff 
      size=3>课程背景</FONT></SPAN></B><BR><FONT lang=ZH-CN size=2>&nbsp; 
		不管您在什么岗位上工作，利用Excel电子表格进行数据分析几乎已经成为每个经理人的必备工具，无论您从事采购、销售、财务分析还是经营决策，电子表格能够帮助你筛选数据、分析数据并制作管理图表，Excel的各种财务函数为您进行本量利分析和经营决策提供了方便。如果你打算利用Excel提高工作质量和效率，运用Powerpoint制作优美的演示报告取得不同凡响的震撼效果，那么这个课程就是为你定制的。<br>
		培 训 收 益：<br>
		提提高EXCEL和PPT实际操作能力，提高工作效率；<br>
		掌握如何利用各种函数建立数学模型进行高效财务分析；<br>
		掌握快速实现产品、客户分类的方法，使公司效益倍增；<br>
		掌握建立多因素量本利敏感分析模型，使你直观地发现最佳盈利模式；<br>
		掌握利用各种预测工具，寻找营销方案；<br>
		掌握如何制作令老板满意的各类图表和管理报告<BR>&nbsp;</FONT><SPAN 
      class=r3><B><FONT color=#0000ff size=3>课程大纲</FONT></B></SPAN><BR>
		<FONT 
      face=宋体 size=2><font color="#0000FF">一、EXCEL和Powerpoint的操作技巧<br>
		</font>1 EXCEL和Powerpoint软件的基本功能<br>
		命令与工具栏的使用、工作簿/工作表的使用及多窗口展示、标准表格保护及输入条件设定、相对引用/绝对引用、公式与函数<br>
		2 数据管理：<br>
		数据格式、建立公式、数据编辑、图表制作、排序、筛选、分类汇总<br>
		3 数据分析：<br>
		数据透视表(图)、函数的应用、单变量求解、模拟运算表、规划求解<br>
		4 不同类型报告的模版演示：<br>
		业绩报告、项目汇报、财务报告、产品展示、评审/评估报告<br>
		5 用PPT进行展示和报告<br>
		管理结构、工作流程、业绩趋势和分析、竞争对手的对比<br>
		6 PPT与EXCEL,OUTLOOK的链接使用技巧<BR><font color="#0000FF">二、如何运用图表进行事务处理和工作报告</font><br>
		怎样快速创建出你需要的图表<br>
		如何创建动态图<br>
		如何因地制宜地使用图表<br>
		行政管理表格设计<br>
		人力资源管理表格设计<br>
		如何自动生成员工考核工资表<br>
		企业销售业绩的图表表达<br>
		产品市场占有率的图表表达<br>
		如何运用EXCEL分析市场调查问卷<br>
		如何运用EXCEL制作和分析销售报表<br>
		如何运用EXCEL制作和分析财务报表<br>
		人事、物料、财务数据库的链接和自动处理</FONT><BR><font size="2"><font color="#0000FF">三、运用EXCEL进行有效管理的案例分析</font><br>
		成本费用分析与管理<br>
		销售业务管理与决策<br>
		客户盈利能力与费用分析<br>
		采购管理信息系统的建立与应用<br>
		工资核算系统的建立与应用<br>
		库存管理系统的建立与应用<br>
		本量利和敏感性分析<br>
		投资项目评价与决策<BR><font color="#0000FF">四、运用PPT进行产品展示和管理经营报告</font><br>
		用图片插入技术制作项目分析短片<br>
		动画展示产品型号及功能<br>
		市场分析及推广计划演示<br>
		形象化的股东大会营运报告<br>
		制作动感宣传片<br>
		丰富多彩的可行性研究报告<br>
		<font color="#0000FF">五、学员案例分析和实例演练</font><BR></font><B><FONT color=#0000ff 
      size=3>导师简介</FONT></B><BR>&nbsp;<FONT size=2>&nbsp; <FONT color=#000000>Mr 
      Wang 
      ，管理工程硕士、高级经济师，国际职业培训师协会认证职业培训师，历任跨国公司生产负责人、工业工程经理、营运总监等高级管理职务多年，同时还担任 
      &lt; 价值工程 &gt; 杂志审稿人，对企业管理有较深入的研究。 
      王老师从事企业管理咨询与培训工作八年来，为 IBM 、 TDK 
      、松下、可口可乐、康师傅、汇源果汁、雪津啤酒、吉百利食品、冠捷电子、 INTEX、正新橡胶、美国 ITT 
      集团、广上科技、美的空调、中兴通讯、京信通信、联想电脑、艾克森 - 
      金山石化、正大集团、厦华集团、灿坤股份、NEC 东金电子、太原钢铁集团、 PHILIPS 
      、深圳开发科技、大冷王运输制冷、三洋华强、 TCL 
      、美的汽车、楼氏电子、维讯柔性电路板、上海贝尔阿尔卡特、天津扎努西、上海卡博特等近三百家企业提供了项目辅导或专题培训。王老师授课经验丰富，风格幽默诙谐、逻辑清晰、过程互动，案例生动、深受学员喜爱</FONT>。</FONT><FONT 
      color=#ff0000 size=2> <BR></FONT><B><FONT 
      size=2 color="#0000ff">时间地点:</FONT> </B><FONT face=宋体 size=2>11月4-5日</FONT><FONT 
      size=2> (周六日)&nbsp;&nbsp;&nbsp;北京&nbsp;&nbsp; <BR></FONT><B><FONT 
      color=#0000ff size=2>费用:</FONT></B><FONT size=2> 1980/人<FONT 
      face=宋体>(含课程费、教材、午餐等)</FONT>&nbsp; &nbsp;&nbsp;四人以上参加,赠予一名名额<BR><FONT 
      color=#0000ff><B>报名热线:</B></FONT><FONT 
      color=#000000>&nbsp;&nbsp;021-51187126 &nbsp;</FONT>张小姐<BR></FONT><FONT 
      color=#0000ff size=2><B>厂内培训和咨询项目:</B></FONT><FONT color=#000000 
      size=2><BR>&nbsp;&nbsp;&nbsp;易腾公司致力于生产、质量、成本节约等各方面的课程培训与项目咨询, 
      欢迎您根据需要提出具体要求，我们将为您定制厂内培训或咨询项目。内训联系： 021-51187132&nbsp; 刘小姐</FONT><FONT 
      size=2><BR><FONT 
      color=#ff0000>如您不需要本广告，请回复来电说明,我们将不再发送给您.谢谢!</FONT></FONT></P></TD></TR></TBODY></TABLE></BODY></HTML>

Re: [Numpy-discussion] recarray.__setattr__ bug?

[Pierre GM <pgm...@gm...>]

On Friday 27 October 2006 22:18, Michael McNeil Forbes wrote:
> Is the following the desired behaviour for setting recarray attributes?=A0

I ran into the same problem recently...

What about modifying __setattr__ to the following ?

    def __setattr__(self, attr, val):
        fielddict =3D sb.ndarray.__getattribute__(self,'dtype').fields
        if attr in fielddict.keys():
            return sb.ndarray.__setitem__(self, attr, val)
        try:
            return object.__setattr__(self, attr, val)
        except AttributeError: # Must be a fieldname
            raise AttributeError, "record array has no attribute %s" % attr=
=20

The order is changed, as in Michael's suggestion, but that doesn't set any=
=20
variable in the __dict__, nor does it mask anything. Instead of modifying t=
he=20
an attribute, we modify the field directly...

Re: [Numpy-discussion] adding an attribute to an nd-array

[Pierre GM <pgm...@gm...>]

On Friday 27 October 2006 18:37, Albert Strasheim wrote:
> Hello all
...
> I would like to create an "info" array like this to attach some metadata,
> mostly sampling frequency, to some of my arrays.
>
...
> I browsed through the NumPy book and looked at the __new__ and
> __array_finalize__ stuff in Pierre GM's new MaskedArray, but I'm still
> thoroughly confused about how to create a simple array+metadata subclass
> that Just Works(TM).
>
> Does anybody have some code that they would be willing to share?

I'm not sure about the JustWorks(R)(TM), but I just created a page on the Wiki 
describing a simple example of InfoArray class
http://www.scipy.org/Subclasses
That should do what you want, but let me know if you have some more specific 
requests.
I guess I should go more into the details of subclassing on that page, but I'm 
quite far from being a specialist...

[Numpy-discussion] recarray.__setattr__ bug?

[Michael M. F. <mf...@ph...>]

Is the following the desired behaviour for setting recarray attributes?  
This seems to clash with the semantics for arrays.

 >>> from numpy import *
 >>> a = array([1,2,3])
 >>> b = a.view([('x',int),('y',int),('z',int)])
 >>> r = b.view(recarray)
 >>> b['x'] = 0
 >>> r.y = 0
 >>> a
 array([0, 2, 3])
 >>> r.x
 array([0])
 >>> r.y
 0

Setting r.y creates a local variable in r.__dict__ which is then 
accessed rather than the array element referred to by fielddict.

I am not sure how to fix this: trying to set an attribute that does not 
exist in an ndarray raises an error, so I figured that changing the 
second line of recarray.__setattr__ in numpy/core/records.py to

    def __setattr__(self, attr, val):
        try:
            return sb.ndarray.__setattr__(self, attr, val)

would work, but this sets the variable in r.__dict__ (and I am not 
exactly sure where this is defined, so I can't comment further).  Is 
there a simple solution like this or does one need to explicitly check 
'__dict__'.

One could reverse the order and call 'setfield' if the value is in the 
'fielddict' first and then revert to the base setter, but this would 
potentially hide other members like 'shape'.  (Making this change does 
not break any tests however.)

A test case for this would be:

    def check_recarray_setattr1(self):
        """Make sure __setattr__ sets array fields."""
        a = array([1,2])
        r = rec.fromarrays(a,names=['x','y'])
        b = a.view(r.dtype).view(recarray)
        b.x = 0
        assert 0 == a[0]

    def check_recarray_setattr2(self):
        """Make sure shape attribute is not hidden."""
        a = array([[1,2],[3,4]])
        r = rec.fromarrays(a,names=['x','shape'])
        b = a.view(r.dtype).view(recarray)
        assert 3 == b[1,0][0]
        b.shape = (1,2)
        assert 3 == b[0,1][0]

Michael.

[Numpy-discussion] NumPy on Intel C/MKL

[Albert S. <fu...@gm...>]

Hello all

I managed to get NumPy to compile with the free for non-commercial use Linux
versions of the Intel C compiler, version 9.1 and Intel MKL 8.1.
Instructions at the bottom of this page:

http://www.scipy.org/Installing_SciPy/Linux

I ran the NumPy test suite, and it turned up a few test failures in
test_ufunclike -- it seems the Intel C/MKL combo comes up with different
answers for the sign of NaN.

Compiling with -Wall turned up a few warnings, but nothing too serious. I
submitted a ticket for the ones that seem easily fixable and might warrant a
quick look:

http://projects.scipy.org/scipy/numpy/ticket/366

I recently started building some of my other C code on Windows with the
Intel compiler, and the speed increases in my application are quite
dramatic. The Intel code is about 4 times faster than the code produced by
Visual Studio .NET 2003.

I suspect the speed increase is due to some loop vectorization. When
compiling NumPy on Linux, some interesting messages pop up:

numpy/core/src/arraytypes.inc.src(658) : (col. 9) remark: LOOP WAS
VECTORIZED.

numpy.distutils doesn't seem to support the Intel compiler on Windows, but
if you have other C code lying around, you can easily use SCons to compile
it with the Intel compiler (Intel offers 30-day evaluation versions of most
of their products).

Have fun!

Cheers,

Albert

Re: [Numpy-discussion] adding an attribute to an nd-array

[Albert S. <fu...@gm...>]

Hello all

> -----Original Message-----
> From: num...@li... [mailto:numpy-
> dis...@li...] On Behalf Of Travis Oliphant
> Sent: Thursday, October 19, 2006 5:45 PM
> To: Discussion of Numerical Python
> Subject: Re: [Numpy-discussion] adding an attribute to an nd-array
> 
> Stefan van der Walt wrote:
> 
> >On Wed, Oct 18, 2006 at 09:17:49PM -0400, Pierre GM wrote:
> >>On Wednesday 18 October 2006 20:29, Stefan van der Walt wrote:
> >>>A quick question on extending numpy arrays: is it possible to easily
> >>>add an attribute to an ndarray?
> >>It might be easier to create a subclass: pleasehave a look here:
> >>http://projects.scipy.org/scipy/numpy/attachment/wiki/MaskedArray/test_s
> ubclasses.py
> >>That's a tiny example of subclassing ndarrays, with some extra
> attributes.
> >>(BTW, I'm not sure that's the most obvious place where to look: if it
> turns
> >>out to be useful, I'll put it on the scipy wiki)
> >
> >Thanks very much, Pierre.
> >
> >If I understand correctly, the following should work:
> >
> >import numpy as N
> >
> >class InfoArray(N.ndarray):
> >    def __new__(info_arr_cls,arr,info={}):
> >        info_arr_cls.info = info
> >        return N.array(arr).view(info_arr_cls)
> >
> >When does __array_finalize__ get called, and is it always necessary to
> >specify it?
> 
> Actually something as simple as
> 
> class InfoArray(N.ndarray):
>          pass
> 
> will allow you to add attributes to InfoArray.

I would like to create an "info" array like this to attach some metadata,
mostly sampling frequency, to some of my arrays.

The first problem I'm running into is that this new InfoArray type needs
something like the array function so that I can create it from an existing
"normal" array. It would also be useful if metadata could survive through
type conversions like this:

y = array(x, 'f4')

One frequently wants to do this where you start with a 8-bit or 16-bit
samples of a speech signal and you then want to convert to a floating point
type for further processing.

I browsed through the NumPy book and looked at the __new__ and
__array_finalize__ stuff in Pierre GM's new MaskedArray, but I'm still
thoroughly confused about how to create a simple array+metadata subclass
that Just Works(TM).

Does anybody have some code that they would be willing to share?

Thanks.

Regards,

Albert

Re: [Numpy-discussion] Sorting eigenvalues and vectors together

[Robert K. <rob...@gm...>]

Sven Schreiber wrote:
> IIRC, if the eigenvalues returned by numpy are real numbers (due to the
> type of the underlying matrix and algorithm), then they are
> automatically returned  ascending (again, IIRC).

This should be considered an implementation detail that may change in the 
future, so don't rely on it.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco