算法

区块链主流共识算法分析 区块链可以概括为一个分布式的高频交易系统，其核心的技术可以总结为四个部分:分布式的数据库，密码学相关理论，共识机制和P2P网络。本文将详细探讨目前主流的区块链共识算法。 共识算法与CAP理论 要探讨共识算法，首先就需要了解计算机中的 CAP 理论。 CAP 是由 Eric Brewer 在2000年PODC会议上，提出分布式系统不能同时完全满足三个要求的假设,其中包括以下三个方面: Consistency : 一致性，是指在分布式系统中的所有数据备份,在同一时刻是否具有同样的值。 Avaliability ：可用性，是指在集群中一部分节点故障后，集群群体是否还能响应客户端的读写请求。 Partition tolerance ：分区容错性，以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。 和所有的分布式系统一样，区块链共识算法设计也是在权衡上面的三个因素。假设区块链中的节点能够立即确认交易数据，这就满足了 CAP 理论中的 AP ,可风险是失去了数据的强一致性，因为其他节点可能丢弃这个区块，因为区块所在的区块链分叉在竞争性的选举中失败了；如果是为了获得强一致性，即满足 CP 的话，那么客户端应该等待区块链中的大多数节点都接受了这笔交易后才能真正的接收它

策略模式 在GOF的《设计模式:可复用面向对象软件的基础》一书中对策略模式是这样说的：定义一系列的算法，把它们一个个封装起来，并且使它们可相互替换。该模式使得算法可独立于使用它的客户而变化。 策略模式为了适应不同的需求，只把变化点封装了，这个变化点就是实现不同需求的算法，但是，用户需要知道各种算法的具体情况。就像上面的加班工资，不同的加班情况，有不同的算法。我们不能在程序中将计算工资的算法进行硬编码，而是能自由的变化的。这就是策略模式。 UML类图 Strategy：定义所有支持的算法的公共接口。Context使用这个接口来调用某ConcreteStrategy定义的算法； ConcreteStrategy：实现Strategy接口的具体算法； Context：使用一个ConcreteStrategy对象来配置；维护一个对Stategy对象的引用，同时，可以定义一个接口来让Stategy访问它的数据。 使用场合 当存在以下情况时使用Strategy模式： 许多相关的类仅仅是行为有异。“策略”提供了一种用多个行为中的一个行为来配置一个类的方法； 需要使用一个算法的不同变体； 算法使用客户不应该知道的数据。可使用策略模式以避免暴露复杂的、与算法相关的数据结构； 一个类定义了多种行为，并且这些行为在这个类的操作中以多个条件语句的形式出现

背景 首先呢，我们讲一下今天我们要说的：算法复杂度分析——背景。 继续讲下我们在面试的过程中被面试官问道算法时，肯定会问到你算法复杂度，例如：时间复杂度，空间复杂度。 有没有更好的算法，来处理某一个业务场景遇到的瓶颈？ 以上这些都是我们会经常碰到的问题。 为什么讨论算法的复杂度？ 算法两个主要方面 正确：算法功能与问题要求一致？ 成本：运行时间 + 所需存储空间 =》 如何度量？ + 如何比较？ 算法复杂度分析的动机 如何度量： 设计的这个算法如何？跑得是不是足够快？ 随着问题规模的增长会怎样变化了？ 如何比较？ 同一个问题有多种不同的算法，如何判断其优劣了？ 直接想法 – 实验测试 把代码跑一遍，通过统计、监控，就能得到算法执行的时间和占用的内存大小 实验测试难以准备反映算法的效率 - 测试环境和测试数据各异 不同的算法可能适应不同的输入规模 不同的算法可能适应不同类型的输入 同一个算法，可能由不同的程序员、用不同的语言、由不同的编译器编译 同一个算法，可能被运行在不同的 OS 、不同体系结构的计算机上 为了给出一个客观的评判断，需要抽象出一个理解的计算模型 不依赖于上述各种具体因素，准确测量和评价算法 RAM(Random Access Model) 1. 指令一条接着一条执行（串行） 2. 指令包含了真实计算机的常见指令 ，例如： 算术指令（加法，减法，乘法，除法，取余

