跳至主要内容

《始得西山宴游记》《赤壁赋》知识梳理

-



内容由@Shadowwind提供
赤壁赋

R7Iazrbd.jpg (1441×1920)
始得西山宴游记

评论

发表评论

此博客中的热门博文

给你的git仓库瘦身

-
很久没有写博客了，最近遇到了一个git问题，比较典型，记录下来与大家分享。 我们使用git版本控制的时候享受了很多便利，不管是代码合并，分支提供给我们的并发,但我们也往往忽略了每次提交之后在我们本地项目根目录下.git文件夹里面的存储变化。我遇到的git“臃肿”问题就是因为在提交的时候把较大文本加入版本控制，在其他人拉取更新反推远程分支的时候，每一次都会加剧.git下面的objects的文件夹大小，最终的结果就是再也无法顺利从远程pull，也无法顺利clone该项目。 关于.git的产生和相关文件，可见此文的详细讲解：http://www.jianshu.com/p/fa31ef8814d2 。 简单的说，每一次提交修改的改变都会以文件的形式存储在本地项目根目录下的.git中，会在.git/objects下面形成一个Blob（一段二进制数据）文件记录。这意味着，即使你只改动了某个文件的一行内容，Git 也会生成一个全新的对象来存储新的文件内容。所以git仓库随着时间变化会自增长，我们往往忽视了这种潜在的危险。 下面来就我遇到的问题来思考解决方案，其实由于.git过大，我们可以从两种方向去思考，第一种治标不治本的方法：压缩git仓库。第二种删除git提交记录中大文件，在gc压缩。第一种方法是比较直接快捷的，可以使用命令：git gc --prune=now。 当你再次du -hs的时候会发现仓库大小有一定的变小。其实git自身在可承受范围内会自动用gc帮你压缩打包，所以除非真的遇到pull,push都困难的时候，可以不用手动执行。这个方法明显的缺点在于压缩的效果有限，且大文件还一直在之后的每次提交中，为以后埋下隐患。 本人更推荐第二种方法，大文件对象再删除。 先查找大文件，命令如下： git rev-list --objects --all | grep "$(git verify-pack -v .git/objects/pack/*.idx | sort -k 3 -n | tail -5 | awk '{print$1}')" 例如删除nspatientList1.txt文件： git filter-branch --force --index-filter 'git rm -rf -...
阅读全文

【洛谷】题解 P1633 【二进制】

-
dalao 都用 DP，我发一发贪心的题解。 DP 题硬生生被做成了思维题 首先，不考虑长度限制，只考虑两个数字的 1 的个数。设 A 中 1 的个数为  an a n  ，B 中为  bn b n  ，C 中为  cn c n  。 如果  an+bn<cn a n + b n < c n  的话，显然无解，因为 1 不可能被凭空创生而来。如果  an+bn=cn a n + b n = c n  的话，只需要不产生进位，即让两个加数的二进制表示全部错开就好。然后考虑  an+bn>cn a n + b n > c n  的情况。 在这种情况下，我们需要通过进位消掉  an+bn-cn a n + b n − c n  个 1，然后保证答案最小。 容易发现，可以简单地使用连续进位来消掉任意个数的 1： 11111 + 1 ------ 100000 消掉的 1 的个数即为第一个加数的长度。 严格来说，消掉的 1 的个数的范围为  [0,an+bn-1] [ 0 , a n + b n − 1 ]  。因为，我们可以这样子： 11111 1 + 111111 -------------- 100000000000 （空格为 0） 可行性可以保证。然后就是考虑最优性。 很显然，对于这样一组连续进位，两个加数在连续进位之前的位必须都是 0。也就是说，算式里面最多只能有一组连续进位。如果有两组连续进位，可以将这两组合并，然后偷掉一个位（全 0 位显然可以直接抠掉），这样两个加数都会变小，和也会变小。 唯一的进位处就在那个连续进位的地方。 同理，这个连续进位必须在最高位。如果不是的话，可以交换顺序使它在最高位，然后偷掉一个位。 基本框架就确定了，由于消掉的 0 的个数确定，连续进位的长度也确定了，然后只需要在这个基础上贪心地将 1 用完就好了。 在这个连续进位式骨架上，我们可以做的事情包括将一个连续进位中的改成 1，以及在后面跟单独一个 1。容易证明，最优的解就是尽量用 1 填那个进位中的空，如果还有多余的 1...
阅读全文