天空随想

春眠不觉晓,

处处闻啼鸟.

夜来风雨声,

花落知多少.

《念奴娇·赤壁怀古》
苏轼

大江东去，
浪淘尽、
千古风流人物。
故垒西边，
人道是、
三国周郎赤壁。
乱石崩云，
惊涛裂岸，
卷起千堆雪。
江山如画，
一时多少豪杰！
遥想公瑾当年，
小乔初嫁了，
雄姿英发。
羽扇纶巾，
谈笑间、
樯橹灰飞烟灭。
故国神游，
多情应笑我、
早生华发。
人间如梦，
一樽还酹江月。

南京暴雨的下午。一个男孩在雨中骑自行车。非常的犹豫，不知道应该骑的快一点还是慢一点。他边骑边计算怎样淋的雨会少。他非常苦恼，不知道怎样才好。所有听到的人都在大笑。

看到这里我突然想起来我高中的时候也思考这个问题，可是那个时候没有得到结果，直到我进了大学后通过建模的方法才彻底解决了这个问题。

建模的方法是我在粒子的里学到的，常常一个非常复杂的数学问题，或者一个难以下手的实际问题，都是可以通过建模来实现的。

下面我介绍一下我对这里淋雨问题的建模和求解，当然，简化的的求解方法，不见得全面。

１．我们先对雨进行建模，我们先进行最少参数的简化建模。假设雨点是一个均匀分布和垂直往下降落的物体，就会有以下参数：
v 下降速度
r 雨点的大小
n 单位面积雨点的个数
l 两个雨点上下相距的长度

２．下面我们对在雨中行走，奔跑的人进行建模。我们的模型是简化人为一个圆柱体，分两个参数，高度和直径：
h 身高
w 就是人的宽度
s 就是人跑或者走的速度
L 两建筑物（点）之间的距离

３．初步的计算
我们对人进行了简化后实际上人能够接收到雨点的地方只有两个：
横截面　和　纵向
我们先计算横截面接受到的雨滴数目

３．１ 横截面（头顶接收到的雨量）
这个雨量就应该是人头顶单位时间内接收到的雨量乘以时间
人跑完L 需要的时间： L/s
这个时间共接收到雨量的体积是：(L/s)*v*(pai/4)*w*w
那么全部的雨滴数目：
((L/s)v)*(pai/4)w*w*n/l
全部的水的体积是：
((L/s)v)*(pai/4)w*w*n/l*(4/3)*(pai)*r*r*r

３．２ 纵向面（迎面接受到的雨量）
这个雨量就是人身子扫过的横断面乘以长度，这个体积是：
w*h*L
全部的雨滴的个数是：
w*h*L*n/l
全部的水的体积是：
w*h*L*n/l*(4/3)*(pai)*r*r*r

４．总的水量：
((L/s)v)*(pai/4)w*w*n/l*(4/3)*(pai)*r*r*r+w*h*L*n/l*(4/3)*(pai)*r*r*r
=n/l*(4/3)*(pai)*r*r*r*(L*v*w*w*pai/s/4+w*h*L*)

因此可以看出来，速度s是总的水量的一个函数，而且随着s的提高，总的水量在下降。因此从这个简单的模型里说，要最少的被雨淋湿，就要跑的快，越快头上的水越少。

５．当雨的方向不是垂直向下
这点我没有进行特别的计算，有兴趣的可以继续求解。

1引言

　　构建IC卡应用系统过程中，如何定义卡中的数据信息（相对逻辑加密卡）或卡中的应用类型及其数据信息（相对CPU卡）及将数据信息写入卡中，以便应用于系统中进行交易是一个重要环节。这一环节在业界通常称为卡片个人化。卡片个人化既可以在专门的设备机器上进行，以便于对大批量的卡片进行个人化；也可以在PC机上通过连接IC卡读写器进行，以便于对小批量的卡片进行个化。不管硬件设备如何，都必须设计一套程序软件来进行个人化。这个程序软件通常称为发卡程序。本文讨论CPU卡发卡程序设计过程中将会遇到的关键技术问题及其解决方法。

　　CPU卡发卡大体可分为三个组成部分：（1）卡结构建立；（2）密钥写入；（3）个人化数据写入。当然，为确保正确发卡，程序设计过程中最好是采用一边建立卡结构，一边写入密钥和个人化数据。

　　2发卡前的准备工作

　　一般地，卡片供应商提供卡片时，已经对卡片进行过初始化（主要用于对卡片进行测试），亦即卡片上已经建立了主文件（MF）及主密钥文件（MF下的Keyfile文件），主密钥文件中也已写入了初始卡片主控密钥。