前言： 此文算是我过去一年的工作总结，作为一个萌新算法工程师，尽自己所能把一个算法模型的工程化实现介绍明白。从最原始的数据出发，到最后模型的predict结果。我围绕着计算广告中的ctr预估模型来进行一步步介绍。 技术框架： 整体广告系统的技术框架比较复杂，在我们算法组这边主要是redis,kafka,spark,hadoop,hive,hbase,clickhouse等 redis:主要用来特征缓存，比如用户的一些频次特征会在adx检索时进行关联，频次特征写入redis缓存我们的解决方案是重写mapreduce的OutputFormat函数，将map结果直接写入到redis，采用多进程，一小时可以将3亿用户的频次特征入库完成，理论上可以7分钟完成，但进程数多了之后会不会发生互斥没去细究，一个小时可以满足需求。 kafka:目前的kafka主要是日志落地，后边我们会考虑hdfs+kafka做分布式训练 spark：主要是lr模型 hadoop：mapreduce支撑整个数据流的基础 hive：今年完成了数据流的sql化，主要是以UDF函数的形式简化操作，更方便管理 hbase:之前是五分钟级别的离线特征存储，现已弃用了似乎 clickhouse：支持报表平台的频繁查询操作 整体流程： 数据准备 特征抽取 特征统计/分析 生成特征字典 特征编码 训练数据采样 样本binary

今日大年初二，期望武汉疫情早日控制！！ 单源最短路 以PTA 7-35 城市间紧急救援 (25分)为例 题目 该题目要求给出从相应起点出发所得到的最短路，于是考虑单源最短路的Dijkstra算法。 Dijkstra算法 算法可以得到由指定起点出发到达其他结点的最短路径长度。 实现步骤： 初始化距离数组为INF 扫描邻接矩阵，加入起点，更新距离数组 外层有N-1层循环，每层循环找到距离最小且未被访问的结点，加入该结点，更新距离数组。 全部执行完之后，将可以得到一个长度为结点数目的数组，该数组存储了由结点到达其它结点的最短距离。另外，该题目还需要输出最短路径的条数以及路径，所以在更新距离数组时，需要将距离相同的路径条数以及经过的路径进行记录。 AC代码如下： # include <bits/stdc++.h> # include <cstdio> # include <cstdlib> # include <iostream> # include <algorithm> # include <string.h> # define ll long long # define INF 10000 # include <map> # include <stack> # include <queue> # include <stdio.h> # include <string.h> using

//算法训练——暗恋 //思路：枚举 #include<stdio.h> #define MAX 200 int map[MAX][MAX]; int judge(int x,int y,int cur){ //判断以（x,y）为左上角、长度为cur，能否构成一个纯色的正方形 int color; color = map[x][y]; for(int i=x;i<x+cur;i++){ for(int j=y;j<y+cur;j++){ if(color != map[i][j]) return 0; } } return 1; } int main(){ int i,j,curMax,maxWidth,row,col; scanf("%d%d",&row,&col); for(i=0;i<row;i++) for(j=0;j<col;j++) scanf("%d",&map[i][j]); for(i=0;i<row;i++){ for(j=0;j<col;j++){ while(1){ if(judge(i,j,curMax) == 1){ maxWidth = curMax; curMax++; } else break; } } } printf("%d",maxWidth*maxWidth); return 0; } 　　 来源： https://www.cnblogs

