Category 编程研究

import numpy as np x1 = ; x2 = ; star = ; yuandan= pos1 = 0; pos2 = x2.index(x1) for i in range(0,72): #九宫位置 pos3 = x1 pos4 =…

Read More

甲子本命王文卿，從官十八人，貪狼星元辰。乙未杜仲陽，十六人。女。癸巳史公來，從官九人。 乙丑本命龍季卿，從官十六人，臣門星元辰。甲午衛上卿，從官十八人。女。丙申朱伯衆，從官十四人。 丙寅本命張仲卿，從官十四人，祿存星元辰。丁酉臧文公，從官十二人。女。乙未杜仲陽，從官十六人。 丁卯本命司馬卿，從官十二人，文曲星元辰。丙申朱伯衆，從官十四人。女。戊戌范少卿，從官　十人。 戊辰本命季楚卿，從官　十人，廉貞星元辰。己亥鄧都卿，從官十三人。女。丁酉臧文公，從官十二人。 己巳本命何文昌，從官十三人，武曲星元辰。戊戌范少卿，從官　十人。女。庚子楊仲昇，從官十七人。 庚午本命馮仲卿，從官十七人，破軍星元辰。辛丑林衛卿，從官十五人。女。己亥鄧都卿，從官十三人。 辛未本命王文章，從官十五人，武曲星元辰。庚子楊仲昇，從官十七人。女。壬寅丘孟卿，從官十三人。 壬申本命侯博卿，從官十三人，廉貞星元辰。癸卯蘇他家，從官十一人。女。辛丑林衛公，從官十五人。 癸酉本命孫仲房，從官十一人，文曲星元辰。壬寅丘孟卿，從官十三人。女。甲辰孟非卿，從官十四人。 甲戌本命展子江，從官十四人，祿存星元辰。乙巳唐文卿，從官十二人。女。癸卯蘇他家，從官十一人。 乙亥本命龐明心，從官十二人，巨門星元辰。甲辰孟非卿，從官十四人。女。丙午魏文公，從官十六人。 丙子本命邢孫卿，從官十六人。貪狼星元辰。丁未石叔通，從官十四人。女。乙巳唐文卿，從官十二人。 丁丑本命趙子玉，從官十四人，巨門星元辰。丙午魏文公，從官十六人。女。戊申范伯陽，從官十二人。 戊寅本命虞子張，從官十二人，祿存星元辰。己酉成文長，從官十五人。女。丁未石叔通，從官十四人。 巳卯本命石文陽，從官十五人，文曲星元辰。戊申范伯陽，從官十二人。女。庚戌史子仁，從官十三人。 庚辰本命尹佳卿，從官十三人。廉貞星元辰。辛亥左子行，從官十一人。女。己酉成文長，從官十五人。 辛巳本命陽仲公，從官十一人，武曲星元辰。庚戌史子仁，從官十三人。女。壬子宿上卿，從官十五人。 壬午本命馬子明，從官十五人，破軍星元辰。癸丑江漢卿，從官十三人。女。辛亥左子行，從官十一人。 癸未本命呂威明，從官十三人，武曲星元辰。壬子宿上卿，從官十五人。女。甲寅明文章，從官十六人。 甲申本命扈文長，從官十六人，廉貞星元辰。乙卯戴公陽，從官十四人。女。癸丑江漢卿，從官十三人。 乙酉本命孔利公，從官十四人，文曲星元辰。甲寅明文章，從官十六人。女。丙辰霍叔英，從官十二人。 丙戌本命車元昇，從官十二人。綠存星元辰。丁巳崔巨卿，從官　十人。女。乙卯戴公陽，從官十四人。 丁亥本命張文通，從官　十人，巨門星元辰。丙辰霍叔英，從官十二人。女。戊午從元光，從官十四人。 戊子本命樂石陽，從官十四人，貪狼星元辰。己未時通卿，從官十七人。女。丁已崔巨卿，從官十人。 己丑本命范仲陽，從官十七人，巨門星元辰。戊午從元光，從官十四人。女。庚申華文陽，從官十五人。 庚寅本命褚進卿，從官十五人，綠存星元辰。辛酉郵元玉，從官十三人。女。己未時通卿，從官十七人。 辛卯本命郭子良，從官十三人，文曲星元辰。庚申華文陽，從官十五人。女。壬戌樂進卿，從官十一人。 壬辰本命武稚卿，從官十一人，廉貞星元辰。癸亥左石松，從官　九人。女。辛酉郵元玉，從官十三人。 癸巳本命史公來，從官　九人，武曲星元辰。壬戌樂進卿，從官十一人。女。甲子王文卿，從官十八人。…

Read More

