V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  geelaw  ›  全部回复第 6 页 / 共 172 页
回复总数  3428
1 ... 2  3  4  5  6  7  8  9  10  11 ... 172  
>2500 刀每个月, 没有税

震惊,初次留学读博的话,大概是 nonresident alien ,中国人减免 5000 USD/a 的与学校有关的收入,没有标准扣除,因此每年的 effectively connected income after deduction 是 25k ,依然要交税的。

如果是 fellowship 而不是 assistantship (雇佣关系)的话另说。

IANAL/TP, NL/TA.
可以用编辑距离建模。

准备工作:找一本字典,记住所有的标点、空白、汉字,以及同一个字的不同写法(简体繁体异体字)。

1. 两个字符串都删除所有的标点空白,只留汉字。
2. 计算编辑距离最小的编辑:把一个字替换为它的其他写法、删除一个字、增加一个字的代价可以都设置为 1 (这样的话把一个字改成和它没关系的另一个字的代价就是 2 )。

第二步是标准的动态规划问题。
116 天前
回复了 KlNon 创建的主题 问与答 有没有这么一款剪切版软件?
@r3a1ex0n0 #10 可以,但是这样做就必须用 Ctrl+V 访问粘贴功能,然而用户可以选择用鼠标、用 Shift+Ins 粘贴。我选择采用 psychic debugging 之“揣摩出题人的意图”。
117 天前
回复了 KlNon 创建的主题 问与答 有没有这么一款剪切版软件?
如果是读取剪贴板数据的软件实现,当然没有问题,第一次按 Ctrl+V 之后,软件读到 1,2,3,4,5,6,7,8,9 ,然后记住目前在输出列表,如此这般,这般那般,皆大欢喜。

如果是放置剪贴板数据的软件这样做,则 Windows 上不存在可靠的方法实现这个需求。

Windows 的剪贴板数据流是这样的:

1. 程序 A 打开剪贴板并清空之,此时剪贴板的所有者是 A 。如果剪贴板曾经有所有者 C ,则 C 被告知它已经不是所有者。
2. A 在剪贴板上放置各种数据,并标记一些格式延迟渲染。
3. A 关闭剪贴板。

4. 程序 B 打开剪贴板并查询支持的格式。
5. B 选择一些格式获取数据。
6. 如果获取的数据是非延迟渲染,则 A 被告知需要渲染某格式,此时 A 把数据放入剪贴板。
7. B 关闭剪贴板。

这一段表明,若剪贴板上某个格式(例如字符串)已经有数据(非延迟渲染,或延迟渲染且已经渲染过),则再次读取那一格式的时候 A 不会知道,也就是某个格式的数据一旦放入剪贴板,A 就不会在有机会考虑修改它了。

一种思路是这样的:A 设置字符串是延迟渲染,并且在第一次被要求渲染的时候放入 1 ,然后在 B 读完之后重设为延迟渲染(下次放入 2 ),或者放入 2 。

这样做不可靠有理论原因和实际原因,理论原因是 A 不可能知道 B 什么时候读取完毕,实际原因是 B 读取一次不代表用户粘贴一次,比如各种 Office 程序,当鼠标悬停在“粘贴”上的时候就会读取一次剪贴板显示预览,但用户不一定要真的粘贴,A 自然无从判断 B 读取之后是否应该“前进”。
@Bingchunmoli #5 这个问题是很奇怪的,因为 merge commit 是常态,squash merge 是非常态。如果 git merge 不加 --squash 那么 Git 在默认设置下就会采用 merge commit 。

但这些实操并不重要,随便搜索一下就知道了。我的回复想要表达的是这个:Git 中一切信息都来自于每个 commit 里面的内容和 commit 的亲子关系,任何计算(例如 merge 如何 merge )当然只能基于这些信息。Squash merge 会导致 Git 记录的信息和人类心中的信息不一样,两种解决方案无非是告诉 Git 正确信息的方法。
是 merge 不是 megre 。

在 A 上 git merge --squash B 的意思是在 A 之后建立一个 commit C ,它的 parent 是 A ,效果是 A 和 B 的 merge base 以来 B 的变化的复合。这相当于在 A 上面把 B 里面的事情重做一次再 commit ,因为 C 的 parent 没有 B (换言之,Git 认为 C 和 B 没有关系),所以继续在 B 、C 开发后再次 merge ,会导致 Git 以为 B 和 C 包含重叠的变化,于是 Git 不知道怎么办(是接受一次呢,还是接受两次呢,还是……),即冲突。

