rate 或 irate 函数

老老实实换成 yml 或者 json 配置吧
Properties 根本就不是为这种场景设计的，key 里的多级结构仅仅起到一个人肉命名空间的作用，实际使用时只能当作一个整体，换成个熟悉的例子，就好比 package 名字一样，有 com.example.x 和 com.example.y 存在，除非真的在 com.example 下面有类存在，否则 com.example 就不是一个正确的包名，不能理解为一个“parent package”，同理还有 redis 或者其他的 k-v 存储里，我们通常会在 key 名字里加上点分结构，为的是在人的逻辑上存在一个“树形”结构，但是对于存储来说根本就不关心这个点的存在，只认整体
而只有在 yml 这类配置里，本来就是为树形结构而生的，对树形结构有原生的支持，由于 yml 语法对 Properties 有一定的兼容性，你只需要把原本的 Properties 文件改为 yml，并且把=改为:就达到你想要的效果了

其实吧，现代的浏览器，不管移动端还是桌面端的，都存在两种“放大”
第一种是从早期浏览器开始就存在的“缩放”功能，即显示地修改“缩放水平”这个设置，通常为+-键或鼠标滚轮操作，对页面有感知，会引起布局的变化，也就是你想要解决的场景
第二种是浏览器自身在显示时进行的缩放，例如双指缩放或者双击页面空白处，这种缩放对页面无感（非要有感也有一些很费劲的旁门左道，个人觉得完全没必要），不会引起页面布局的变化

按照现在人的操作习惯，很多时候使用的是后者，所以结论就是，网页里什么都不用做，自然就能达到你想要的效果了，你需要做的是引导用户去使用后者操作

pr 既然叫做 pull request，表示的是请求 maintainer 去 pull，如果你不 fork 的话准备让人从哪去 pull 呢？

楼上的都在强答些什么啊，正解是，你任意搜索一篇关于 rsa 原理的文献，其中的证明部分都针对 m 与 n 互质和不互质的情况进行了分类讨论，其中互质情况的证明就是你贴出来的欧拉定理，而假如不互质，那么 m 一定整除 p 或者整除 q，由于轮换对称性，任取其中一种假设接着证明即可，最后可以证出即使 m 与 n 不互质，m^ed%n==m 仍然成立，所以加解密仍然可以工作

上一条 @错人了，应该是 @TuYanzheng

@SimonOne 社死现场，删号重练吧

我相信你需要的是 CodeModel，你生成的是 AST，它负责输出代码，完全满足你的要求

- hey,Siri,叫我起床
- 好的，从现在开始，我会称呼你为“起床”

@mrxyz 你以 liar's dice 为关键字搜索，可以看到确实有一些人尝试了 AI 在这个游戏中的应用，有兴趣的话可以看一下，不过个人观点，程序在这种游戏里作用极其有限，因为不管是什么样的程序，都需要正确的输入来的得到正确的输出，但是在这个游戏里，输入完全有可能是无效的甚至负面的，就好像专业高手玩的斗地主，在普通玩家看起来有些操作会很蠢，实际上是因为高手追求稳定，总是考虑最坏情况，而普通玩家通常喜欢赌一把，所以有的时候就会看到高手因为过度谨慎而输掉一把牌，但是换成普通玩家反而能赌对，吹牛也是一样，即使真的做出这样的程序，我估计在面对小白玩家时反而容易输掉

@mrxyz 这不就是“吹牛”嘛，好好的规则被你给描述得细碎
这个游戏说实话跟概率关系不大，因为别人的任意一次报点都有可能是假的，虽然通过统计确实可以得出一些类似“这个人上一次和这一次之间必有一个是假的”这样的结论，但是对于游戏决策没有关注，因为有可能是上一次假这一次真

