这道题目有两种解法:记忆化搜索和线性动态规划。实际上,两者都属于动态规划的范畴之内,而记忆化搜索因为具有更为直接的思路,因而更容易想到(虽然不一定了解这个术语)。记忆化搜索的原理是利用搜索子问题的重复性,本质就是使用额外的空间存储已经进行过的搜索结果,是一种以空间换时间的思路,在此不做赘述。

本篇题记主要描述在本题中,将二维平面搜索转换为线性动态规划的一些理解。

第一步:分析问题结构

将问题动态规划化需要三个条件:最优子结构、无后效性和子问题重复。其中最优子结构的“问题最优解基于子问题的最优解”结论,从理论上允许我们通过求解子问题的最优解,从而推断出原问题的最优解;无后效性则确保了子问题一定是可解、易解的,从理论上杜绝了循环依赖的问题;子问题重复则是对于效率上的一种保证。前两个条件确保了动态规划的可行性,第三个则确保了动态规划的有效性。

但是在本题中,数据是按照二维坐标排列的。这样就会产生两个问题:

  1. 索引有两个维度,排序复杂;
  2. 现有的索引并不利于子问题的划分(即坐标与“高度”之间无关联性)。

于是注意到题目中,“斜坡”是按照点的高度进行定义的,所以考虑将点按照高度进行排序,这样恰好满足了最优子问题的结构:当考虑“斜坡”是以在现有“斜坡”的基础上追加新的、长度为1的小“斜坡”的话,恰好形成了一系列以高度为顺序的子问题序列。也就是说,这个时候,只需要按照高度顺序进行某种最长升序子序列的状态转移方程进行求解即可。

第二步:明确状态转移方程

状态转移方程可以视作一类递归函数,不过实现的时候用的是数组,而这也正是对子问题重复特性的利用。实际上,状态转移方程就是动态规划算法的实现原型。完成目标参数值下的状态转移方程值求解,也就完成了对问题的求解。

这里的状态转移思路非常简单,以当前坐标为起点的最长路径是:所有可到达该点、且高度高于该点的坐标中,所具有的最长路径。

公式表述如下:

L_{i} = \mathit{max}(L_{i}, L_{j} + 1)\ \text{where}\ \mathit{i, j}\ \text{is adjacent and}\ h_{i} > h_{j}

第三步:实现

基于上述思路,进行程序语言的书写就可以了。由于要设计高效算法,应该尽可能避免不必要的操作,在进行数据读入的时候就可以按照高度作为索引的数据结构进行保存。其余部分没有什么需要特别注意的,就是条件记得写对、不写漏就行。

在CentOS 8上配置Kubernetes。

步骤可以大致简述如下:

  1. 如果在国内,换源
  2. 安装Docker(需要手动添加repo)
  3. 安装Kubernetes配置工具Kubeadm,会自动顺带完成其他Kubernetes配件的安装(也需要手动添加repo)
  4. 决定一个CNI(容器网络接口)组件
  5. 使用kubeadm init初始化集群,记得带上CNI可能会需要指定的参数(至少FlannelCalico在默认情况下是要求手动显式指定默认的CIDR的)
  6. 使用kubectl apply(更新)或者kubectl apply(重置)安装对应CNI组件的Pod
  7. 使用kubectl taint nodes --all node-role.kubernetes.io/master-取消集群master节点的“特殊地位”,允许在master节点上部署应用容器 Google传统艺能

然后关于Kubernetes的镜像,默认用的是Google的GCR仓库,显然在国内是访问不到的,在拉取镜像的时候会报超时错误。网上有不少的解决方法,比如建立私有仓库,换源,但是要么太复杂,要么说的含糊不清。还是弄个透明代理最爽了

参考:https://coreos.com/flannel/docs/latest/kubernetes.html

最近在研究编码参数的时候,随手点开了某番剧的MediaInfo作为参考。结果一看,虽然MediaInfo上显示是AVC(H.264的一种)编码,但是居然没有编码参数Encode Settings

然后很是疑惑,遂到网上寻找隐藏H.264编码参数的方法。H.264的没找到,不过H.265的好像倒是有。

http://forum.doom9.org/archive/index.php/t-171681.html
这里有一群外国人讨论过这个问题,从中能够获取的信息之一是,x264编码器的开发者们本意似乎是希望编码参数跟随视频一同流传的,从某种程度上还能方便大家相互学习参数的调整。也就是说,AVC编码的视频本身没有携带编码参数是一种不正常的现象(视频编码程序本身并没有提供这种功能)。

然后仔细对比了一下MediaInfo里的参数,也没有发现什么猫腻。

不过后来用WinHex查看了一下文件头,发现这个文件的类型是ftypmp42,和常见的自带编码参数的ftypavc1有区别。说不定是因为数据流版本太老,所以不支持记录编码参数?(问题是,上个世纪的DV编码格式都能记录编码参数的啊)

难道是,失传已久的S级记忆消除秘术?

坑+1

今天突发奇想去Internet Archive搜了一下自己的网站,发现在过去的短短半个月内竟然被收录了(虽然似乎只有首页),而且还快照了六次。震惊。

也不知道这些网络爬虫用的是什么原理,建站一年多,网站链接在GitHub挂了有半年多都没被被收录,结果最近突然就收录了。

不胜荣幸.jpg

算是小小的庆祝一下吧,顺便看下这篇文章什么时候会被收录

(十年老站的第一步,任重而道远啊)

HTTPS为网络安全传输带来了很大帮助,但是会因为其严格的措施,导致在很多地方出现奇怪的报错= =

这次的主角是Powershell,具体情境是在使用Download-File命令的时候,出现如下的错误信息:

The underlying connection was closed: An unexpected error occurred on a send.

两个StackOverflow链接解君愁:
https://stackoverflow.com/questions/41674518/powershell-setting-security-protocol-to-tls-1-2
https://stackoverflow.com/questions/36265534/invoke-webrequest-ssl-fails

简单总结,就是因为Powershell中需要对系统使用的HTTPS加密协议进行显式声明,然而因为我用的系统版本过低,某些常用的协议(比如TLS 1.2)并没有被默认加入到这个声明列表中,导致协议握手失败。

再次放图:

不愧是巨硬.jpg

好在可以通过Powershell命令对允许使用的加密协议进行修改:

[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Ssl3 -bor [System.Net.SecurityProtocolType]::Tls -bor [System.Net.SecurityProtocolType]::Tls11 -bor [System.Net.SecurityProtocolType]::Tls12;

在Powershell中读取.NET对象的属性的时候,有点像IPv6指定端口一样,需要先用中括号将对象包裹起来,然后再用两个冒号连接需要读取的属性名称。

后来找到了更简单的写法:

[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]'Ssl3,Tls,Tls11,Tls12';

到此结束。