V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  ipwx  ›  全部回复第 192 页 / 共 195 页
回复总数  3888
1 ... 184  185  186  187  188  189  190  191  192  193 ... 195  
2017-01-02 00:17:22 +08:00
回复了 fjhh 创建的主题 Python 求问 Python 大神,多进程处理文本内数据
机械硬盘随机读取需要寻道,速度远低于顺序读取。所以你进程分得越多越慢。

话说现在的程序员都不知道硬盘 IO 是大部分程序的瓶颈了吗?
2017-01-01 19:29:27 +08:00
回复了 AlisaDestiny 创建的主题 Python Python 如何按照行来分割大文件。
2017-01-01 19:16:30 +08:00
回复了 AlisaDestiny 创建的主题 Python Python 如何按照行来分割大文件。
100M 这个还需要问大神…… 老老实实地边读边写不就行了,时间都在 IO 上不在运算上, Python 绰绰有余。

哦对了,最好是读写的两个文件在两块硬盘上,不然就很慢了。
2017-01-01 17:50:42 +08:00
回复了 glogo 创建的主题 C C/C++ 宏的问题 两个 @@符号
@glogo g++ 应该是不会自动调用 autoconf 的。但是 cmake 就不知道了。

我映像中的 cmake 一般流程是根据不同平台产生不同的编译脚本。比如对 *nix 产生一个 Makefile ,对 Visual C++ 产生一个 .sln 等等。然后你(手工地)再用对应平台的工具来进行编译。

所以一个典型的 cmake 流程:

mkdir build && cd build && cmake .. && make

同时, cmake 是很灵活的,书写 cmake 脚本的人可以在产生 Makefile 的阶段中做任何事情。我不知道你的 cmake 脚本有没有处理 .h.in 里面的特殊标记。
2017-01-01 16:02:18 +08:00
回复了 glogo 创建的主题 C C/C++ 宏的问题 两个 @@符号
@glogo 在 make 之前运行一下 autoconf ,然后工具链会读取 gflags_declare.h.in ,产生一个 gflags_declare.h 。