　　在对CPU卡建立特定的卡结构及写入密钥和数据之前，程序设计中的第一步应该对卡片进行外部认证。外部认证所使用的密钥正是初始卡片主控密钥。

　　当完成外部认证后，接下来最好是擦除卡片上已有的卡片结构，然后再开始重新建立卡片结构。

　　许多发卡程序在设计过程中，没有考虑到擦除卡片上已有的卡片结构，而是在完成外部认证后直接改写原有卡片的主密钥文件的卡片主控密钥。常见问题是由于原有主密钥文件创建时的空间大小不够，而发卡程序试图写入除卡片主控密钥外还想写入卡片维护密钥时，势必造成写入空间不够而导致写入不成功。

　　3密钥文件的建立与密钥值的写入

　　为了独立地管理一张卡上不同应用之间的安全问题，CPU卡中的每一个应用放在一个单独的ADF中。各个ADF及其下属各文件数据的访问（包括改写、读取）只能应用该ADF下的密钥文件中的密钥数值。为讨论方便，此处假设只有一个ADF。

　　用户卡结构中主要存在以下两个密钥文件及相应的几个密钥：

　　(1)MF下的密钥文件(简称KMF)，其装载的密钥是卡片主控密钥(简称CCK，以下同)；

　　(2)ADF下的密钥文件(简称KADF)，其装载的密钥有应用主控密钥(简称ACK，以下同),应用维护密钥(简称AMK)，及其它应用密钥；

　　(3)其它密钥，如口令密钥PIN，口令解锁密钥，DES运算密钥等等。

　　3.1密钥文件的创建

　　各密钥文件在建立时必须慎重考虑以下两个要素:

　　(1)文件大小的分配；

　　(2)有关权限和密钥使用后的后续状态值的规定。

　密钥文件的大小分配取决于要装载的密钥个数。每个密钥均为一条可变长的记录，每条记录的长度为密钥数据长度加7。以此可以计算密钥文件的大小。在发卡程序设计过程中，常常会出现因为密钥文件的大小分配不够而造成后面的密钥无法写入。

　　密钥文件建立过程中的有关权限和密钥使用后的后续状态值的规定一方面起到对密钥文件本身的安全维护作用，另一方面也将决定对卡片操作的流程。显然这个要素至关重要。

　　3.2各密钥值的写入

　　关于密钥值的写入，关键问题是要弄清楚该密钥要求以何种形式写入。通常有以下几种形式：

　　(1)以明文形式写入（常见的如口令密钥PIN的写入）；

　　(2)以带线路保护的形式写入（要求计算MAC）；

　　(3)以对密钥值进行加密后的密文形式写入（要求计算DES或3DES）；

　　(4)以对密钥值进行加密并带线路保护的形式写入（要求计算DES＆MAC）。

　　如果密钥值的写入要求加密并带线路保护，则密钥值写入时须对该密钥值进行DES＆MAC计算后以密文形式写入（当然卡片操作系统内部会自动将其解释成明文），带线路保护的目的是防止密钥值在写入的过程中被劫取。如果不要求带线路保护写入，可直接以明文方式写入。

　　在发卡程序设计过程中，尤其要注意卡片主控密钥、应用主控密钥、应用维护密钥及其它密钥之间的关系及其写入要求。

　　3.2.1卡片主控密钥与应用主控密钥

　　卡片主控密钥是对整个卡片的访问起控制作用的密钥，由卡片生产商写入，由发卡方替换为发卡方的卡片主控密钥。发卡程序设计过程中,在对卡片进行任何操作之前,必须使用卡片主控密钥作外部认证,

　　应用主控密钥是应用的控制密钥，在卡片主控密钥控制下写入。一般地，发卡方替换卡片的主控密钥之后，为验证替换工作正确，再用新的卡片主控密钥作一次外部认证。

    

    所谓为人做事分为四种:

    1.利人利己

    2.不利己,但是利人

    3.不利人,但是利己

    4.又不利人,又不利己

    当然明眼人一看就知道,第一种互利型的处事方式是最理想的,我们通常称那种人为"好人".第二种,我想很多人都不会去选择,因为实在是违反了社会主义市场经济的准则,本人不是很推崇这种处事方式,这种人,我们通常称之为"善人".第三钟,是在第一种没有办法被实施情况下的优先预案,很多人都对此钟爱有加,因为在某些特定的情况下,这样做可以使你获得最高利益,对于这种人,我们称之为"聪明人",当然有不屑或所谓行为高尚者称之为"小人".第四中就是绝对没有任何优势可言了,"傻子"是别人对他自己,以及他自己使用最多的称谓了,我想没有一个人会喜欢和这种人打交道的了.