还有 the art of deception
是不是还是和 mecab 用中文训练的结果差不多?
哇,现在 ICTCLAS 竟然可以在非 windows 用了...
header 处理法是 CGI 的传统... 然后 rack 把这种环境滥用到 "rack.*" 上了
@blacktulip @qhwa 就是 http://www.lfgcomic.com/extras/ 官方提供的头像图...
是的... 不过对一般货币如现在的人民币/美元的面额配置是最优解:
如果一个解法是最优解, 那其中除了最大面额外,1,5,10,50,100,500,...等面额都最多是 1 张 (如果有 2 张,可以抽出来替换成 x2 的面额). 而其中 2,20,200,...等面额最多是 2 张 (如果有 3 张 2,可以抽出来替换成 1 张 5 和 1 张 1). 所以最优解里,每一十进位上的和最多是 1+2*2+5 = 10, 但 = 10 就能替换成 1 张 10, 不算最优解了,所以和最多是 9. 于是最优解里小面额的总和不超过 999... , 还是小于 1 张最大面额. 综上,对于人民币/美元,粗鄙解得出来的结果和最优解一致。
第二题...
def make_change r, coins = [50,20,10,5,1]
coins.map do |c|
q, r = r.divmod c
q
end
end
edit
其实这道题应该是给些奇怪的 coin 配置,考 DP (动态规划) 的 但对于一般货币 (1,2,5,10,20,50,...) 这么整也能得到最优解... 原因见 #33 楼
#3 楼 @daqing 不知道... 不过对于理解 *
在类型声明的作用是有点帮助的...
typedef void (foo)(int);
typedef void (*foo_p)(int); // 函数指针
typedef void (**foo_p_p)(int); // 函数指针的指针
另外还有一种 比较绕脑子的嵌套声明法,就是返回类型是函数指针的函数类型...
typedef void* (*(*bar)(int))(); // 相当于 typedef void* (*foo)(int); typedef foo (*bar)();
为什么要这么写呢... 因为下面两种写法语法都不好解析...
typedef void*(*)(int) (*bar)();
typedef (void*(*)(int)) (*bar)();
头像反映取向,很正常啊...
1 的 foo 用于函数指针时还要加个 *
, 可以说是函数 指针 类型...
typedef void *(foo)(int);
void* f(int i) { return NULL; }
foo* x = f;
不过一般不这么用
2, 3 的 foo 是函数指针类型,对应的函数的返回类型分别是 void
, void*
自带补全够用了
ctrl+p 补全出现过的词 ctrl+x ctrl+l 全行补全
把 $KCODE
那行改成 # coding: binary
?
队形 (意见大合) 和吵架 (意见不合) 是帖子数的主要来源...
#20 楼 我举的两段代码如果分散在 a.rb 和 b.rb, 然后它们是由 c.rb 载入的,编程者就必须把这 3 个文件都看了然后想明白了才能知道真正的调用顺序,是真正影响程序的理解和可读性的问题。如果 c.rb 是用 Dir.glob '*.rb'
之类的方法来获取 a.rb 和 b.rb 的路径然后载入,甚至会因为文件系统的差别而导致行为的差别,是绝对不可忽视的坑...
如果像 rails 那样通过 const_missing
去载入,甚至会因为访问 url 的顺序不同而产生不同的结果,不是这么简单就能解决的事情。
而这种坑多多少少就是因为从继承的角度去设计模块造成的...
#48 楼 @blackanger "实质" 是你加的...
继承这个词含义太多了,我还是希望避免增加它的外延... 就像这个帖子的讨论一样,我说 mixin 不是 (规格) 继承,你说 mixin 是 (实现) 继承,没意义...
#12 楼 @blackanger 前面有个 .
, 谁都看得出来是方法...
命名变量是不行,但关键字定义方法完全没问题,不需要刻意避免...
(1..3).begin
(1..3).end
1.class
关键字用来做 hash key 也完全没问题
''.encode 'utf-8', undef: :replace
validate ... if: lambda{ ... }
只说明了硬件比较牛,per-connection 资源消耗比较少 (2k-3k, 不过我记得 Haskell 有 1k 的做法,同样的硬件可以达到更高的指标)
但这是裸跑的,真实逻辑一加上就掉下去到 c10k 或者更低水平了...
和载入顺序当然有关系了,先载入 E 的话,ancestors 顺序就不同了。我说的是编程时不好确定调用到哪里,你说的是运行时这个东西是确定的,不是一回事...
你看,当多继承去理解的话,首先得澄清"继承"的概念,要说明计算机里的"继承"和分类学中的概念不同,它还可以泛化到整体 < 部分
之类的用途。然后还要澄清多继承的概念,区分好规格继承和实现继承。再然后要解释为什么 Ruby 被分类为单继承的语言 (因为 Ruby 规格单继承,实现多继承). 再然后要解释清楚为什么不直接用 mixin 代替单继承的语法 (mixin 的四个限制)... matz 的书就用了大半章去澄清这里的坑...
同样是 matz 的书里写的 (35 页):
多重继承相当于语言功能支持模块组合
所以绕了一个圈又跑回来变成 composition 啦...
我觉得这里没有谁更本质的地方,你可以把 mixin 中各部分态射到多继承中的对应概念,表明两者实质上没有不同,但就组合去理解对写出来的代码没影响,而且对面向对象设计提供了便利的准则:分类就用规格继承,差分/组合就用 mixin
哦,是 6.4k / 连接么,占内存不算少啊
宋体,难道是 cmd.exe ...
64G 内存?