“报告这个主题”

大概看懂了但是你的问题大概是 NP-hard ，可以通过 Hamiltonian path 归约。

然而我们并不知道体积、重量和运费的关系，如果假设 运费 = max { Vp, Wq } 其中 V 、W 是总体积、总重量且 p 、q 是常数，则可以赋予每个 SKU 包邮时的保守利润估计，那就是

售价 — 税 — 成本 — max { vp, wq }

其中 v 、w 是这个 SKU 的体积、重量。

这是因为同一个 SKU 买很多件，则每件的利润如此。 由此看来如果你要给售价打九折还不亏，就需要

售价*0.9 — 调整过的税 — 成本 — max { vp, wq }

非负，这说明可以设置满减的条件是利润本来就大，而且可以设置满减的起始额就是体积、重量的一次函数主导运费的时候（低体积重量的运费并不会变成 0 ，此时上面的计算不可行）。

更常见的设置应该让满减后依然保有大量利润，否则你无法处理退货之类的问题。

最后，请多多使用字母表示数的方法，不要用数字表示未知数。

@renmu #3 很明显在 V2EX 看来行使自己的权利是浪费生命。

@klgd #2 推荐的思考方法：假设你先上线，完成同步，此时 remote/branch 是 A ，然后离线，然后有人 push B 到 remote 的 branch ，然后你在离线的状态下 git merge remote/branch ，请问这是在 git merge A ，还是 git merge B ，还是 merge 不会成功呢？

当然，我们相信 git 的设计是良好的，一个重要的特征就是各种操作的效果都尽量可预期，为此目的应该让本质上有不确定效果的操作（如 fetch ，它的效果取决于网络环境和远程计算机上的状态）尽量单独成立。我们 merge 的时候会先想好要 merge 的 commit 是谁，然后才操作，如果 merge 会自动 fetch ，那么它的效果就无法预期（因为我们看好的 branch 可能在 fetch 的时候变更），因此可以推断 merge 的时候不会自动 fetch ，此外 pull 的效果通常是 fetch+merge ，如果 merge 会自动 fetch ，那就没有单独成立 pull 的需要了。

另外你可以看到 git 自动生成的消息表述十分准确，remotes/origin/develop 是 remote-tracking branch ，不是 remote branch 。

有很多可能的原因，比如没有 fetch 就 merge ，或者 merge 之后 3908 才被 push 上去（那个时间并不是 push 的时间，而且 commit 的两个时间也是可以随便写的）。

没有自带的。Microsoft 目前的 Dictionary 实现是用数组作为节点存储、下标作为指针的链表，数组里的顺序是遍历顺序，删除的时候把节点放入空闲链表，加入的时候优先使用空闲链表，其次使用数组之后的空位，最后考虑扩容。因此，加入 1 、2 、3 ，删除 2 ，加入 4 ，此后遍历顺序是 1 、4 、3 。当然，现在的实现不一定是未来的实现。

你可以仿照这个实现一下自己的 Dictionary ，删除的时候不要放入空闲链表，但要考虑碎片整理（例如有 1/2 空间是碎片的时候整理），加入的时候先考虑数组之后的空位，再考虑碎片整理，最后考虑扩容，以数组顺序作为遍历顺序。删除的时候碎片整理是为了提高均摊效率，当然坏处是删除操作会令所有迭代器无效（最新版本的 Dictionary 里，删除操作不会令迭代器无效）。

没看懂你的文章里的例子，是每个 Heading 1 样式的段落都创建一个链接吗？推荐用 OneNote COM API 。

另，如果目录的每一项是页面的话直接选中页面复制链接即可。

AppleCare 是否生效，和技术上是否显示 AppleCare 生效，是两回事儿。收据已经证明了 AppleCare 有效期。

@hhhhhh123 #9 客户端和服务端的通信要防止传输路径上的窃听与篡改，不能防止用户发送无意义数据。你的问题（……进行交互……照搬？的完整解答需要好几本书，但你可以通过仔细思考什么行为是安全隐患、什么问题可以（或者不能）通过在哪里施加哪些技术手段防范来管中窥豹。

最后，这个 secret 是你和 VMADU 公司才知道的，通常来说是 VMADU 公司审核你的资质之后为你生成的（同时也允许你请求 VMADU 重新生成并告诉你新的 secret ）。

首先，这个不是数字签名，而是消息验证码（ MAC ），特别地，这是 hash MAC 。

其次，这里说的 app 不是运行在客户端的程序，而是运行在服务器上的（因此受到开发者的控制），客户不应该能直接访问这个 secret （因此不受任意用户的控制）。

