Shell's Home

Jan 26, 2009 - 1 minute read

牛年快乐

过年了过年了 祝大家牛年快乐,万事如意 贝壳敬上

Jan 20, 2009 - 1 minute read

24点计算原理和程序

最近开心上狂算24点,于是贝壳搞了一个24点计算程序,并且说明原理。 我们将24点问题一般化,变成一个搜索问题。假定从一个初始表开始,里面有一些原子。我们定义一个操作,结合。每次操作任意从中选择出两个(或者以上)原子,使用算符连接,成为一个新的原子。那么,一般来说,24点就是计算所有可能的路径,从初始表开始,持续进行结合,直到只剩下一个原子,并且对这个原子求值得24。 有人可能在算符优先级上想不开,其实不用考虑这个问题,每次求值的时候,按照求值顺序优先就可以。你想到的另外一种优先级可能,会在穷举的时候被列举出来算掉,不用担心遗漏。 同时,算子必须是两目以上算子,因为单目算子可以持续作用于同一个对象,因此原子表中的原子个数并不严格单调减少,造成无法肯定路径收敛于有限步骤上。并且,如果允许单目算子,那么我只需要求导和阶乘就可以对任何数字求24点。 ((a')!+(b')!+(c')!+(d')!)!=24 因此,单目算符是没有意义的。 另外,注意算符分可交换和非可交换的。例如:a+b=b+a,但是a-b!=b-a。如果不注意这点,倒是不会漏算,但是会造成搜索空间增大,并且有重复结果。 以下是24点计算程序,python版本的。有兴趣的朋友可以用scheme重写,相信会更简洁有效。回头会用django封装一下,做成网页给大家玩玩。 #!/usr/bin/python import sys symbol_list = [ ("%s+%s", True), ("%s-%s", False), ("%s*%s", True), ("%s/%s", False), ("%s**%s", False), ] def diff_seq(length): for i in range(0, length): for j in range(i + 1, length): yield (i, j) def get_less_state(input_state): for i, j in diff_seq(len(input_state)): temp = input_state[:] del temp[j] del temp[i] for s in symbol_list: rslt = s[0] % (input_state[i], input_state[j]) rslt = "(%s)" % rslt temp.

Jan 12, 2009 - 1 minute read

论同时的双系统--准虚拟对双系统的进一步扩充