由此可见两种解决办法:一是 B 继续开发之前重新指向 C ,于是下次 merge 的时候 B 先前的变化就不是 merge 的考虑范围了;二是采用 merge commit ,让 C 记住自己来自于 A 和 B 。
这个问题的常规做法是先确定模型,比如你认为温度作为时间的函数是某族函数中的一个,有未知的待定参数,然后根据数据拟合之,再分析这样做的误差等等。

贸然计算温度对时间的差商无甚意义。
@ysmood #28

第二个问题,似乎你没有理解第一个攻击例子的场景:A 要和 B 说话,B 选择去听任何人的话,M 达成的效果是 M 不知道 A 想说什么,但是让 B 以为 M 说了 A 本来要说的话。B 是用 M 的公钥验证的。

另外加密算法的安全性不是用思考具体攻击方案的方式考虑的,复合两个安全的算法也不一定达成两者安全性的“复合”。通行的做法是归约,你的算法可以看作某种安全性的 KEM 和 CPA 安全的私钥加密和签名的复合,无法推出第一个例子下的安全性。

当然,你并没有说明你的算法期待达成何种安全性,因此我考虑的是两个人之间的对话是 authenticated channel 版本的安全性,这通常需要采用 CCA 安全的加密算法。
@ysmood #25

第一个问题,我不知道有没有风险,但是这会导致没有选择超过 128 位密钥的意义,限制了最大安全性。

第二个问题,对密文签名只能保证密文“被谁同意”,不能保证明文来自于谁,也不能保证密文在加密结束之后没有被“有意义地修改过”,后者是选择密文安全性的要求。

“明文来自于谁”的攻击:A 向 B 发送消息 X ,经过加密得到 C ,再对 C 签名得到 D ,并通过网络发送 D ,使坏者 M 截获 D 并拿出 C ,然后重新以 M 的身份签名 C 得到 E ,发送 E 给 B 。

假设 B 公开接受任何人 Y 的消息 Z ,如果 Z 包含了某个密码,则允许 Y 获得权限。上述场景中 A 知道密码但 M 不知道,但 M 可以获得权限。

“修改密文”的攻击:类似上面的,但重新签名之前修改 C 获得 C' 并对 C' 签名。

除非收信人只收取某个特定的人(以签名所用的公钥识别)的信息(因此 M 重新签名不会被接受),否则上述场景可以成立。但如果收信人只收取特定的人的信息,则没必要每次通信都用公钥加密。
@ysmood #5

你的第一段回复表明确实弄混了块长度和密钥长度,AES 的块长度永远是 128 位,密钥有三种长度。不存在“选择”块长度这种操作,因为没的可选。

第二段回复表明没理解什么是选择密文安全性。把公钥加密和 AES 以 OFB 模式(不是选择密文安全)结合时当然不可能期待选择密文安全性。
随便看了几眼,看起来有如下问题:

- 弄混了 AES 块长度和密钥长度,并且不知为何要先对随机数取 MD5 再当作 AES 密钥
- 加密算法看起来没有保证选择密文攻击下的安全性
- 引用 RFC 4880 Sect. 5.13 以论证合理性的部分似乎没有起到密码学安全性(所引用段落的目的)的作用
127 天前
回复了 dumbbell5kg 创建的主题 程序员 一个逻辑直觉的问题
@yxd19 #10 我并不是这么理解的,楼主的话的意思显然是编译器认为 b1 是恒为 true ,这才是让我惊讶的点——因为我以为编译器不会追踪集合是否是空。

此外就是这段代码看起来像 Java ,而我以为 Java 编译器不会做这么多的检查,尤其是 x 的静态类型上的 getProcessStatus 非常可能不是密封(最终)方法,从而不能假设是无副作用,对它静态分析非常困难。

但总之,我的第一条回复的另一层含义是楼主说话应该把上下文说清楚。

