R 2.15.3 (代号 “Security Blanket”)已经释出。这个版本带来了少量新特性和 Bug 修正。这是 2.15.x 系列的最后一个版本,以及自 2004 年开始发布的 2.x 系列的最后一个版本,下一版本将是预计在 4 月发布的 3.0。

主要变动

  • 升级了自带的 PCRE 库
  • 在 64 位 Windows 系统上,R_alloc 现在可以和其他 64 位系统一样分配多至 32GB 的内存
  • real(), as.real()is.real() 现已废弃,使用时会抛出警告
  • 解压缩工具的若干修正



发布公告

https://stat.ethz.ch/pipermail/r-help/2013-March/348468.html

下载地址(源码包)

http://cran.r-project.org/src/base/R-2/R-2.15.3.tar.gz

注: Security Blanket,安全毯;带给人安全感的熟悉的物体(保护 3.0 顺利落地?)

事实上,不知道R现阶段的定位和发展方向是什么?是提供面向统计领域的全面应用,还是向数值计算的方向发展。虽然,看起来R core把更多的精力用在了基础构建上,但是却很难看出来他们打算向哪个方向发展?从使用上的易用性到开源特征看,他比较适合于教育机构,比如大学等,因为其购买成本接近于零,并可以根据具体的教学安排与目的构建不同的数学统计模型,且语法上比较容易被非计算机专业的学生理解。即——进入门槛很低。

但是,当应用领域稍稍扩展到专业领域后,会出现一些问题:

1.算法的严谨性和计算过程的完整性。比如,大部分附加包——即base packages外的扩展包,都有一个包的样子和格式化的形式,比如说明文档等。而具体的包的质量,是一个大大的?。如果仅仅是应用在不考虑风险成本的用途上,比如做个非核心数据的常规数据分析,R的使用风险基本是不用考虑的。但你要是有一个多指标决策模型,那我认为还是必须要审查构成每个核心指标的应用函数和计算过程,速度问题是可以被实时观察到的,算法要是有瑕疵,你就很难发现了,如果没有数据错误屏蔽机制进行先验,那就只能适用错误爆发的后觉了。所以建议官网应该在扩展包下载界面上增加一个Bug列表。这样至少降低了使用者的选择风险。

2.统计模块化还是数值计算易用化。如果把R与相关的统计软件简单比较,首先说在功能完整性上,由于大量扩展包的存在,R是不差的。如果R core打算在S 语言的基础上构建一个统计软件的大厦,那么模块化可能是一个必然的选择。虽然大部分统计人员面向不同的统计应用领域,但实际上所使用的统计工具(数学意义上的)都很近似,也就是说一般统计分析工具的需求很大;在这之外,就是一些自定义的特殊统计需求了,而R在这方面是没有太大问题的。如何把一般统计分析工具构建的扎实(至少要达到R base packages的质量),我认为这是R core所应该考虑到一个问题。即——对base packages进行相应的完整和调整。R会面向数值计算发展吗?我认为可能性不大,理由来自于这方面的需求很小(至少是现在)。很小指的是计算设备的成本构成的应用领域被局限于能够承担自行开发硬件及软件的部门。而一般的商业部门或研究部门会选择使用专业设备及捆绑的商业软件,因为他有法律保障。再次一点的往往就会选择R这种类型的软件进行数值计算了,因为人工成本和计算成本都很低。如果需求部门是特定的,那他的计算领域和需求也必然是特定的,那么他会自行开发算法和计算过程。因此,我认为R更多的在数值计算易用化方面仅有一点发展的空间。

最后,就是一个特别的想法,希望R能够在高中阶段就被普及(我国的)。如果看到托马斯微积分完全是用计算机绘图的方式进行讲解的,那么我想大家就会认同我的想法了。

计算机是用来计算的,应该让每一个使用计算机的人理解这个含义,并且能够让他们自如的把其算计方法表达给计算机。[s:17]

回复 第3楼 的 zggjtsgzczh:

数值计算貌似有很多其他软件了,R就专心搞统计计算就好啦...确实您说的R其他程序包的质量问题,所以需要很厉害的懂统计的懂编程序包的设计就像我们的谢老大一样,然后让大家测试,不可能R core弄出我们所有需要的base的....

我现在已经很少用R了。说一下原因:

支持文档,Documentation。R的help文档就是天书,看懂基本考猜。很多function的参数设定都交代得不清楚,更别说算法上得解释了。往往最后给你一篇论文得索引,但是论文里面对程序得介绍有少之又少。我还曾被迫看过fortan的source code。说实话,fortan是一门读起来很不容易的语言。我的导师还和我经常提起R里面某些很奇特的处理方式,但是这些再documentation里面都是找不到的。

速度。读写文件的速度,执行R script的速度,并行计算上的缺陷。读写文本文件的速度奇慢,或许我不改在这里用python做比较。脚本速度运行极慢,一旦for loop 叠多了就是悲剧。这个在自己开发算法、调试的时候造成很多的困难。为了增加运行速度,不得不使用各种tips,结果导致程序的可读性大大下降。 并行计算,R15 内置有parallel(shared memory),这个其实还挺好用的,但是要在cluster上用MPI就有一定困难了。特别是在BLUE GENE Q上,我们的工程师告诉我,由于R的诡异结构,根本都编译不起来。(好吧,可能是他偷懒了。但是R在CS中的极差口碑总也是有原因的吧。)

对我来说R适合做的事情:画画图,小数据整理一下,跑一下别人方法,校准自己程序的计算精度,当计算器(电脑上直接开terminal,打R回车)。

我的替代方案:python(numpy)+ Cpp

回复 第6楼 的 adouzzy:膜拜!同感,R的help文档就是天书,基本看不懂

话说现在身材正向图中这人靠拢 。。。[s:14]

回复 第6楼 的 adouzzy:我虽然接触R不久,但一上来也发现你说的一些问题了,深有同感。现在 R和Python交叉的一起学。建议学R的同学注意一下这些不利方面。