熟悉贝壳的人都知道,贝壳是个linux爱用者,不过因为工作关系,经常要使用windows。贝壳在自己的笔记本上使用了linux/windows混合双系统,并通过共用磁盘的方式共享数据,解决这个问题。但是长期的使用表明,这种解决方案存在几个巨大的瑕疵。首先是系统切换时间常,因此长期在一个系统中工作,而很少触及另外一个系统。其次是稳定性差,windows下一旦崩溃,进入linux后就需要检测数据盘,80G的数据慢慢扫描,感觉晕到死。那么是否有一种方案,能够同时使用两个工作级系统(注意,不是实验级,贝壳成功的在windows下的vmware里跑了一个oracle,这个可以说是实验级的典范。然而工作级系统的要求和实验级完全不同)。 从系统发展史的角度来说,我们可以预见,将来的系统将是脱离硬件的。首要的原因就是和硬件不相匹配的各个层级的计算能力需求。现在系统发展有两个极端,一个是虚拟机,试图将一个硬件整体分离,运行多个系统。另一个是高性能集群,试图将多个硬件合并,运行一个系统。从根本上说,这是因为高性价比的硬件集中在了一个性能区间,而实际的性能需求却是完全分离的,因此我们才会出现如此两类完全背离的需求。而现在有大量宝贵的人力浪费在了系统和硬件结合,系统稳定性问题上,这无疑是对将来发展的一个巨大瓶颈。虽然无法预知将来的技术发展会以何种方式解决这个问题,然而可以预见的是,解决硬件和性能的背离将是人类计算机发展史上一个重要的里程碑,解决这个问题的人必定会在计算机历史上留下重重的一笔。 同时,更进一步,贝壳揣测,将来的解决方案将是系统硬件调度/驱动和系统软件管理分离。一个软系统拥有一个用户表和一个硬件表,硬件表上写他可能有10个键盘,两个显示器,或者一堆其他设备。系统借助某个可信方案,管理了一系列虚拟抽象设备和真实设备形成的映射。作为系统层以上的软件,我们只要关心如何操作这个虚拟设备即可。而实际上,我们可以通过管理参数和对应关系实现各种需要。例如我们可以将多个机器的硬件管理核心加入一个系统,形成集群。或者我们可以在一个机器的硬件管理核心上加入多个系统,形成虚拟机。这个基本是分布系统的观点。如此一来,系统层软件就无法得知也无需得知自己是在到底运行在什么环境下。只是这个系统设计方案对高性能要求的子系统(主要是显卡)相当不利。 从揣测回到现实,为了实现一个工作级系统(幸好,还不是工业级),我们需要为系统制定一些评判标准,以判别各个方案的优劣。我们首先能想到的评判标准就是速度,一个慢吞吞的系统解决方案是没有任何实用价值的。当然,这个速度是有差异的,可能是linux快一些,windows慢一些,或者相反。我们假定实际的需要是windows快一些,因为linux可以通过定制进行加速。 我们的第二个评判标准就是稳定性,经常会崩溃的系统不比慢吞吞的系统好到哪里去,甚至会更加让人讨厌。虽然工作级系统并没有工业级那样高的要求,然而高负荷稳定,宕机平均频率低于3天/次还是要保证的。而后我们还希望两个系统可以做到数据互通,即两个系统间的数据尽可能的共享,至少要做到文件和邮件的共享。最后,我们希望解决方案简单易用,便于实施和维护。 而后,我们列出了一个原始方案,和以下几个改进解决方案,并给出优劣评价,谨供大家参考借鉴。同时我们在其中还补充了一些无法实际解决问题的虚拟化解决方案,并且说明无法使用的原因,供适合的人自行选用。 原始方案,windows+linux+数据分区。此种方案是最中规中矩的,性能最高的方案。具有对硬件最好的支持,最容易的维护。如果需要运行游戏(尤其是魔兽,WOW),这也是唯一可行的工作级方案。稳定性评价属于尚可,主要由于ntfs在linux的稳定性并不好,ext3在windows需要使用非官方驱动,和某些(就是avast)驱动不兼容。数据互通比较方便,通过数据分区可以轻松的共享文件和邮件。 windows虚拟方案,vmware+虚拟分区。这种方案是改进方案中唯一可以跑游戏的,因为虚拟机随时可以关上。性能上满足windows快 linux慢的要求,虚拟系统显示性能良好,也可以通过文件共享部分的解决数据共享问题(文件共享方便,邮件共享困难)。稳定性很好,基本没有什么不稳定的问题出现,操作和维护都不困难。然而之所以一开始这种方案就被排除在外,主要是因为这种方案无法让linux驱动实体硬件,无法通过机器启动。这样也许对一些跑起来玩玩的人或者是内核工程师/测试员比较有用,然而如果要在linux里面进行大量工作,编译程序,运行服务,这种方案就力有未逮。因此这个方案可以说是一个实验级方案,而非工作级。 windows虚拟方案,vmware+实体硬盘。速度一般,windows快linux慢,基本和上面一个方案一样,唯一的区别就是linux也可以被实际驱动。然而这也成了整个方案的最大败笔,因为linux的驱动灵活性不如windows,因此无法经受这种系统切换的动作。举例来说,真实的机器上,硬盘是sata的,作为sda识别和使用。而虚拟机上则是IDE的,被识别成了hda。于是启动环境一变,就需要修改大量配置来调和这个问题。又例如,在真实机器上,X使用fglrx驱动,而虚拟机下面要用mesa。如果我在/etc/xorg.conf中不指定驱动,那么真实机器的驱动也会变成 mesa,导致性能下降。如果指定驱动,又会导致虚拟机内X无法运行。诸如此类的问题林林总总,需要大量细节修正,因此维护复杂,稳定性差,不建议正式使用。在贝壳机器上更严重的,出现了虚拟机内和虚拟机外争抢数据分区的状况,这种情况下数据分区实质是被当做盘阵用了。使用非专用的磁盘作为底层共享存储,并在上面运行ext3系统,这是及其危险和愚蠢的。 linux虚拟方案,xen。速度超快,但是上来就在贝壳的机器上暴出几个问题,因而没有继续测试。首先是安装xen后x无法启动,出现fglrx驱动无法加载的状况。其次是xen要求使用虚拟盘启动,可贝壳经常需要跑到windows下面打游戏。因此在简单测试后被剔除出局。感觉这种方案的最大问题在于配置管理太过复杂,debian下面已经很轻松了,只需要安装对应内核,使用工具建立虚拟机,但是依旧感觉麻烦到一塌糊涂。相信这种方案在专业级服务器领域应当有不俗表现。 linux虚拟方案,openvz。这种方案压根就不适合贝壳的状况,因为这个虚拟方案要求宿主和客户必须是同一CPU同一系统(不要求同一linux发行)。主要用于希望将一个主机切分成多个独立的同构主机,以达到分离管理的目的(例如业务服务器和数据库服务器分离)。需要做大型网络管理/虚拟主机业务的人可能会对这个虚拟方案感兴趣。 linux虚拟方案,vmware。速度一般,linux快windows慢,视频效果不错。vmware毕竟是商业公司,视频驱动挺齐全的。但是内核驱动的编译麻烦到死,首先是要求编译器版本和主内核编译器版本一致,于是贝壳去搞了个gcc-4.1,然后连接了上去。下面又是内核头定义出现版本差异,搞到现在还没有搞定。谁能搞的定的给个参考,最好是debian上的解决方案。 linux虚拟方案,kvm。这个是贝壳目前使用的方案,基本比较理想。速度很快,和xen基本差不多,显示速度不如vmware(理论上说装好显卡驱动应该会好点,不过贝壳找不到CLDC5446的XP驱动,那是Win32和Win95时代的显卡)。linux快windows慢,但是还在可忍受范围内。稳定性很好,只要测试通过,运行中到目前为止没有死机(当然很多参数是加了之后开机即死机)。数据可以通过samba互通,邮件也同样可以互通。然而使用samba无疑复杂很多,而且性能并不太好。只是从稳定性上说,让linux自己去驱动ext3总比半吊子的windows驱动更好,同时也不会出现争抢的问题。易用性上还算可以,无论是内核编译还是系统使用都不太难,最大的麻烦就是网络配置。根据贝壳的测试,在真实机器上superpi运行100W 位需要45秒,虚拟机内需要54-60秒,尤其在换用kvm-72.2后反而更慢了(54下降到60,折合真实机器83.3%下降到75%)。 总体来说,贝壳更倾向于使用全开源的准-全虚拟解决方案kvm,主要因为他简便易行,对系统影响小,不改变现有系统。同时性能高,稳定性好。主要需要解决显卡效率问题。如果以上问题无法彻底解决,贝壳打算换用linux下的vmware,想办法搞定他的内核模块。