另外怎么突然用清朝微积分语言(?
127 天前
回复了 GopherDaily 创建的主题 Go 编程语言 Go: For-Loop-Variable 适合面试的小问题
@yxd19 #25 你可能没有仔细阅读楼主的内容,请看第三段代码片段,那里面没有闭包。
127 天前
回复了 dumbbell5kg 创建的主题 程序员 一个逻辑直觉的问题
@yxd19 #7 我不确定你为什么会认为名字类似 getProcessStatus 的方法是无副作用的,举个非常自然的例子,如果 x 对象基于操作系统级别的进程,那么 getProcessStatus 很可能每次调用的时候都会检查操作系统级别的进程是否结束,并根据操作系统级别的进程的结束状态(还在运行、以 0 退出、以 1 退出、以其他返回值退出)决定返回值。调用操作系统级别检查进程状态的 API 相当于某种同步 (synchronization) 操作,永远属于有副作用操作。

从您打人的条件来看,似乎光是把 complete/close 写成小写就可以发动您打人的动作了?实际上,同一个数值具有多个不同的同类型枚举名字的状况不少见。我想没有什么人在“正经”的程序里用 xs.anyMatch(x -> true) 判空,但不代表它的行为不是如此。

另外您似乎忘了:当下的主题是形式逻辑,不是编程最佳实践。
127 天前
回复了 GopherDaily 创建的主题 Go 编程语言 Go: For-Loop-Variable 适合面试的小问题
@GopherDaily #14 错误的方式可以有很多,没有必然理由认为你的错误答案程度更轻,建议不要和别人玩“揣摩出题人意思”的游戏。

#15 你可能没有理解我的意思。

>我们在下述例子中看到, i 和 v 的内存地址始终未曾改变: ...
>另外 i 和 v 的地址未曾改变不能证明任何事情,即使每次迭代的变量是新的,编译器也可以证明复用旧的内存位置没问题,于是优化之后会看到相同的地址。

引述第一段内容,阅读后揣摩得出:这段话是想要通过地址不改变 (A) 证明迭代变量每次都是同一个 (B),即论证 A => B ,并观察到 A ,因此推出 B 。
引述第二段内容,意思是 A => B 的论证不恰当,并不是说 A => B 这个命题本身不真。

换言之,A 对论证 B 是无意义的,论证 B 的惟一方式是阅读 Go 的定义。
127 天前
回复了 dumbbell5kg 创建的主题 程序员 一个逻辑直觉的问题
这段代码不能推断任何事情——都不知道 scopes 、x 、complete 、close 是什么!假设 scopes.stream() 是 sensible 的。

如果 scopes 是空集,则 anyMatch 当然永远是 false 。
如果 scopes 不是空集,那么 getProcessStatus() 可能有副作用,连续调用两次不一定返回相同的数值。
我们也不知道 complete 和 close 是不是相等。

如果假设 getProcessStatus() 无副作用,且 complete 和 close 不相等,那么 b1 的结果等于 scopes 是否是空,这依然是非平凡的,除非上文里编译器可以推断 scopes 非空。

培养逻辑直觉的第一步是放弃错误的直觉(也就是所谓的“想当然”)。
127 天前
回复了 GopherDaily 创建的主题 Go 编程语言 Go: For-Loop-Variable 适合面试的小问题
随便看了一下文档,正确答案不是“乱序输出三个数字”,而是“乱序输出三个数字或者程序在不知道什么时候崩溃”。

https://go.dev/ref/mem

> While programmers should write Go programs without data races, there are limitations to what a Go implementation can do in response to a data race. An implementation may always react to a data race by reporting the race and terminating the program. Otherwise, each read of a single-word-sized or sub-word-sized memory location must observe a value actually written to that location (perhaps by a concurrent executing goroutine) and not yet overwritten.

另外 i 和 v 的地址未曾改变不能证明任何事情,即使每次迭代的变量是新的,编译器也可以证明复用旧的内存位置没问题,于是优化之后会看到相同的地址。
130 天前
回复了 WJC5197 创建的主题 Windows 英文版 windows 11 中文字体粗细不一怎么解决
是因为默认的字体兜底顺序先考虑日文字体。

解决方法是在数据中(比如 HTML lang 或者 font-family )指定正确的语言、字体兜底,以及使用正确编程的程序。
目测 mt_rand(10000000, 99999999) 的输出一定以 1 开始,那自然不是均匀随机的 8 位纯数字序列号(当然 MT 本身就不够随机,但这是另一码事儿了),毕竟均匀随机的 8 位纯数字序列号以 1/10 的概率以 0 开始。

对这个分布套上 str_shuffle 是会“变得更随机”(增加分布的熵)的,但 str_shuffle 之后得到的依然不是八位纯数字序列号,因为它不可能是 00000000 ,而真正随机的以 10^(-8) 的概率出现 00000000 。

如楼上 @maggch97 所说,这个数据范围出现碰撞的概率不小。最简单的做法是:预先生成好 0 到 99999999 的一个置换(打乱一个 0 到 99999999 的列表,并存下来),然后每次需要的时候取用。
131 天前
回复了 summerLast 创建的主题 分享创造 RSS 阅读器增加朗读功能
@summerLast #4 我的意思是,想要听到屏幕上显示的东西,在 macOS 下只要打开 VoiceOver 就行了。
1 ... 2  3  4  5  6  7  8  9  10  11 ... 172  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2545 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 36ms · UTC 14:34 · PVG 22:34 · LAX 07:34 · JFK 10:34
Developed with CodeLauncher
♥ Do have faith in what you're doing.