（以下描述，均不是学术用语，仅供大家快乐的阅读）
之前没见过这玩意，从百度百科截个图。樽海鞘看起来像是透明的鱼但又不是鱼，是一种无脊椎动物，不知道它能不能吃，味道如何 :）。
樽海鞘算法借鉴了樽海鞘聚集的生活习性，算法提出于2017年，距今也有几年时间了。在有性时期和无性时期，樽海鞘有着不同的行为，无性时期，樽海鞘们会组成长链。
为了模拟樽海鞘的习性，在樽海鞘算法中，将群体分为了两部分，头部和尾部，头部寻找食物，而尾部则跟随头部。
樽海鞘算法中每只樽海鞘的位置为 ，该位置的优劣由其适应度函数
计算得出。
种群在解空间内随机初始化后，会根据其适应度函数，从优到劣排序，随后将种群按顺序分为两组，第一组为leader,第二组为follower。Leader会在全局最优位置附近寻找新位置，而follower则是紧跟着自己的前一个个体。
种群中有1/2的个体为leader，它们会在当前全局最优位置附近搜索，其具体实现如下：
每个个体会随机选择公式（2）（3）其中的一个进行移动。公式（2）（3）的含义很明显，已最优位置为起点，以解空间内随机位置为步长和方向走了一步。
结合图像公式（2）（3）可以看出leader其实是在做全局搜索，搜索范围比较大。即使迭代到最后C1取值最小时仍有0.0366，乘以较大的步长，应该也是一个不小的值，故其搜索范围较大。
跟随者的行为特别简单，就是移动到排在自己前面的个体和自己的中点位置。
从公式（4）可以得知，该部分个体在群体较为分散时作用不太大，当群体集中时能够快速提高算法的精度，属于小范围局部搜索。
该算法没有贪心步骤，樽海鞘的新位置即使差于原位置，它依然会移动到新位置。加之follower的行为，它的运动图像一定非常的有意思。
适应度函数。
实验一：
| 问题维度(维度) | 2 |
| 总群数量(种群数) | 20 |
| 最大迭代次数 | 50 |
| 取值范围 | （-100，100） |
| 实验次数 | 10 |
从图像可以看出群体组成的樽海鞘链还是有比较明显的辨识度的。群体收敛速度虽然一般但是明显是找到了最优位置。
| 值 | |
|---|---|
| 最优值 | 1.1132229918179271E-10 |
| 最差值 | 2.9571940843091835E-9 |
| 平均值 | 6.819800231198109E-10 |
从结果可以看出算法非常的稳定，得到的结果也有非常高的精度。
该算法没有使用贪心算法，依旧能快速收敛。这主要由于全局最优位置其实是一个单调变优的位置，随着迭代次数的增加，C1的值会越来越小，leader的搜索范围也会逐渐集中到最优位置附近。
樽海鞘算法模拟了樽海鞘的聚集成链的生活习性而提出的优化算法。算法将群体分为leader和follower，leader以全局最优为中心进行搜索，为算法提供了全局搜索能力，保证种群收敛，follower跟随自己的前一个个体，为算法提供了局部搜索能力，保证算法精度。
可以看出樽海鞘算法的模型十分简单，实现过程也简单明了，同时算法也有的不错的效果。可能唯一的不足之处就是算法后期缺少跳出局部最优的步骤，不过前期的搜索范围还是比较广泛的，（如果问题不太复杂）陷入局部最优的概率应该也不大。
参考文献
Mirjalili S , Gandomi A H , Mirjalili S Z , et al. Salp swarm algorithm: a bio-inspired optimizer for engineering design problems[J]. Advances in Engineering Software, 2017, 114(dec.):163-191. 提取码：175q
原文代码 提取码：175q
以下指标纯属个人yy,仅供参考
| 指标 | 星数 |
|---|---|
| 复杂度 | ★☆☆☆☆☆☆☆☆☆ |
| 收敛速度 | ★★★★☆☆☆☆☆☆ |
| 全局搜索 | ★★★★☆☆☆☆☆☆ |
| 局部搜索 | ★★★★★★☆☆☆☆ |
| 优化性能 | ★★★★★☆☆☆☆☆ |
| 跳出局部最优 | ★★☆☆☆☆☆☆☆☆ |
| 改进点 | ★★☆☆☆☆☆☆☆☆ |
目录一.加解密算法数字签名对称加密DES(DataEncryptionStandard)3DES(TripleDES)AES(AdvancedEncryptionStandard)RSA加密法DSA(DigitalSignatureAlgorithm)ECC(EllipticCurvesCryptography)非对称加密签名与加密过程非对称加密的应用对称加密与非对称加密的结合二.数字证书图解一.加解密算法加密简单而言就是通过一种算法将明文信息转换成密文信息，信息的的接收方能够通过密钥对密文信息进行解密获得明文信息的过程。根据加解密的密钥是否相同，算法可以分为对称加密、非对称加密、对称加密和非
目录前言滤波电路科普主要分类实际情况单位的概念常用评价参数函数型滤波器简单分析滤波电路构成低通滤波器RC低通滤波器RL低通滤波器高通滤波器RC高通滤波器RL高通滤波器部分摘自《LC滤波器设计与制作》，侵权删。前言最近需要学习放大电路和滤波电路，但是由于只在之前做音乐频谱分析仪的时候简单了解过一点点运放，所以也是相当从零开始学习了。滤波电路科普主要分类滤波器：主要是从不同频率的成分中提取出特定频率的信号。有源滤波器：由RC元件与运算放大器组成的滤波器。可滤除某一次或多次谐波，最普通易于采用的无源滤波器结构是将电感与电容串联，可对主要次谐波（3、5、7）构成低阻抗旁路。无源滤波器：无源滤波器，又称
1．问题描述使用Python的turtle（海龟绘图）模块提供的函数绘制直线。2．问题分析一幅复杂的图形通常都可以由点、直线、三角形、矩形、平行四边形、圆、椭圆和圆弧等基本图形组成。其中的三角形、矩形、平行四边形又可以由直线组成，而直线又是由两个点确定的。我们使用Python的turtle模块所提供的函数来绘制直线。在使用之前我们先介绍一下turtle模块的相关知识点。turtle模块提供面向对象和面向过程两种形式的海龟绘图基本组件。面向对象的接口类如下：1）TurtleScreen类：定义图形窗口作为绘图海龟的运动场。它的构造器需要一个tkinter.Canvas或ScrolledCanva
写在之前Shader变体、Shader属性定义技巧、自定义材质面板，这三个知识点任何一个单拿出来都是一套知识体系，不能一概而论，本文章目的在于将学习和实际工作中遇见的问题进行总结，类似于网络笔记之用，方便后续回顾查看，如有以偏概全、不祥不尽之处，还望海涵。1、Shader变体先看一段代码......Properties{ [KeywordEnum(on,off)]USL_USE_COL("IsUseColorMixTex?",int)=0 [Toggle(IS_RED_ON)]_IsRed("IsRed?",int)=0}......//中间省略，后续会有完整代码 #pragmamulti_c
TCL脚本语言简介•TCL（ToolCommandLanguage）是一种解释执行的脚本语言（ScriptingLanguage）,它提供了通用的编程能力：支持变量、过程和控制结构；同时TCL还拥有一个功能强大的固有的核心命令集。TCL经常被用于快速原型开发，脚本编程，GUI和测试等方面。•实际上包含了两个部分：一个语言和一个库。首先，Tcl是一种简单的脚本语言，主要使用于发布命令给一些互交程序如文本编辑器、调试器和shell。由于TCL的解释器是用C\C++语言的过程库实现的，因此在某种意义上我们又可以把TCL看作C库，这个库中有丰富的用于扩展TCL命令的C\C++过程和函数，所以，Tcl是
我一直在尝试用Ruby实现Luhn算法。我一直在执行以下步骤:该公式根据其包含的校验位验证数字，该校验位通常附加到部分帐号以生成完整帐号。此帐号必须通过以下测试:从最右边的校验位开始向左移动，每第二个数字的值加倍。将乘积的数字(例如，10=1+0=1、14=1+4=5)与原始数字的未加倍数字相加。如果总模10等于0(如果总和以零结尾)，则根据Luhn公式该数字有效；否则无效。http://en.wikipedia.org/wiki/Luhn_algorithm这是我想出的:defvalidCreditCard(cardNumber)sum=0nums=cardNumber.to_s.s
下面是我写的一个计算斐波那契数列中的值的方法:deffib(n)ifn==0return0endifn==1return1endifn>=2returnfib(n-1)+(fib(n-2))endend它工作到n=14，但在那之后我收到一条消息说程序响应时间太长(我正在使用repl.it)。有人知道为什么会这样吗？ 最佳答案 Naivefibonacci进行了大量的重复计算-在fib(14)fib(4)中计算了很多次。您可以将内存添加到您的算法中以使其更快:deffib(n,memo={})ifn==0||n==1returnnen
我希望Ruby的解析器会进行这种微不足道的优化，但似乎并没有(谈到YARV实现，Ruby1.9.x、2.0.0):require'benchmark'deffib1a,b=0,1whileb由于这两种方法除了在第二种方法中使用预定义常量而不是常量表达式外是相同的，因此Ruby解释器似乎在每个循环中一次又一次地计算幂常数。是否有一些Material说明为什么Ruby根本不进行这种基本优化或只在某些特定情况下进行？ 最佳答案 很抱歉给出了另一个答案，但我不想删除或编辑我之前的答案，因为它下面有有趣的讨论。正如JörgWMittag所说，
为了防止在迁移到生产站点期间出现数据库事务错误，我们遵循了https://github.com/LendingHome/zero_downtime_migrations中列出的建议。(具体由https://robots.thoughtbot.com/how-to-create-postgres-indexes-concurrently-in概述)，但在特别大的表上创建索引期间，即使是索引创建的“并发”方法也会锁定表并导致该表上的任何ActiveRecord创建或更新导致各自的事务失败有PG::InFailedSqlTransaction异常。下面是我们运行Rails4.2(使用Acti
我正在尝试从数据库中读取大量单元格(超过100.000个)并将它们写入VPSUbuntu服务器上的csv文件。碰巧服务器没有足够的内存。我正在考虑一次读取5000行并将它们写入文件，然后再读取5000行，等等。我应该如何重构我当前的代码以使内存不会被完全消耗？这是我的代码:defwrite_rows(emails)File.open(file_path,"w+")do|f|f该函数由sidekiqworker调用:write_rows(user.emails)感谢您的帮助! 最佳答案 这里的问题是，当您调用emails.each时，