Jan 1, 2009 - 1 minute read

新年快乐

废话不多说了,新年快乐。 TMD想找个人说新年快乐也找不到,全出去Happy了,真该考虑找个女朋友了。 另外,专门在Linux里开个虚拟的Windows来写这个东西——鄙视一下微软的产品对Firefox 4 Linux的支持。另外,真TMD的复杂,真浪费。

Dec 17, 2008 - 1 minute read

emacs简介

emacs一定是我梦想中的编辑器,设计者一定是个超级的混蛋。 emacs是一种多平台的编辑器,具有非常古老的历史,和vi一起并称为黑客常用两大编辑器(在贝壳学习linux后,就“顺带”学习了vi——因为根本没有其他选择)。作为编辑器来说,他只接受文本编辑,但是却具有收发邮件,编译软件,调试程序,甚至煮咖啡等各种诡异的非正经功能。很多人疯狂的热爱他,认为他是人工智能的结晶,化妆成编辑器的操作系统。但也有人疯狂的咒骂他,认为这东西纯粹就是折磨人用的。贝壳这次的blog,就是侃侃emacs到底是什么。 说emacs是人工智能平台,其实这个说法并没有错。emacs的运作机理和我们通常的编辑器都有不同。通常来说,一个编辑器可能有多个windows啦,frame啦什么的,但是最终作用于一个文本。你可以添加,删除,修改,或者标记一段文本,进行剪切,复制,粘贴等动作。设计比较完善的还有回退和重做。让我们专注于其中一个任务,例如,删除,看看我们的编辑器是如何工作的。 以notepad++为例吧,在选中一段文字删除的时候,你可以用键,同样,如果没有选中文字,这个键作用于当前光标后面的一个文字。(在此我们不讨论和前后删除的关系)这很简单,一个内容,按删除,就没了。但是你是否注意了这个过程本身,为什么按下是删除,为什么不是按下键或者键? 按照程序员的思维来说,编辑器的基础是一个文本内容和一个光标(或者说一个position),我们通过修改数据结构变更这两者以达到某种目的,这个过程被称为操作。例如,作为删除操作,我们移除(remove)了文本内容的position处的字符。而后,我们将这个操作(也可以称为函数)绑定到键上。于是,我们在按下键的时候,触发了删除函数,导致内容被删除。这个是能够删除文本的核心过程。从正常人思维的角度来说,一般我们都会将这个功能绑定到上面,而不会是或者,或者其他更疯狂的键。同样的机理,我们按下,文件存盘,是因为存盘的功能被绑定到了这个键上。好的编辑器一般带有键绑定修改功能,notepad++就可以自行修改热键。而emacs则更进一步。 emacs允许你自行编写扩充函数,并且将这些新的函数绑定到键上,这样就赋予了编辑器无限的可能性。例如,你可以写一个过程,每次触发就在当前光标处插入当前时间对应的纽约时间。或者你可以写一个过程,自动根据一个预定义的数据表格补充你输入人名的头衔。可以想象,当你需要重复单一工作时,这种扩充能力是非常重要的。你可以免除记忆一堆领导的详细头衔,免除重复输入,免除繁重的劳动,只要你编写一次扩展程序,并且绑定到某个键上。然而现在编辑器的趋势是,我们使用编辑器从事各种不同的工作。有的时候,我们用编辑器记事,有的时候用来写程序,有的时候用来看源码。因此我们对编辑器的个性化能力和强大都没有要求,反之对编辑器的标准化要求很高。说的更通俗点,我们不需要自行扩充一个插件来省事,但是我们一定要用来复制,用来粘帖。因为我们(指普通用户,而非以电脑为生的专业用户或者是变态的geek)不会程序,或者不喜欢为了某个目地花费时间来编写程序,毕竟现在不是70年代,当时接触电脑的都是智力最高的一帮变态。现在接触电脑的都只是普通用户而已,我们不需要强大的扩充,但是我希望我用一个编辑器的时候,这些基本功能在另外一个编辑器上不会产生区别。从这点来说,emacs差劲透了。 emacs的键绑定是根据上世纪70年代unix下(那时候linus都没出生,何况linux)的键盘来的,因此emacs假定你有一个Meta键。这个键在今天的电脑上已经找不到了,我们用Atl来替代。但是同志们,Atl是系统键,这么替代是有副作用的。例如自动补齐的函数热键是M-Tab,但是请试试在windows下按Atl+Tab。亲爱的,你会跳到另外一个程序上。那是windows切换程序的热键。还有我们经常用来复制,来退回。可是在当时的linux下,代表终止程序运行,代表挂起程序到后台。emacs当然要避免这两个热键,于是——你自己试试在emacs下按这两个热键的结果吧。 从热键约定的角度说,emacs是当之无愧的最差编辑器。不过这个很难怪罪emacs,毕竟他出生的年代不用说windows,连dos都没有出生,cp/m还只是个样品。要怪只能怪windows的设计人员在考虑热键的时候根本没有考虑emacs的现有标准,自己瞎设计一通(尤其是最常用的,虽然从人机工程角度这个是最合适的键)。 emacs更强大的特性是,可以根据当前文件的特征鉴定文件类型,并且采用正确的模式。例如,我可以在python模式下编写python程序,在C++模式下编写C++程序。对于用户来说,这两种模式看不出区别,然而他们本身有着非常多的细节不同。例如,在C++模式下,/**/是注释,而python下,#才是注释。灵活的模式允许你使用同样的方法操作不同类型的文件,并且还具有各种扩充。对于C++,他可以编译,对于python,他可以校验。并且有一些比较常用的超级扩充,例如etags。这个程序可以用来生成一些文件,帮助你找到一个符号的位置。利用这个扩充,你可以快速的寻找符号位置,自动完成,等等。这些近几年才在VSIDE和eclipse里面出现的特性,早在数十年前就出现在了emacs里面。 如果你有程序基础,并且长期从事相似的工作,例如写程序,写文档,并且有很多重复的工作,希望解放自己的劳动力,那么推荐你使用emacs。如果你是个找酷的新新人类,希望找一个很少人用的编辑器,具有真正酷的特性,被很多人称赞,那么建议你用emacs。除此外的人,请珍爱生命,远离emacs——这东西太容易上瘾了。~~~~~~~~~~~~