@charlie21 @zxCoder 给楼上看不懂规则的解释下，如果没理解错，题主说的应该是流行于全国各地酒吧的名为“吹牛”的游戏，基本规则如下
1. 所有人摇骰子，每个人只能看到自己的点数，按顺序依次行动
2. 每次行动中可以喊“X 个 Y”，意思是所有人的骰子加起来至少有 X 个骰子点数为 Y
3. 上一个玩家喊完后下一个玩家可以接着喊 X1 个 Y1，且必须满足 Y1 > Y or (Y1 == Y and X1 > X)，也可以选择开，如果选择了开，所有人把骰子翻开，如果上家喊的条件满足则上家喝酒，否则开的这个玩家喝酒，游戏结束
4. 还有其他一些补充规则，例如 1 可以当任意点，但是如果有人喊过 X 个 1 则此规则失效

这个游戏由于是非完全信息博弈，且有很大的心理成分，所以用程序计算的帮助不大，实战当中基本的技巧一般是利用自己某个点数较多的优势，把对手逼到一个“喊又喊不过，开的话你又是真的”这个境地，同时前期还可以冒险喊一些假的，让别人对你的点数产生误判，从而在后面喊真的进行出击时积累优势，这些更多考验的是心理素质、表演能力以及对对手风格的熟悉程度等，假设对面是个绝对理性的人或机器，在已知大家都只会选择最优解的前提下，可以通过马尔可夫过程大致推断出对面的点数从而做出决策，但要是对面是个不按常理出牌乱喊一气的，理性一方反而会被乱拳打死老师傅，因为你从前面得到的虚假信息中推出了错误的结论

确定 df 是在你目前用的这个 svn 服务器上运行的么？

代数是研究结构的学科，以代数系统为例，给定一个集合，定义若干种运算，就构成了一个代数系统，按照这些运算的性质进一步归类为一些特殊的代数系统，例如群、环、域等等，代数最大的特点就是抽象，虽然学习过程中会先从一些熟悉的具体的例子开始，例如自然数的加法和乘法构成的代数系统等，但是代数系统本身并不局限于具体事物，而是关注抽象的事物之间的联系，用程序来类比的话有点面向接口而非面向实现的这个意思在里面
你题目中说的代数数据类型，因为不清楚上下文，姑且以我自己知道的 haskell 来举例，由于可以给类型定义“加法”、“乘法”等运算，从而可以证明 haskell 的类型构成了一个代数系统，既然构成一个代数系统，那么已知的代数系统里满足的性质类型系统自然也都满足，从而可以推导出一些有趣的结论