概述 垃圾收集 Garbage Collection 通常被称为“GC”，它诞生于1960年 MIT 的 Lisp 语言，经过半个多世纪，目前已经十分成熟了。 jvm 中，程序计数器、虚拟机栈、本地方法栈都是随线程而生随线程而灭，栈帧随着方法的进入和退出做入栈和出栈操作，实现了自动的内存清理，因此，我们的内存垃圾回收主要集中于 java 堆和方法区中，在程序运行期间，这部分内存的分配和使用都是动态的。 垃圾收集器(garbage collector (GC)) 是什么？ GC其实是一种自动的内存管理工具，其行为主要包括2步 在Java堆中，为新创建的对象分配空间 在Java堆中，回收没用的对象占用的空间 为什么需要多种GC？ 首先，Java平台被部署在各种各样的硬件资源上，其次，在Java平台上部署和运行着各种各样的应用，并且用户对不同的应用的 性能指标 (吞吐率和延迟) 预期也不同，为了满足不同应用的对内存管理的不同需求，JVM提供了多种GC以供选择 性能指标 最大停顿时长：垃圾回收导致的应用停顿时间的最大值 吞吐率：垃圾回收停顿时长和应用运行总时长的比例 不同的GC能满足不同应用不同的性能需求，现有的GC包括： 串行化GC(serial garbage collector)：适合占用内存少的应用 并行GC 或 吞吐率GC(parallel or throughput

货郎问题(Traveling Salesman Problem，简称“TSP”)也叫货郎担问题，中国邮路问题，旅行商问题等,是计算机算法理论历史上的经典问题。在过去几十年中，它成为许多重要算法思想的测试平台，同时也促使一些新的理论领域的产生，比如多面体理论和复杂性理论。 货郎问题：给定n个结点和任意一对结点{i，j}之间的距离为dist(i，j)，要求找出一条闭合的回路，该回路经过每个结点一次且仅一次，并且该回路的费用最小，这里的费用是指每段路径的距离和。 货郎问题求解其精确解是NP难的，并且求解任意常数因子近以度的解也是NP难的。若将问题限定在欧氏平面上，就成为欧氏平面上的货郎问题,也叫欧几里德旅行商问题(Eculid Traveling Salesman Problem)。但是，即使是欧氏平面上的货郎问题也是NP难的。因此通常用来解决TSP问题的解法都是近似算法。其中第一个欧几里德旅行商问题的多项式近似算法是Arora在1996年使用随机平面分割和动态规划方法给出的。 J.L. Bentley 建议通过只考虑双调旅程(bitonic tour)来简化问题,这种旅程即为从最左点开始，严格地从左到右直至最右点，然后严格地从右到左直至出发点。下图(b)显示了同样的7个点的最短双调路线。在这种情况下，多项式的算法是可能的。事实上，存在确定的最优双调路线的O(n*n)时间的算法。 　 注

1.cocos2dx 3.0 auto batch http://blog.csdn.net/musicvs/article/details/28226299 2.Lua __index,__newindex,rawget和rawset http://blog.csdn.net/wangbin_jxust/article/details/12108189 http://nova-fusion.com/2011/06/30/lua-metatables-tutorial/ 3.换装实现： http://cn.cocos2d-x.org/tutorial/show?id=2607 4.LUA （ !!!!!!!! ） http://wuzhiwei.net/ 5.Mac 下 Android手机不被eclipse识别的解决办法 http://blog.csdn.net/wk3368/article/details/38382939 理解A*寻路算法具体过程 http://www.cnblogs.com/technology/archive/2011/05/26/2058842.html 来源： https://www.cnblogs.com/kelisi-king/p/4428562.html

画了一系列树的动画，从二分搜索树，到AVL树，再到2-3树，再到基于2-3树的红黑树，都可以发现这些树都跟二叉查找树很像啊。 嘿嘿！二分搜索树就是二叉查找树；AVL树也是一颗二分搜索树，只多了高度差的限制；2-3树虽满足二分搜索树的性质，但不是一颗二分搜索树，2-3树由2-节点和3-节点组成的，满足了完美平衡性；基于2-3树的红黑树就是希望不要有3-节点，将3-节点转换成二叉，两个元素之间由红链接相连，并约定谁是子节点谁是红的，如下图。 本篇文章还会继续介绍满足二分搜索树性质的一棵树，它是2-3-4树，和2-3树一样也不是一颗二分搜索树。它在2-3树的基础上可以存储4-节点，4-节点由三个元素组成，有四个子树。 查找元素 和二分搜索树一样，根据元素的大小来决定查找的方向。要判断一个元素是否存在，我们首先将待查找元素和根节点逐一比较，如果它和当前节点中的一个元素相等，就返回查找命中；如果它比当前节点任一元素要大，就选择右递归进行下一个节点；如果它比当前节点任一元素要小，就选择左递归进行下一个节点；直到树底下的空节点，返回查找未命中。 插入元素 我们知道2-3树树底下最多是3-节点，可以直接插入元素然后再判断是否是4-节点，如果是向2-节点插入一个元素，变成3-节点无需分解；如果是向3-节点插入一个元素变成4-节点，进行向上变换将中间的键合并到父节点，如果父节点也变成4-节点