Dec 15, 2008 - 1 minute read

U盘启动

hihi 大家看过血色星期一没有?那里面有个家伙用随身的U盘当系统带来带去,很酷哎。 贝壳也有个U盘系统盘,做过使用/分区隐藏/Linux启动/密码访问控制,但是基本用不上,首先一个原因就是――太慢。 KST的2GU盘读写速度是5/1.5,貌似用来启动个30多M的系统也够了,可是加上各种检测,时间就远远比硬盘长,而且长很多。所以贝壳正在寻思,什么时候弄个高速(起码要10M)U盘来当系统。分个2G给linux,足够他跑X了,连带编译器什么都可以加上去。 不过在这之前,首先要搞定系统启动问题。混蛋的grub在U盘启动的时候不稳定,一会把U盘当hd0,一会把硬盘当hd0。可以想象,系统启动的时候每次都要手工确认,这种东西鬼才高兴用。而且U盘系统有的时候开关机不稳定,半路死机ext3就损坏,又要拿debian来扫。ext3损坏本来没什么,可是hd识别又出现变化――变的像死机一样。TMD这种鬼环境,加上600M的空间,会用才有鬼了。 先解决这个问题,然后弄个8GU盘来装酷,就这么决定了。 另外,血色星期一的设定弄的很不错,系统是linux(估计是定制的),里面用的是python(就是听说用这个语言才去看的)。不过入侵的时候时间和动作都搞笑了点。真正的入侵往往耗时数天甚至数周,而hack高手也不是拿一堆脚本去淹死服务器的家伙。能够从别人认为完美的地方看出破绽才算入门,而能够从逻辑层面升华到理论的才算是大师。