设计模式主要是针对面向对象的思考方法，即将万物都抽象成类来描述，然后基于类生成具体的对象。 这个类其实就是一个模板，所以最基础的设计模式便是模板模式，模板模式非常简单，即定义一个基类，然后给出来一些虚拟或抽象方法，具体的实现在子类中完成，这是面向对象编程里最基础也最简单的用法。 如一篇文章，它有标题，有内容，那么这个就可以成为一个模板，标题作为一个方法，内容作为一个方法，这样子类中返回的字符不同，便能够成为不同的类型文章，如在标题字符串描述里，可以是有有图像与无图像的。 模板方法强调在对基类的调用上拥有统一的接口，这样才能够实现足够的延展性，它强调的是模板式。 而更进一步，如果仅仅接口方法只是很少量时，可以视作为策略模式，比如定义一个方法名称，是两个整型参数，在方法内部可以实现加法，也可以实现减法，也可以实现乘法等各种处理，在外部看来选择不同的继承类，就能够实现不同的功能，所以这就成为了策略模式。 策略模式与模板模式的最大区别在于，策略模式关注的是实现选择，而这个在策略模式中，通常是引入一个Context 的上下文类，策略本身的基类是策略模板，而选择什么策略，则由Context 来负责调用。 为什么要有一个Context，比如出现多个策略需要连续判断时，Context调用一个策略类的方法后，还可以记录下该策略的结果，然后带着上个的结果传入到下一个策略方法中，然后再进行计算。 换句话说，引入Context上下文类创建的对象，目的就是为了记录并传递策略的结果，所以它可以是上下文相关的。 一种常见场景就是用Context记录当前运算状态或步骤，比如处理一张图片，先进行了灰度处理，然后再进行提轮廓，因为有了上下文的对象，系统随时可以知晓当前的状况，无论对于异步处理还是多线程编程都是非常有益的。 对于能直接新建的对象，只需要直接创建就好了，但是总是事不如人意的，有时候对于产生的对象是需要统一管理的，尤其是复杂的对象，同时并不需要上下文有那么密切的相关性。 比如说生产一辆轿车后，再生产一辆卡车，这是基于不同需求的选择，但是生产轿车与生产卡车之间并无上下文联系的需求，它们甚至是可以进行同步进行的。 这种情况下，无疑可以考虑使用工厂模式，在同一个工厂出厂的对象无疑都可以打上相应标志，并且事后无论是要统一销毁还是怎么处理，都会非常方便。 工厂模式中只关心产生对象，所提供的方法接口，对于产生的顺序或是之间需要什么组合要求，并不关心。 简单的工厂对于一些简单场景是很有用的，比如说，一个日志记录，是记录到硬盘还是记录到内存还是记录在哪里，可以用工厂产生记录对象来后期决定。 但是打开工厂方法，对于一辆车的内部流程，涉及到了具体的组装时，就需要采用不同的方法进行构建。 这种构建的流程大多是可以复用的，比如给封闭轿车安轮子与给敞篷型轿车安轮子，并没有不同的地方。 但是一辆车安车顶与安轮子显然是两个不同的活，这个无法直接通过策略模式完成，因为策略模型可以关心完成安什么样的轮子，安轮子的步骤，却在概念上不能组装车子。 所以在这里又有了构建者模式，构建者模式中，复杂的构建与其表示相分离，它类似于策略模式，但是来源的构造并不基于同一个策略类。 一系列策略可以构成同一类零件，而不同零件可以构成不同的部件，而不同部件则可以构建出一个成品。 这就是它们的区别，在构建者模式中，包含了零件与部件，比如说一辆车可以安个圆顶，也可以安个方顶，那么这可以用构建者模式来实现圆顶构建者或方顶构建者。 构建者模式的最大特点是：它是可以在现有对象上，将不同部件组成一个新对象。 如一个汉堡，用纸装或用盒子装，而装的汉堡可能用奥尔良鸡腿，也可能是用油炸鸡腿所构成，而到底是用纸或盒还是用什么鸡腿，这之间并无任何关系，这就比较适合用构建者模式。 对象之间的关系并不是完美而简单的，有时候会出现相互对象的依赖，这会非常麻烦，最有效的方法是除了统一调度外，还必须考虑有意外的情况，从而能够进行临时调度。 比如高铁的各个列车，它们的先后次序很重要，需要并行不紊的进行，如果依赖于高铁列车之间相互通讯必然会引起混乱，因为消息的传播效率很低。 所以这就需要一个广播机制，一个中介的对象来与其它对象之间进行交互，这就好比一个数据中心，而其它对象只是各个终端，所有的终端都只与数据中心进行通讯。 这种情况所设立的中心，被称为中介者，将数据广泛发给所有的其它相应对象可以看到，这就类似于一个频道，然后所有的对象信息都在这上面进行交互。 这种星型结构，也是现代网络最常见的结构，就目前来说它是一个相对较好的方案。 对于终端的接入，有时候需要判断的它的状态，例如是否已经接入，或是已经断开，以确定数据可以发送，这种情况称为事件。…

Read More