理由?很简单,不同平台上面需要不同的 define 。另外一点是为了支持 feature 的精细开关,用以禁用一部分功能,减小编译出来的二进制大小和依赖库数量。
买个上千的蓝牙头戴式,想坏也难。 <-- 我猜你的都是耳塞式,线和耳机连接处坏掉?
2017-01-01 11:17:53 +08:00
回复了 liuzhiyong 创建的主题 分享创造 [分享经验] 我是怎么让老一辈放弃 IE 改用 Chrome 滴
用得舒心就是好,哪有什么大材小用的。既然你家的两位不用网银,给个 MBA 不是挺好?轻巧便携,开盖即用,不用关机,不用 360 升级,还不用杀毒。
2016-12-31 11:01:34 +08:00
回复了 liuzhiyong 创建的主题 分享创造 [分享经验] 我是怎么让老一辈放弃 IE 改用 Chrome 滴
我把 Macbook Air 给了母上大人( Safari 大法好
2016-12-27 17:26:24 +08:00
回复了 coolair 创建的主题 问与答 一个 Python 循环问题
@kimchan 。。。四楼的答案当然是对的,因为 return foundPos 在 for 循环体外。

话说你们没人关注一下我的代码吗?它是对的,且只遍历了一遍。
2016-12-27 17:01:36 +08:00
回复了 coolair 创建的主题 问与答 一个 Python 循环问题
我是来搞笑的:

findpos = (lambda items, s1, s2: (lambda f: ([i for (l, i) in sorted((x for x in (f(i, v) for (i, v) in enumerate(items)) if x))] + [-1])[0])(lambda i, v: (0, i) if v == s1 else ((1, i) if v == s2 else None)))

print(findpos(['a', 'b', 'ab', 'ab'], 'ab', 'a'))
print(findpos(['a', 'a', 'b'], 'ab', 'a'))
print(findpos(['b'], 'ab', 'a'))
2016-12-26 14:27:53 +08:00
回复了 lxiange 创建的主题 程序员 来看看这个函数的时间复杂度是多少
@laxenade @rogerchen 首先对于“民间科学家”的不当言论表示歉意。但是我仍然有话反驳。

先列出结论:我认为就你们举的这个例子,无论是 O(n) 还是 O(n log2 n) 都是逻辑自洽的,其中 O(n log2 n) 的论述见我之前的回复。当令 k = log2(n),可得 O(2^k * k)。然而在这里如果我想要把 k 代换成 n 给出 O(2^n * n) 的复杂度就是不恰当的,因为 n 在上下文是有明确含义的,不能把一个符号随意变换含义。

所以对于 O(2^n) 的这个结论,如果按照 n 表示 k 的角度去看,就少了一个 *k 的因子;如果不是这样,那就显然更加离谱了。
- - - -

@rogerchen 对于你说的复杂度分析不应该考虑工程问题,这显然不合适。我们目前的算法都是为了电子计算机设计的,因此所有算法分析和时间复杂度估计都是在电子计算机的前提下成立的;这已经考虑了工程问题。

@laxenade 你说“限制 32bit 的话,那就都变成 O(1)了”,只是大 O 。就算是考虑 32 位整数,在这个例子里面,当限定 n 为 32 位整数, O(15 n) (见我先前的回复)依旧是比 O(15 * 2^32) 更紧的界。同时,算法的复杂度不会小于 Ω(n)。因此 Ω(n) 和 O(15 n) 卡住了这个算法在 32 位整数下的界,因此 Θ(n) 是紧界。

当然如果按照教科书的定义,一切 n < ∞ 的论述都是没有意义的。可是啊,读书不能死扣概念,要领会它的精神。复杂度分析是为了在没有测试算法的前提下估计它的运行时间,当我们有了 32 位整数的大前提下,考虑更细致的界依旧是有意义的,因为我们可以通过计算来估计两个不同算法的优劣。
- - - -

@rogerchen @laxenade 另外还有第二点反驳。你们可能不赞同我说的,“可以定义 i++, sum++, i<n 三个操作为常数时间”。然而你们是出于电子计算机的前提才这么反驳我的。我们谁也不知道将来的量子计算机,乃至什么其他种类的计算机究竟能够有多快,因此我假设这三个操作是 O(1) 是公理,完全不违背理论性。

如果接受这三个假设,那么你们的算法复杂度是 O(n) 是没有错误的结论。当然如果不接受,认为这三个操作的复杂度是 O(log2 n),那么推出来的结论就是 O(n log2 n)。

当我们考虑 32 位定长整数的电子计算机的时候,也可以认为上述三个操作为 O(1),得出 O(n) 的结论。
2016-12-26 11:16:56 +08:00
回复了 lxiange 创建的主题 程序员 来看看这个函数的时间复杂度是多少
@rogerchen @lxiange 你们要说的事情我知道,但是呢……

根据你们的伪代码定义,令 k=log2(n),那么 n++, i++, i<n 三个运算都 <= O(k)。一共进行了 n 次,那么 <= O(3kn) = O(3k*2^k) = O(3n log n)。

发现了没有,你们的第一个问题是混淆了 n 和 k 。这是我说你们民间科学家的第一个原因。

第二个原因,你们混淆了理论性(理想电脑)和工程性的边界。如果按照理论性来探讨,我们可以随时随地把某些操作定义为 O(1)。再说一遍, O(1) 的操作是定义出来的,我可以定义 i++, n++ 和 i<n 三个运算为 O(1),这不违反理论。所以在理论性的前提下,这个函数为 O(n)。

如果按照工程性来考虑,这个世界上没有无线位宽的电脑。所以位宽 k 是常数。按照你们的代码风格为 C 来考虑,这个位宽可以定义为 k=32 。所以工程性为前提,算法复杂度为 O(3kn) = O(15n)。

混淆了理论性和工程性的边界,所以说你们是民间科学家。
- - - -

别拿什么考研答案来说事,我还看不上考研这个层次的题目。
2016-12-26 10:48:10 +08:00
回复了 lxiange 创建的主题 程序员 来看看这个函数的时间复杂度是多少
一个民间计算机科学家的钓鱼贴你们也回得这么起劲干嘛。
2016-12-25 18:22:42 +08:00
回复了 okevin 创建的主题 macOS 新 mac 的输入法和 spotlight 快捷键怎么是相反的?
我喜欢 Ctrl+Space
2016-12-22 15:50:23 +08:00
回复了 nbhec2 创建的主题 编程 OOP 思想真的很先进吗 GOTO 真的不能用吗
非嵌入式领域,人工成本比硬件成本高得多。
apt-get install fcitx-*
2016-12-12 23:51:34 +08:00
回复了 taowen 创建的主题 分享创造 全世界最快的 JSON 解析器 - 比别的快 10x
毕竟静默报错可能会把错误累积到系统其他不知道哪里的地方,这时候查错的成本实在是大得惊人。更别说恶意攻击的情况了。
2016-12-12 23:50:46 +08:00
回复了 taowen 创建的主题 分享创造 全世界最快的 JSON 解析器 - 比别的快 10x
你这代码不能防御错误的 JSON 文件。现在是硬件过剩而软件复杂度超过任何人能处理的时代,宁可用大部分性能去防御错误输入,也不要假定输入是对的。显式报错永远比静默忽略要重要。
2016-12-10 16:53:13 +08:00
回复了 goodbest 创建的主题 MacBook Pro cPro 众筹中:完美匹配 2016 MBP 的扩展 Docker
看了这张图我更进一步认为苹果干掉这么多接口是多赞的事情。
1 ... 184  185  186  187  188  189  190  191  192  193 ... 195  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2451 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 58ms · UTC 06:58 · PVG 14:58 · LAX 23:58 · JFK 02:58
Developed with CodeLauncher
♥ Do have faith in what you're doing.