@Mexion 这个其实是个很有价值的问题，说句冒犯的话，我相信现在越来越多的 Java 程序员当问到他这个话题时，都能说出协变、逆变、PECS 原则等名词，但是继续深入追问下去就会发现开始难以自圆其说了，在这里我根据自己的理解，争取能够一次性把这个问题说清楚
1. 首先回答你主题里的疑问，首先你的疑问来自于一个误解，List<？ extends Animal>并不是用来约束里面元素类型的，而是用来约束 List 本身的，只要这个弯转过来那主题里的疑问以及其他类型的疑问都一并迎刃而解了，为什么说这是个误解，有个很简单的证据，你直接写个 List<Animal>，里面一样是可以存 Animal 及其子类的，所以 List<? extends Animal>绝对不是表示这个 list 可以存 Animal 及其子类的意思，到底表示什么下面展开讲
2. 首先简单回顾一点预备知识，在绝大多数的 OO 语言里，类的继承关系都是表示 is-a 的关系，简单地说就是如果 B is-a A，那么在所有期望一个 A 的地方(包括方法参数，变量等)，都可以提供一个 B，并且不需要任何的显示类型转换，这就是为什么可以写 List l = new ArrayList();的原因，对于简单类型，判断 is-a 很简单，只要二者在一条继承关系的链上，就能定义 is-a 关系，但是引入泛型后，问题就开始变得有点复杂了，List<Animal>和 List<Dog>之间的 is-a 关系是怎么样的呢？结论是不具有 is-a 关系，List<Animal> is-a List<Dog>不成立看起来是显然的，但是反过来似乎就有点反直觉了，这就涉及到下面要讲的几个概念
3. 关于不变(invariant)、协变(covariant)、逆变(contravariant)，首先声明，虽然这里使用 Java 语言举例，但是这几个概念在几乎所有支持泛型的 OO 语言里都存在，事实上这几个概念在存在计算机语言之前就已经存在了，是范畴论里的几个概念，下面以 Java 为例说下分别是什么意思，前面说了，List<Animal>和 List<Dog>之间不存在 is-a 关系，这就叫做不变(invariant)，但是有的时候，我们需要让它们之间存在 is-a 关系，这就要通过一些关键字来人为指定下面两种关系，假设规定 List<Dog> is-a List<Animal>，这种关系就叫做协变(covariant)，因为 List 之间的 is-a 关系和 Animal 及 Dog 之间的 is-a 关系方向是一致的，反之，如果规定 List<Animal> is-a List<Dog>，这种关系就叫做逆变(contravariant)，因为 List 之间的 is-a 关系和 Animal 及 Dog 之间的 is-a 关系方向是相反的，各种语言里都会有一些标识来定义协变及逆变，例如 c#用 in/out，scala 用+/-，而 Java 就是用的 extends 和 super，简单说 List<? extends Animal>实际表示的是，对于这个变量，可以接受 List<Animal>，也可以接受 List<Dog>、List<Cat>等，反之，如果定义 List<? super Animal>，那么表示这个变量可以接受 List<Animal>、List<Object>等，这就是我在开头说的，当定义一个变量 List<? extends Animal> l 时，这里的 extends 并不是约束“l 里可以存什么”，而是约束“什么样的 List 能够赋值给 l”
4. 相信到这里题主应该已经能够自己想通问题出在哪了，但是我还是顺便展开说一说 PECS 原则，PECS 原则确实是个帮助记忆的好东西，但是真正合格的程序员应该主动多思考一下，PECS 里是用 List 举例的，但是泛型类并不一定都是个容器，对于非容器类型的泛型类，到底什么算 produce 什么算 consume，其实，所谓的 produce 和 consume 是人逻辑上的概念，编译器肯定不认识啊，所以 PECS 的本质其实指的是这个类型边界出现在方法参数上还是出现在返回值里，下面举个例子，假如我们写了一个方法，作用是将一个 list 里的元素取出来进行某种操作然后放到另一个 list 里，为什么方法签名必须定义成这个样子
void map(List<? extends Animal> source, List<? super Animal> target)
首先，对于 source，我们可能会进行这样的操作
Animal a = source.get(0);
这就要求传给 source 的 list 必须满足“能够从中取出 Animal”这个条件(当然，从编译器的角度，应该是“可以调用返回类型为 Animal 的方法”)，因此当在调用 map 时，可以给 source 参数传 List<Animal>、List<Dog>、List<Cat>都是合法的，但是不能传 List<Object>
而对于参数 target，我们可能进行这样的操作
target.add(a);
这就要求传给 target 的 list 必须满足“能够往里添加 Animal”这个条件(当然，从编译器的角度，应该是“可以调用参数为 Animal 的方法”)，因此当在调用 map 时，可以给 target 参数传 List<Animal>，List<Object>都是合法的，假设 target 能够接受 List<Dog>，而在 map 方法体内部往里放了个 Animal，这显然是不合理的

一不小心写了这么多，最后放个太长不看版吧，一句话，对于 List<? extends Animal> l 和 List<? super Animal>，泛型边界并不是表示 l 里能够存什么，而是表示 l 能够接受什么样的 list

@RedBlackTree

用“创建”变量这个词容易让人产生一种误解，好像变量是某种资源一样，“创建”是个消耗资源的过程，实际上所有的局部变量仅仅是 BP+N 这个地址的一个代号而已，并且这个 N 在编译时已经确定了，换句话说在运行时根本就没有所谓的“创建”变量这回事，跟是否循环没有任何关系

business logic

重读音节和非重读音节

@0576coder 是的，你在主题中的疑惑应该来自于“反正都要手写 Class.forName，那么 spi 就没意义了”，事实上只要认识到 Class.forName 不但是多余的，甚至根本就是错误的，正确的做法是只需要把带有元信息的相应的实现放到 classpath 即可，当需要替换驱动时对代码完全无感，从这个角度看 spi 跟多态、DI 、服务发现等都是一回事，手写 Class.forName 反而依赖了具体实现