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: <te...@16...> - 2006-07-02 03:44:42
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<title>无标题文档</title>
<style type="text/css">
<!--
.td {
font-size: 12px;
color: #313131;
line-height: 20px;
font-family: "Arial", "Helvetica", "sans-serif";
}
-->
</style>
</head>
<body leftmargin="0" background="http://bo.sohu.com//images/img20040502/dj_bg.gif">
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td height="31" background="http://igame.sina.com.cn/club/images/topmenu/topMenu_8.gif" class="td"><div align="center"><font color="#FFFFFF">主办单位：
易腾企业管理咨询有限公司</font></div></td>
</tr>
</table>
<br>
<table width="684" border="0" align="center" cellpadding="0" cellspacing="0" height="1287">
<tr>
<td height="71" bgcolor="#8C8C8C">
<div align="center">
<table width="100%" border="0" cellspacing="1" cellpadding="0" height="76">
<tr>
<td height="74" bgcolor="#F3F3F3"><div align="center">
<span lang="zh-cn"><font size="6" color="#000080">
运用EXCEL改进财务管理和市场营销</font></span></div></td>
</tr>
</table>
</div></td>
</tr>
<tr>
<td height="1211" bgcolor="#FFFFFF"> <div align="center">
<table width="99%" border="0" cellspacing="0" cellpadding="0" height="48">
<tr>
<td width="17%" height="22" bgcolor="#BF0000" class="td">
<div align="center"><font color="#FFFFFF">[课 程 背 景]</font></div></td>
<td width="83%" class="td" height="22"> </td>
</tr>
<tr>
<td height="26" colspan="2" class="td">
<p ALIGN="JUSTIFY"><font LANG="ZH-CN">
</font><font color="#000000" size="2">
不管您在什么岗位上工作，利用Excel电子表格进行数据分析几乎已经成为每个经理人的必备工具，尤其是在财务和营销管理上，电子表格能够帮助你筛选数据、分析数据并制作管理图表。如果你打算利用Excel提高工作质量和效率，那么这个课程就是为你定制的。<br>
</font><b><font color="#ff0000" size="2">培 训 收 益：</font></b><font color="#000000" size="2"><br>
提高EXCEL实际操作能力，提高工作效率；<br>
掌握如何利用各种函数建立数学模型进行高效财务分析；<br>
掌握快速实现产品、客户分类的方法，使公司效益倍增；<br>
掌握建立多因素量本利敏感分析模型，使你直观地发现最佳盈利模式；<br>
掌握利用各种预测工具，寻找营销方案；<br>
掌握如何制作令老板满意的各类图表</font><font LANG="ZH-CN"><font size="2"><span style="mso-bidi-font-size: 9.0pt; 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></font> </font></td>
</tr>
</table>
</div>
<div align="center" style="width: 671; height: 1"> </div>
<div align="center">
<table width="99%" height="84" border="0" cellpadding="0" cellspacing="0">
<tr>
<td width="17%" height="20" bgcolor="#0080C0" class="td"> <div align="center"><font color="#FFFFFF">[课
程 大 纲]</font></div></td>
<td width="83%" class="td"> </td>
</tr>
<tr>
<td height="64" colspan="2" class="td"> <p>
<font color="#FF0000">
<span style="font-size: 10.0pt; font-family: 宋体">一、<span style="font-family:宋体; font-size:10.0pt">EXC</span>EL<span style="font-family: 宋体; font-size:10.0pt">操作技巧</span></span></font><span lang="EN-US"><br>
</span><span style="font-size: 10.0pt; font-family: 宋体">数据处理：</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span style="font-size: 10.0pt; font-family: 宋体">
数据输入、数据格式、建立公式、数据编辑、调用函数（基本函数、逻辑、统计、数据库、财务类等）、图表制作</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span style="font-size: 10.0pt; font-family: 宋体">数据管理：</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span style="font-size: 10.0pt; font-family: 宋体">
排序、筛选、记录单、分类汇总</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span style="font-size: 10.0pt; font-family: 宋体">数据分析：</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span style="font-size: 10.0pt; font-family: 宋体">数据透视表</span><span lang="EN-US" style="font-size:10.0pt">(</span><span style="font-size: 10.0pt; font-family: 宋体">图</span><span lang="EN-US" style="font-size:10.0pt">)</span><span style="font-size: 10.0pt; font-family: 宋体">、数据敏感分析、单变量求解、模拟运算表、方案管理器、规划求解</span><span lang="EN-US"><br>
<br>
</span><span style="font-family: 宋体; font-size:10.0pt">
<font color="#FF0000">二、如何运用图表进行行政事务处理和工作报告</font></span><span lang="EN-US"><br>
</span><span style="font-size: 10.0pt; font-family: 宋体">
怎样快速创建出你需要的图表</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span style="font-size: 10.0pt; font-family: 宋体">如何创建动态图</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span style="font-size: 10.0pt; font-family: 宋体">如何因地制宜地使用图表</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span style="font-size: 10.0pt; font-family: 宋体">行政管理表格设计</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span style="font-size: 10.0pt; font-family: 宋体">人力资源管理表格设计</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span style="font-size: 10.0pt; font-family: 宋体">
如何自动生成员工考核工资表</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span style="font-size: 10.0pt; font-family: 宋体">企业销售业绩的图表表达</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span style="font-size: 10.0pt; font-family: 宋体">产品市场占有率的图表表达</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span style="font-size: 10.0pt; font-family: 宋体">如何运用</span><span lang="EN-US" style="font-size:10.0pt">EXCEL</span><span style="font-size: 10.0pt; font-family: 宋体">分析市场调查问卷</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span style="font-size: 10.0pt; font-family: 宋体">如何运用</span><span lang="EN-US" style="font-size:10.0pt">EXCEL</span><span style="font-size: 10.0pt; font-family: 宋体">制作和分析销售报表</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span style="font-size: 10.0pt; font-family: 宋体">如何运用</span><span lang="EN-US" style="font-size:10.0pt">EXCEL</span><span style="font-size: 10.0pt; font-family: 宋体">制作和分析财务报表</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span style="font-size: 10.0pt; font-family: 宋体">
人事、物料、财务数据库的链接和自动处理</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span lang="EN-US"><br>
</span><font color="#FF0000">
<span style="font-family: 宋体; font-size: 10.0pt">三、如何运用EXCEL进行销售和财务管理</span></font><span lang="EN-US"><br>
</span><span style="font-size: 10.0pt; font-family: 宋体">成本费用分析与管理</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span style="font-size: 10.0pt; font-family: 宋体">销售业务管理与决策</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span style="font-size: 10.0pt; font-family: 宋体">动态本量利模型分析</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span style="font-size: 10.0pt; font-family: 宋体">固定资产折旧计算</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span style="font-size: 10.0pt; font-family: 宋体">工资及个人所得税计算</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span style="font-size: 10.0pt; font-family: 宋体">
现金日报及现金流量表的编制</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span style="font-size: 10.0pt; font-family: 宋体">
由资产负债表自动生成现金流量表</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span style="font-size: 10.0pt; font-family: 宋体">
工资、固定资产投资、折旧方案筛选等实际运用模板建立和应用分析</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span style="font-size: 10.0pt; font-family: 宋体">
量本利分析、回归分析、方案预测、销售客户产品分析等实战演练</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span style="font-size: 10.0pt; font-family: 宋体">
定性指标的定量化分析技术应用的模拟演练</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span style="font-size: 10.0pt; font-family: 宋体">
运用数据透视表（图）进行经营分析的分析思路和模拟演练</span><span lang="EN-US" style="font-size: 10.0pt"><br>
</span><span style="font-size: 10.0pt; font-family: 宋体">投资项目评价与决策<br>
<br>
<font color="#FF0000">四、公司实际案例分析与演练</font></span></p></td>
</tr>
</table>
<table width="99%" height="84" border="0" cellpadding="0" cellspacing="0">
<tr>
<td width="17%" height="20" bgcolor="#0080C0" class="td">
<div align="center"><font color="#FFFFFF">[导 师 简 介]</font></div></td>
<td width="83%" class="td"> </td>
</tr>
<tr>
<td height="64" colspan="2" class="td"> <p>
<font color="#FF0000"> </font><font color="#000000">
<font color="#ff0000">Mr Wang </font>
，管理工程硕士、高级经济师，国际职业培训师协会认证职业培训师，历任跨国公司生产负责人、工业工程经理、管理会计分析师、营运总监等高级管理职务多年，同时还担任
< 价值工程 > 杂志审稿人、辽宁省营口市商业银行独立董事等职务，对企业管理有较深入的研究。
王老师主要从事成本控制、财务管理、管理会计决策等课程的讲授，为 IBM 、 TDK
、松下、可口可乐、康师傅、汇源果汁、雪津啤酒、吉百利食品、冠捷电子、 INTEX 明达塑胶、正新橡胶、美国 ITT
集团、广上科技、美的空调、中兴通讯、京信通信、联想电脑，应用材料 ( 中国 ) 公司、艾克森 -
金山石化、中国化工进出口公司、正大集团大福饲料、厦华集团、灿坤股份、NEC 东金电子、太原钢铁集团、 PHILIPS
、深圳开发科技、大冷王运输制冷、三洋华强、 TCL
、美的汽车、上海贝尔阿尔卡特、天津扎努西、上海卡博特等知名企业提供项目辅导或专题培训。王老师授课经验丰富，风格幽默诙谐、逻辑清晰、过程互动，案例生动、深受学员喜爱</font>。<font color="#FF0000"> </font>
</p></td>
</tr>
</table>
</div>
<div align="center">
<table width="669" border="0" cellpadding="0" cellspacing="0" height="57">
<tr>
<td width="132" height="26" bgcolor="#0080C0" class="td"> <div align="center"><font color="#FFFFFF">[时间/地点/联系方式]</font></div></td>
<td width="536" class="td" height="26"> </td>
</tr>
<tr>
<td height="31" colspan="2" class="td" width="669">
<p><b> </b><font size="2"><b>时间: </b>7月15-16日（周六/日）<b> 地点: </b></font>
上海
<font size="2"><b> </b>1980元/人 四人以上参加，赠送一名名额</font>
</p>
</td>
</tr>
</table>
</div>
<table width="99%" height="51" border="0" align="center" cellpadding="0" cellspacing="0">
<tr>
<td height="51" class="td"> <font size="2"><b> 电话：<</b>0 2 1 - 5 1 1 8 7 1 2 6
>
谢小姐 注:如您不需要此邮件,请回信
ts...@to...并在标题注明订退</font></td>
</tr>
</table> </td>
</tr>
</table>
</body>
</html>
|
|
From: Travis O. <oli...@ie...> - 2006-07-02 03:20:00
|
I've been playing a bit with ctypes and realized that with a little help, it could be made much easier to interface with NumPy arrays. Thus, I added a ctypes attribute to the NumPy array. If ctypes is installed, this attribute returns a "conversion" object otherwise an AttributeError is raised. The ctypes-conversion object has attributes which return c_types aware objects so that the information can be passed directly to c-code (as an integer, the number of dimensions can already be passed using c-types). The information available and it's corresponding c_type is data - c_void_p shape, strides - c_int * nd or c_long * nd or c_longlong * nd depending on platform -Travis |
|
From: Travis O. <oli...@ie...> - 2006-07-02 03:14:30
|
Is anybody else having trouble connecting to the SciPy SVN server? It just started failing with could not connect to server errors in the last hour. -Travis |
|
From: Tim H. <tim...@co...> - 2006-07-01 23:34:37
|
Sasha wrote:
> I don't see how that will simplify the transition. Convertcode will
> still need to detect use of the dtype argument (keyword or
> positional). Simple s/zeros/int.zeros/ will not work. I read Ed's
> suggestion as retaining current default in intzeros so that
> intzeros(n, float) is valid. On the other hand Tim's int.zeros would
> not take dtype argument because dtype is already bound as self.
>
It's just like a game of telephone! That was Robert's suggestion not
mine. What I said was:
Personally, given no other constraints, I would probably just get
rid of the defaults all together and make the user choose.
Since I've been dragged back into this again let me make a quick
comment. If we are choosing a floating point default, there are at least
two other choices that make as much sense as using float64. The first
possibility is to use the same thing that python uses, that is 'float'.
On my box and probably most current boxes that turns out to be float64
anyway, but choosing 'float' as the default rather than 'float64' will
change the way numpy is expected to behave as hardware and / or Python
evolves. The second choice is to use the longest floating point type
available on a given platform, that is, 'longfloat'. Again, on my box
that is the same as using float64, but on other boxes I suspect it gives
somewhat different results.
The advantage of using 'float64' as the default is that we can expect
programs to run consistently across platforms. The advantage of choosing
'float' is that interactions with Python proper may be less suprising
when python's float is not 'float64. The advantage of using 'longfloat'
is that it is the safest type to use when interacting with other unknown
types.
I don't care much which gets chosen, but I think we should know which of
these we intend and why. Since there often the same thing at present I
have a suspicion that these three cases may be conflated in some people
heads.
-tim
> The bottom line: int.zeros will not work and intzeros(n, float) is
> ugly. I would not mind oldnumeric.zeros, but context aware convertcode
> is still worth the effort. Let's see how far I will get with that ...
>
>
>
> On 7/1/06, Alan G Isaac <ai...@am...> wrote:
>
>> On Sat, 1 Jul 2006, Ed Schofield apparently wrote:
>>
>>> couldn't we make the transition easier and more robust by
>>> writing compatibility interfaces for zeros, ones, empty,
>>> called e.g. intzeros, intones, intempty
>>>
>> I think Robert or Tim suggested int.zeros() etc.
>>
>> fwiw,
>> Alan Isaac
>>
>>
>>
>>
>>
>> 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
>>
>>
>
> 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
>
>
>
|
|
From: Sasha <nd...@ma...> - 2006-07-01 20:28:13
|
I don't see how that will simplify the transition. Convertcode will still need to detect use of the dtype argument (keyword or positional). Simple s/zeros/int.zeros/ will not work. I read Ed's suggestion as retaining current default in intzeros so that intzeros(n, float) is valid. On the other hand Tim's int.zeros would not take dtype argument because dtype is already bound as self. The bottom line: int.zeros will not work and intzeros(n, float) is ugly. I would not mind oldnumeric.zeros, but context aware convertcode is still worth the effort. Let's see how far I will get with that ... On 7/1/06, Alan G Isaac <ai...@am...> wrote: > On Sat, 1 Jul 2006, Ed Schofield apparently wrote: > > couldn't we make the transition easier and more robust by > > writing compatibility interfaces for zeros, ones, empty, > > called e.g. intzeros, intones, intempty > > > I think Robert or Tim suggested int.zeros() etc. > > fwiw, > Alan Isaac > > > > > > 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 > |
|
From: Sasha <nd...@ma...> - 2006-07-01 20:07:41
|
On 7/1/06, Robert Kern <rob...@gm...> wrote: > ... > I strongly believe that we need to be using whatever build system is the > standard for Python packages. I'm happy to see distutils go away in favor of > something better, but that "something better" needs to be actively promoted as > *the* replacement for distutils for *all* Python packages, not just numpy. > I strongly agree. Distutils is in such a bad shape partially because extension packages either not use distutils or extend distutils in non-standard ways. Python-dev is not an easy crowd to deal with, but in the long run investing effort in improving core distutils will pay off. |
|
From: Robert K. <rob...@gm...> - 2006-07-01 19:45:16
|
Albert Strasheim wrote: > I'd like to take a stab at doing something with SCons in a few weeks' time. > Does anybody want to brainstorm on some ideas for what is needed from a > better build system for NumPy? Maybe a wiki page? I strongly believe that we need to be using whatever build system is the standard for Python packages. I'm happy to see distutils go away in favor of something better, but that "something better" needs to be actively promoted as *the* replacement for distutils for *all* Python packages, not just numpy. -- 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 |
|
From: Albert S. <fu...@gm...> - 2006-07-01 19:37:34
|
Hey Chuck > -----Original Message----- > From: num...@li... [mailto:numpy- > dis...@li...] On Behalf Of Charles R Harris > Sent: 01 July 2006 19:57 > To: Robert Kern > Cc: num...@li... > Subject: Re: [Numpy-discussion] Time for beta1 of NumPy 1.0 > > All, > > This is bit off topic, but a while ago there were some complaints about > the usefulness of distutils. I note that KDE has gone over to using cmake > after trying scon. I am not familiar with cmake, but perhaps someone here > knows more and can comment on its suitability. CMake definately warrants investigation, but I think SCons might be a better way to go. I think it would make it easier to reuse large parts of the existing build code (e.g. conv_template.py could be converted into a SCons builder without too much effort). Reusing parts of distutils and setuptools would also be easier if the new tool is somehow Python-aware. I think the main problem with distutils in the NumPy context is that it was never designed to build C/Fortran code over so many platforms with to many possible build configurations. python setup.py install works pretty well, but any kind of non-default configuration can become a bit hairy, despite the excellent work on NumPy extensions to distutils. I'd like to take a stab at doing something with SCons in a few weeks' time. Does anybody want to brainstorm on some ideas for what is needed from a better build system for NumPy? Maybe a wiki page? Regards, Albert |
|
From: Robert K. <rob...@gm...> - 2006-07-01 19:36:34
|
Travis Oliphant wrote: > Charles R Harris wrote: >> Thanks Travis, >> >> Your directions are very helpful and much appreciated. > I placed these instructions at > > http://projects.scipy.org/scipy/numpy/wiki/MakingBranches > > Please make any changes needed to that wiki page. I will add (here as well as the wiki) that using the svnmerge tool to be enormously helpful in maintaining branches. http://www.dellroad.org/svnmerge/index Among other things, it makes merge commit messages with the contents of the individual commit messages, so history isn't lost when changes are merged back into the trunk. Here is how I tend to set things up for bidirectional merging: (untested with this specific example, though) $ cd ~/svn/scipy $ svn cp http://svn.scipy.org/svn/scipy/trunk http://svn.scipy.org/svn/scipy/branches/mine $ svnmerge init http://svn.scipy.org/svn/scipy/branches/mine $ svn commit -F svnmerge-commit-message.txt $ svn switch http://svn.scipy.org/svn/scipy/branches/mine $ svnmerge init http://svn.scipy.org/svn/scipy/trunk $ svn commit -F svnmerge-commit-message.txt Then, when you need to pull in changes from the trunk, view them with $ svnmerge avail and pull them in with $ svnmerge merge $ svn ci -F svnmerge-commit-message.txt When you're finally done with the branch, the same procedure on the trunk pulls in all of the (real, not merged in from the trunk) changes you've made to the branch. Also, if you're only going to be making changes in one directory, I've found that it's much easier to simply branch that directory and svn switch just that directory over. That way, you don't have to worry about pulling in everyone else's changes to the rest of the package into the branch. You can just svn up. -- 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 |
|
From: Robert K. <rob...@gm...> - 2006-07-01 19:19:15
|
Charles R Harris wrote: > All, > > This is bit off topic, but a while ago there were some complaints about > the usefulness of distutils. I note that KDE has gone over to using > cmake after trying scon. I am not familiar with cmake, but perhaps > someone here knows more and can comment on its suitability. None at all. I have nightmares about it every time I need to rebuild VTK. -- 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 |
|
From: Travis O. <oli...@ie...> - 2006-07-01 18:53:45
|
Charles R Harris wrote: > Thanks Travis, > > Your directions are very helpful and much appreciated. I placed these instructions at http://projects.scipy.org/scipy/numpy/wiki/MakingBranches Please make any changes needed to that wiki page. -Travis |
|
From: Charles R H. <cha...@gm...> - 2006-07-01 18:50:12
|
Thanks Travis, Your directions are very helpful and much appreciated. Chuck On 7/1/06, Travis Oliphant <oli...@ie...> wrote: > > Charles R Harris wrote: > > > > > > On 6/30/06, *Robert Kern* <rob...@gm... > > <mailto:rob...@gm...>> wrote: > > > > Travis Oliphant wrote: > > > > > Comments? > > > > Whatever else you do, leave arange() alone. It should never have > > accepted floats > > in the first place. > > > > > > Hear, hear. Using floats in arange is a lousy temptation that must be > > avoided. Apart from that I think that making float64 the default for > > most things is the right way to go. Numpy is primarily for numeric > > computation, and numeric computation is primarily in float64. > > Specialist areas like imaging can be dealt with as special cases. > > > > BTW, can someone suggest the best way to put new code into Numpy at > > this point? Is there a test branch of some sort? > My favorite is to make changes in piece-meal steps and just commit them > to the turnk as they get created. I think your projects 2 and 4 could > be done that way. > > If a change requires a more elaborate re-write, then I usually construct > a branch, switch over to the branch and make changes there. When I'm > happy with the result, the branch is merged back into the trunk. > > Be careful with branches though. It is easy to get too far away from > main-line trunk development (although at this point the trunk should be > stabilizing toward release 1.0). > > 1) To construct a branch (just a copy of the trunk): > > (Make note of the revision number when you create the branch-- you can > get it later but it's easier to just record it at copy). > > svn cp http://svn.scipy.org/svn/numpy/trunk > http://svn.scipy.org/svn/numpy/branches/<somename> > > 2) To switch to using the branch: > > svn switch http://svn.scipy.org/svn/numpy/branches/<somename> > > You can also just have another local directory where you work on the > branch so that you still have a local directory with the main trunk. > Just check out the branch: > > svn co http://svn.scipy.org/svn/numpy/branches/<somename> mybranch > > 3) To merge back: > > a) Get back to the trunk repository: > > svn switch http://svn.scipy.org/svn/numpy/trunk > > or go to your local copy of the trunk and do an svn update > > b) Merge the changes from the branch back in to your local copy of the > trunk: > > svn merge -r <branch#>:HEAD > http://svn.scipy.org/svn/numpy/branches/<somename> > > This assumes that <branch#> is the revision number when the branch > is created > > c) You have to now commit your local copy of the trunk (after you've > dealt with and resolved any potential conflicts). > > If your branch is continuing a while, you may need to update your branch > with changes that have happened in the main-line trunk. This will make > it easier to merge back when you are done. > > To update your branch with changes from the main trunk do: > > svn merge -r <lastmerge#>:<end#> http://svn.scipy.org/svn/numpy/trunk > > where <lastmerge#> is the last revision number you used to update your > branch (or the revision number at which you made your branch) and <end#> > is the ending revision number for changes in the trunk you'd like to > merge. > > Here is a good link explaining the process more. > > http://svnbook.red-bean.com/en/1.1/ch04s03.html > > > > -Travis > > > > -Travis > > |
|
From: Travis O. <oli...@ie...> - 2006-07-01 18:30:20
|
Charles R Harris wrote: > > > On 6/30/06, *Robert Kern* <rob...@gm... > <mailto:rob...@gm...>> wrote: > > Travis Oliphant wrote: > > > Comments? > > Whatever else you do, leave arange() alone. It should never have > accepted floats > in the first place. > > > Hear, hear. Using floats in arange is a lousy temptation that must be > avoided. Apart from that I think that making float64 the default for > most things is the right way to go. Numpy is primarily for numeric > computation, and numeric computation is primarily in float64. > Specialist areas like imaging can be dealt with as special cases. > > BTW, can someone suggest the best way to put new code into Numpy at > this point? Is there a test branch of some sort? My favorite is to make changes in piece-meal steps and just commit them to the turnk as they get created. I think your projects 2 and 4 could be done that way. If a change requires a more elaborate re-write, then I usually construct a branch, switch over to the branch and make changes there. When I'm happy with the result, the branch is merged back into the trunk. Be careful with branches though. It is easy to get too far away from main-line trunk development (although at this point the trunk should be stabilizing toward release 1.0). 1) To construct a branch (just a copy of the trunk): (Make note of the revision number when you create the branch-- you can get it later but it's easier to just record it at copy). svn cp http://svn.scipy.org/svn/numpy/trunk http://svn.scipy.org/svn/numpy/branches/<somename> 2) To switch to using the branch: svn switch http://svn.scipy.org/svn/numpy/branches/<somename> You can also just have another local directory where you work on the branch so that you still have a local directory with the main trunk. Just check out the branch: svn co http://svn.scipy.org/svn/numpy/branches/<somename> mybranch 3) To merge back: a) Get back to the trunk repository: svn switch http://svn.scipy.org/svn/numpy/trunk or go to your local copy of the trunk and do an svn update b) Merge the changes from the branch back in to your local copy of the trunk: svn merge -r <branch#>:HEAD http://svn.scipy.org/svn/numpy/branches/<somename> This assumes that <branch#> is the revision number when the branch is created c) You have to now commit your local copy of the trunk (after you've dealt with and resolved any potential conflicts). If your branch is continuing a while, you may need to update your branch with changes that have happened in the main-line trunk. This will make it easier to merge back when you are done. To update your branch with changes from the main trunk do: svn merge -r <lastmerge#>:<end#> http://svn.scipy.org/svn/numpy/trunk where <lastmerge#> is the last revision number you used to update your branch (or the revision number at which you made your branch) and <end#> is the ending revision number for changes in the trunk you'd like to merge. Here is a good link explaining the process more. http://svnbook.red-bean.com/en/1.1/ch04s03.html -Travis -Travis |
|
From: Charles R H. <cha...@gm...> - 2006-07-01 17:56:36
|
All, This is bit off topic, but a while ago there were some complaints about the usefulness of distutils. I note that KDE has gone over to using cmake after trying scon. I am not familiar with cmake, but perhaps someone here knows more and can comment on its suitability. Chuck |
|
From: Charles R H. <cha...@gm...> - 2006-07-01 17:48:13
|
On 6/30/06, Robert Kern <rob...@gm...> wrote: > > Travis Oliphant wrote: > > > Comments? > > Whatever else you do, leave arange() alone. It should never have accepted > floats > in the first place. Hear, hear. Using floats in arange is a lousy temptation that must be avoided. Apart from that I think that making float64 the default for most things is the right way to go. Numpy is primarily for numeric computation, and numeric computation is primarily in float64. Specialist areas like imaging can be dealt with as special cases. BTW, can someone suggest the best way to put new code into Numpy at this point? Is there a test branch of some sort? I have some free time coming up in a few weeks and would like to do the following: 1) add a left/right option to searchsorted, 2) add faster normals to random, 3) add the MWC8222 generator to random, 3) add the kind keyword to the functional forms of sort (sort, argsort) as in numarray. Chuck |
|
From: Alan G I. <ai...@am...> - 2006-07-01 16:01:16
|
On Sat, 1 Jul 2006, Ed Schofield apparently wrote: > couldn't we make the transition easier and more robust by > writing compatibility interfaces for zeros, ones, empty, > called e.g. intzeros, intones, intempty I think Robert or Tim suggested int.zeros() etc. fwiw, Alan Isaac |
|
From: Ed S. <sch...@ft...> - 2006-07-01 10:53:28
|
On 30/06/2006, at 10:11 PM, Travis Oliphant wrote: > I should have worded this as: > > "People who want arange to return floats *as a default* should be > directed to linspace" > > So, basically, arange is not going to change. > > Because of this, shifting over was a cinch. I still need to write > the > convert-script code that inserts dtype=int > in routines that use old defaults: *plea* anybody want to write > that?? Hmm ... couldn't we make the transition easier and more robust by writing compatibility interfaces for zeros, ones, empty, called e.g. intzeros, intones, intempty? These functions could of course live in oldnumeric.py. Then we can get convertcode.py to do a simple search and replace -- and, more importantly, it's easy for users to do the same manually should they choose not to use convertcode.py. I could work on this this weekend. I'm pleased we're changing the defaults to float. The combination of the int defaults and silent downcasting with in-place operators trips me up once every few months when I forget to specify dtype=float explicitly. Another wart gone from NumPy! I'm surprised and impressed that the community's willing to make this change after 10+ years with int defaults. I think it's a small but important improvement in usability. -- Ed |
|
From: Robert K. <rob...@gm...> - 2006-07-01 04:53:35
|
We now have mailing lists set up to receive notifications of changes to Trac tickets and SVN checkins for both NumPy and SciPy. We do not have Gmane gateways for them, yet. http://www.scipy.org/Mailing_Lists -- 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 |
|
From: Tim L. <tim...@gm...> - 2006-07-01 00:42:15
|
On 7/1/06, Eric Jonas <jo...@mi...> wrote: > On Fri, 2006-06-30 at 12:35 -0400, Sasha wrote: > > > Besides, decent unit tests will catch these problems. We all know > > > that every scientific code in existence is unit tested to the smallest > > > routine, so this shouldn't be a problem for anyone. > > > > Is this a joke? Did anyone ever measured the coverage of numpy > > unittests? I would be surprized if it was more than 10%. > > Given the coverage is so low, how can people help by contributing unit > tests? Are there obvious areas with poor coverage? Travis, do you have > any opinions on this? > ...Eric > > A handy tool for finding these things out is coverage.py. I've found it quite helpful in checking unittest coverage in the past. http://www.nedbatchelder.com/code/modules/coverage.html I don't think I'll have a chance in the immediate future to try it out with numpy, but if someone does, I'm sure it will give some answers to your questions Eric. Cheers, Tim Leslie > > 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 > |
|
From: Travis O. <oli...@ee...> - 2006-06-30 23:18:26
|
Sasha wrote: > On 6/30/06, Travis Oliphant <oli...@ee...> wrote: > >> ... >> Yes, this is true, but the auto-generation means that success for one >> instantiation increases the likelihood for success in the others. So, >> the 26.7% is probably too pessimistic. > > > Agree, but "increases the likelihood" != "guarantees". Definitely... > > The best solution would be to autogenerate test cases so that all > types are tested where appropriate. Right on again... Here's a chance for all the Python-only coders to jump in and make a splash.... -Travis |
|
From: Sasha <nd...@ma...> - 2006-06-30 23:16:30
|
On 6/30/06, Travis Oliphant <oli...@ee...> wrote: > ... > Yes, this is true, but the auto-generation means that success for one > instantiation increases the likelihood for success in the others. So, > the 26.7% is probably too pessimistic. Agree, but "increases the likelihood" != "guarantees". For example, relying on nan propagation is a fine strategy for the floating point case, but will not work for integer types. Similarly code relying on wrap on overflow will fail when type=float. The best solution would be to autogenerate test cases so that all types are tested where appropriate. |
|
From: Travis O. <oli...@ee...> - 2006-06-30 23:04:54
|
Alexander Belopolsky wrote: >On 6/30/06, Sasha <nd...@ma...> wrote: > > > >>File `numpy/core/src/arraytypes.inc.src' >>Lines executed:47.35% of 868 >> >> > >This is was an overly optimistic number. More relevant is the >following obtained by disabling the #line directives: > >File `build/src.linux-x86_64-2.4/numpy/core/src/arraytypes.inc' >Lines executed:26.71% of 5010 > > Yes, this is true, but the auto-generation means that success for one instantiation increases the likelihood for success in the others. So, the 26.7% is probably too pessimistic. -Travis |
|
From: Sasha <nd...@ma...> - 2006-06-30 23:02:21
|
---------- Forwarded message ---------- From: Alexander Belopolsky <ale...@gm...> Date: Jun 30, 2006 7:01 PM Subject: Re: [Numpy-discussion] Time for beta1 of NumPy 1.0 To: "David M. Cooke" <co...@ph...> Cc: Fernando Perez <fpe...@gm...>, num...@li... On 6/30/06, Sasha <nd...@ma...> wrote: > File `numpy/core/src/arraytypes.inc.src' > Lines executed:47.35% of 868 This is was an overly optimistic number. More relevant is the following obtained by disabling the #line directives: File `build/src.linux-x86_64-2.4/numpy/core/src/arraytypes.inc' Lines executed:26.71% of 5010 |
|
From: Alexander B. <ale...@gm...> - 2006-06-30 23:01:55
|
On 6/30/06, Sasha <nd...@ma...> wrote: > File `numpy/core/src/arraytypes.inc.src' > Lines executed:47.35% of 868 This is was an overly optimistic number. More relevant is the following obtained by disabling the #line directives: File `build/src.linux-x86_64-2.4/numpy/core/src/arraytypes.inc' Lines executed:26.71% of 5010 |
|
From: Travis O. <oli...@ee...> - 2006-06-30 23:01:11
|
Jonathan Taylor wrote:
> In some earlier code (at least one of) the following worked fine. I
> just want
> to get a new type that is a byteswap of, say, float64 because I want to
> memmap an array with a non-native byte order.
>
> Any suggestions?
Last year the array scalars (like float64) were confused with the
data-type objects dtype('=i4'). This was fortunately changed many
months ago so the two are now separate concepts. This may be why your
old code worked.
You want to get a data-type object itself:
d = numpy.dtype(numpy.float64)
d = numpy.float64(1).dtype # you have to instantiate a float64 object
to access it's data-type.
Then
d.newbyteorder('>') or d.newbyteorder('big') will work.
But, probably easier and clearer is just to use:
dlittle = numpy.dtype('<f8')
dbig = numpy.dtype('>f8')
There are now full-fledged data-type objects in NumPy. These can be
used everywhere old typecodes were used. In fact, all other aliases get
converted to these data-type objects because they are what NumPy needs
to construct the ndarray.
These data-type objects are an important part of the basearray concept
being introduced to Python, so education about them is very timely.
They are an out-growth of the PyArray_Descr * structure that Numeric
used to "represent" a data-type internally. Basically , the old
PyArray_Descr * structure was enhanced and given an Object header.
Even just getting these data-type objects into Python would be a useful
first-step to exchanging data.
For NumPy, the data-type objects have enabled very sophisticated
data-type specification and are key to record-array support in NumPy.
Best,
-Travis
|
258 messages has been excluded from this view by a project administrator.
![http://bo.sohu.com//images/img20040502/dj_bg.gif">](http://bo.sohu.com//images/img20040502/dj_bg.gif">){kind=link}
![http://igame.sina.com.cn/club/images/topmenu/topMenu_8.gif"](http://igame.sina.com.cn/club/images/topmenu/topMenu_8.gif"){kind=link}