就用这里的收付款的例子，假设客户可以通过客户端（如网页）填写信用卡信息来购物，然后要调用 VMADU 公司的支付 API 来请款，那么调用这个请款 API 的程序运行在服务器上，而不是客户的机器上，服务器程序需要验证购物信息有效才会调用这个 API ，而消息验证码是确保这个 API 确实是服务器调用的。

假设你发现信用卡 1234 的客户总是退货，于是你决定不再和这个客户做生意，那么你的服务器程序遇到 1234 的时候就不调用 API ，此时 1234 客户不能强行用这个 API 使得你收款（从而带来不必要的麻烦，例如要求你发货之类的）。

这个做法到底在保护什么并不明确。

如果 Chrome 以用户 A 的身份运行，那么用户 A 身份运行的其他程序都可以向其中注入代码，因此验证进程对应的可执行文件路径无法保证运行的代码全部来自该可执行文件。

另外这个功能看起来需要以 SYSTEM 身份运行 Chrome 代码，除了以 SYSTEM 身份运行代码本身相当不安全之外，这会导致安装 Chrome 时（或者运行的时候）必须提权——现存的设计允许 Chrome 以非管理员身份安装和运行，这显然是巨大退步。

@geelaw #7

>假设 a b c d e f > 0 且不考虑历法变更而不存在的日子，这些数表达了存在的日子，且 x 年 y 月 z 日不早于 a 年 b 月 c 日。

更正为

>假设 a b c x y z > 0 且不考虑历法变更而不存在的日子，这些数表达了存在的日子，且 x 年 y 月 z 日不晚于 a 年 b 月 c 日。

@airbotgo #2 你似乎没有理解 #1 的用意。

> 如某事已经过去了 2000 天，如何转化为某事已经过去了“x 年 x 月 x 日”，关键这个“x 日”如何准确计算？

#1 的定义表明从 2000 天无法算出多少年多少月多少日，例如：

2000 年 8 月 31 日是 2000 年 7 月 31 日之后 31 日，也是它之后 0 年 1 月 0 日。
2000 年 10 月 1 日是 2000 年 8 月 31 日之后 31 日，但不是它之后 0 年 1 月 0 日。

同样是 31 日，不能得到它到底是不是 0 年 1 月 0 日。因此问题不成立，但如果你知道开始和结束的日子，则很容易根据定义计算到底是多少年多少月多少日，同理，如果一个软件采用了 #1 的定义，那么它并不是先算出多少日，再仅从多少日转换为多少年多少月多少日的，而是直接算出来。

如果你想问某个软件是如何计算多少年多少月多少日的，最好的方法是直接去看代码，毕竟不同的人定义不同。

如果你想问 #1 的定义下的最佳表达（年数最大的基础上月数最大）如何计算，下面是一种方法：

计算 a 年 b 月 c 日是 x 年 y 月 z 日之后的 u 年 v 月 w 日。假设 a b c d e f > 0 且不考虑历法变更而不存在的日子，这些数表达了存在的日子，且 x 年 y 月 z 日不早于 a 年 b 月 c 日。

https://gist.github.com/GeeLaw/9c68befab1b125a33c52deaf386bf92a

这取决于你如何定义“过去了 ... 年 ... 月 ... 日”的概念。

例如，2001 年 3 月 1 日是 2000 年 2 月 29 日之后的多少年多少月多少日？

我个人认为无歧义的表达是：
0 年 11 月 31 日
0 年 10 月 62 日
0 年 9 月 92 日
0 年 8 月 123 日
0 年 7 月 153 日
0 年 6 月 184 日
0 年 5 月 215 日
0 年 4 月 245 日
0 年 3 月 276 日
0 年 2 月 306 日
0 年 1 月 337 日
0 年 0 月 366 日

不可以说 2000 年 2 月 29 日的 1 年 0 月 ? 天之后，因为不存在 2001 年 2 月 29 日。

形式化来说，我定义“a 年 b 月 c 日的 x 年 y 月 z 日之后的那一天”的概念存在，当且仅当 (a+x+floor((b-1+y)/12)) 年 1+(b-1+y)%12 月 c 日存在，且这个概念表示的是 (a+x+floor((b-1+y)/12)) 年 1+(b-1+y)%12 月 c 日之后的第 z 日。

换言之，增加 x 年 y 月 z 日的意思是前进 (12x+y) 个月并保持“日”不变（假设这一天存在），然后再前进 z 日，只有年月之间是可以自由转换的，年月和日之间的转换比较复杂。

提示：你看一下视频就知道了

@zedboy #7 你要找的是不是 Copy-Item 带 -FromSession 的版本？