Dec 12, 2008 - 1 minute read

杭州,火车,咖啡厅

贝壳,黄昏,杭州,城站火车站旁,上岛咖啡,红烧牛肉饭,充电,无线上网,博客,大家,好玩吗?

Nov 23, 2008 - 1 minute read

竞价排名和不作恶

前两个月贝壳才刚说到百度的竞价排名,果然,这回又出问题了,而且还出的很好笑。 央视曝光了百度竞价排名中的一些问题,主要是有很多医疗信息,百度并没有核实来源。此后,百度总裁李彦宏声称,法律没有要求百度对付费信息负责。从法律角度说,这是对的,我们今天说的主题也不是他,而是这个(http://www.cnbeta.com/articles/69964.htm)。 本来曝光百度,怎么转眼变成google了? 看来百度不应该叫搜索引擎公司,而应该叫公关公司。前两个月讲三鹿问题,他是公关。央视曝光医疗问题,他是公关。现在出这个,还在公关。不过你可以公你的关,不代表股东会买你的帐。详细情况大家可以看这里(http://realtime.zaobao.com /2008/11/081120_21.shtml)。 估计我这篇blog的百度排名应该会很低吧—— 下面贝壳废话一下,讲解一下竞价排名的问题,google的价值观和策略。 竞价排名在前两年是一个非常好的模式,通过竞价本身,我们就可以发现很多有价值的信息。例如,我们在搜索IBM的时候,肯花钱的蓝色巨人总比不肯花钱的国际大嘴(International Big Mouth)来的有价值吧。然而问题在于,由于搜索引擎价值的外在性很大,又没有监管,搞不好就要出问题。而且往往不是竞价排名供应商出问题,而是上游下游出,他们没法管。首先我们说外在性的问题,所谓外在性,是指由不应当承担后果的人承担后果的一种状况。好比我在XX地开了一个工厂,生产在欧洲要花很多环保费的东西,破坏了当地的环境。我获得了收入,但是后果由当地人来承担。不论出现的原因,由于外在性的存在,会破坏社会公平,因此很多国家都有补偿外在性的措施。例如排污税,针对富人的高所得税等。竞价排名的外在性在于,有人花钱买排名,并不总是发现价值的过程,也可能是减少价值的过程。而减少价值的损失并不总由百度承担,而是由百度的用户承担。更麻烦的是,这个过程是不可监管的。 我们举例详述整个过程。假定有人在百度竞价买了“流产”(这也是百度最贵的排名)这个关键词,那么,什么人会最乐意去购买呢?我们分析一下流产的潜在市场。正规医院的流产总要通过手续,未成年需要父母签字。很多有钱的小孩宁可多花钱也不希望父母知道,因此他们会选择一些非正规的医院。于是,这些市场一般都是非正规的医院把持的,因为正规医院的收费公开固定,流程有一定监管,肯定没法和这些非正规医院去竞标这个关键词。那么非正规医院中,我们可以想象,应当是付出最高价格的人能够获得这个关键词。如果你按照百度的去,那么你去的地方一定是市场上拥有最高的成本收益比的地方——因为只有这样他才能标到百度的关键词。问题是,什么样的医院会拥有最高的成本收益比?如果是监管医院,这个答案一般是私人贵族医院——如果中国有的话。如果是非监管,那肯定有问题。因为他不能贵族化,收入上不去,又要保证成本收益比,只有降低成本咯。而且医疗系统里面,降低成本普通人根本看不出来。不普通的人——不普通还需要自己找非监管医院么?同样,一些用户不希望被监管的医疗问题中,这个关键词应当也是非常贵的。例如生育,肾亏,等等。这个过程也是不可监管的,百度自己难道还逐个核查竞价排名的真实性?他又如何有权力做这个事情呢? 一家不在监管下的医疗机构,这个问题够严重了吧?但是百度有做什么非法的事情么?没有。从法律角度讲,任何人有权付费将某个信息在百度的排名变更。例如,我可以付费将布什是条狗的网页调整到最高——如果我对布什不爽的话。这个不触犯任何法律,除非你调整有悖法律的关键字。你不能说布什是条狗不是事实,因而不允许我调整排名。那么,百度调整这些有问题的医疗机构的网页,并不能说他触犯了任何一条的法律——从法理上讲是这样的。 通常来说,如果是普通机构,市场会自行调整。如果一个公司提供的信息是违背市场本意的,那么这个公司本身就会被市场淘汰。如果你天天提供广告给我们,我们应当一脚把你踢开。问题是,百度获得了足够的互联网资源,百度搜索是个太重要的东西了。因此他可以屏蔽对自己不利的消息。于是,即使百度有问题,大家也不会知道,直到上面的这幕出现。百度被另外一个媒体的老大——央视——点名,他屏蔽不掉了——总不能屏蔽央视吧?当然,他还是屏蔽了部分消息,并且留下了相当的尾巴。 google的核心哲学观点之一就是“不作恶”。简单来说,就是不因为外力——包括广告,赞助,等等——人工改变排名。google的排名一般有两种变更方法,一种是被发现作弊或者犯规,另一种是更改算法。用google的话来说,即使我们认为某个关键字结果是错误的,修正错误的方法不是我们调整这个页面的pagerank,而是使用更公正的算法,保证每个人在同一个起跑线上。这个和美国法律的精髓如出一辙。即使我认为这个判例是错的,我也不会行政干预这个判决。而是通过议会修正法案来修正法律,保证一个更公正的法律。 至于google的广告,不要误会,google也是卖广告的。google的广告都统一显示在页面的右边,和左边的搜索结果严格分离。大家可以很容易的识别出google的广告。如果你们对广告内容有兴趣,可以点击广告——这是google广告的本意。如果你们对广告内容没兴趣,不强迫你们。这个是“不作恶”的本意。

Nov 12, 2008 - 1 minute read

关于乙肝的一点常识

对于乙肝,贝壳自认为自己了解的已经够多了。至少贝壳知道两对半的意义,作用机理,还有一些乙肝的常识。不过在看了一篇文后,贝壳发现,还是不够多。具体内容可以看这里[1],中国内可能需要穿墙。 认识贝壳的都知道,贝壳是一个偏执于知识和真理的人。然而知识是否一定带来真理?是,也不是。知识未必带来真理,愚昧一定带来恐慌。上文中描述的乙肝患者歧视现象,贝壳并不怀疑。医院里面长长的体检队伍,电视上大量的乙肝药物广告,都是这一现象的残忍注脚。更不提贝壳从事的职业和传播学也有一定关系,自然知道资本和传播结合又没有管制的后果。那么今天,贝壳就着重提出几个乙肝的基础知识,看看大家是否了解。 乙肝是否会终身感染? 根据香港一个资料[2],幼年时感染后会终身感染,成年后感染基本会痊愈。 乙肝感染的方式和概率? 根据这个资料[3],体液交换会传染,包括献血,血液交换,性交和接吻。但是根据上面的文章[1],接吻传染的概率很低。 乙肝对正常人的传染? 根据资料[3]的说法,只要不发生血液污染,即使是夫妻这样亲密常接触的人,只要接种疫苗就可以防护。同时根据上一个问题,多数情况下你没感觉呢就痊愈了。作为80后的城市青年,贝壳记忆中从初中开始接种过三次乙肝疫苗,应当是终身免疫。 乙肝的后果和概率? 根据文档[1]的说法,也许运气不好的话(大三阳伴随谷丙/谷草异常)会肝功能受损(总体的20%),严重的引发肝硬化(受损的4%,总体的0.8%),少量的会形成肝癌(受损的0.4%,总体的0.08%)。按照当前中国全部乙肝患者全为大三阳肝功异常计算,会有96K人患上肝癌。如果考虑实际情况,大概会有1W人上下吧。 ——如果您觉得很多,查查死于心脏病和高血压的人数,再想想您今天的午餐。 乙肝歧视的后果? 计划生育的后果是多出来的男性可以组建一支军队,而乙肝歧视的后果就是患病,无工作的1.2亿人口。——想想这帮人急了拿个针头在你家楼下扎人。 参考: [1].http://item.feedsky.com/~feedsky/my1510/~5935684/129964642/1488578/1/item.html [2].http://www.hku.hk/uhs/he/hep/chi-hepc.html [3].http://www.hbver.com/Article/ygfz/ygzs/200511/4413.html

Nov 10, 2008 - 1 minute read

SCIP,lambda,Church

贝壳最近在看SCIP,感觉受益匪浅。其中有一个2.6,使用函数表达数字,很难理解。贝壳查了查资料,这篇(http://blogs.sun.com/yongsun/entry/lambda%E6%BC%94%E7%AE%97%E4%B8%8Echurch%E8%AE%A1%E6%95%B0 )写的很好,贝壳就不多说了。贝壳把自己写的内容贴上来,作为一个借鉴。 (define zero (lambda (f) (lambda (x) x))) (define one (lambda (f) (lambda (x) (f x)))) (define two (lambda (f) (lambda (x) (f (f x))))) (define three (lambda (f) (lambda (x) (f (f (f x)))))) (define (add-1 n) (lambda (f) (lambda (x) (f ((n f) x))))) (define (add m n) (lambda (f) (lambda (x) ((m f) ((n f) x))))) (define (mult m n) (lambda (f) (m (n f)))) (define (show-func-number n) (define (inc x) (+ x 1)) ((n inc) 0)) (display (show-func-number zero)) (newline) (display (show-func-number one)) (newline) (display (show-func-number (add-1 one))) (newline) (display (show-func-number (add one two))) (newline) (display (show-func-number (mult two three))) (newline) 结果: