V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  GuuJiang  ›  全部回复第 1 页 / 共 20 页
回复总数  391
1  2  3  4  5  6  7  8  9  10 ... 20  
@InkStone 不了解的东西可以先去检索而不是直接断言,欧几里得除法是个专有概念,维基百科都能查到,另外 rust 语言里的各种数值类型都提供了内置的 div_euclid 和 rem_euclid 方法
@koor 同时证明了何同学在此之前甚至连 github 账号都没有
以前在外企工作时,更多的场景是中途增加更多的接受者,用的是“add xxx to the loop”,那么以此类推,大概应该是“remove xxx from the loop”吧
@GuuJiang 擦,看错标题了,以为在说反感的
有山先生
所有在概率问题上嘴犟的人都有一招可破:真金白银玩几把就老实了
当然,前提是对问题本身的认知是一致的,即:在三门问题中,主持人是知道哪里有车的,主持人永远只会开羊门
这不是一个合法的掩码,掩码必须前面若干个 1 后面跟若干个 0
如果我有罪,请让法律制裁我,而不是让我去读非等款字体显示的代码
148 天前
回复了 yujianwjj 创建的主题 Go 编程语言 go 关于函数返回 error 的一个疑问
恭喜你发现了 go 的一个致命伤,例如 Haskell 中的 Either 、rust 和 swift 中的 Result 等等基于 Monad 的返回类型,都应该是一个 sum type ,然而 go 却定义了一个 product type
兴致勃勃点进来,骂骂咧咧退出去,这不是我们想要的车牌加密
161 天前
回复了 AlohaW 创建的主题 职场话题 回老东家上班会不会很尴尬
@MapHacker 请问你考虑入党吗:doge:
想要 netstat 看到是不可能的,除非你自己魔改一个 netstat ,前面所有答案都没有审题吗?
答案就是,不要拘泥于 netstat ,而是在具体的应用里识别,因为不管是 xff 也好,代理协议也好,都是把真实 ip 作为应用层数据的一部分携带过去,后端需要自行提取
现在还算好了,以前只要弹出来屏幕就保持常亮,经常因为这个莫名其妙地没电了,后来苹果还专门针对这个做了个更新,去掉了常亮
https://v2ex.com/t/825137#reply7
经典陈年老 bug ,不同人在不同时期遇到的触发词不同,只要习惯使用拼音输入法输英文的时不时总会遇到
300 天前
回复了 unt 创建的主题 职场话题 今天才知道年终奖一次性计税的惊天 bug
@snw 醉了,没想到你的理解能力低下到这种程度,反正这个帖子肯定也已经沉了,就不要在这里继续浪费公共空间了,如果你还想要继续讨论,就去知乎上开个提问,让更多各行各业的人都参与进来,只想友情提醒你一句,V 站一般情况下无法删帖,希望你若干年后回想起来不要后悔在这里留下的黑历史,最后回复一条,此后不会再在这个帖子里回复,大过年的,你自便
你一直扯业务逻辑业务逻辑,什么叫做业务逻辑,以月收入为例“月收入实行超额累进制,3000 以下税率为 5%,3000 至 12000 部分税率为 10%”,这就叫业逻辑,并且白纸黑字地写在了法律条文里,有了这个业务逻辑,在使用速算扣除数计算时,这个速算扣除数就只能是 210 ,不可能是其它任何一个值,否则就违背了前面的业务逻辑,所以 210 不是人为定的!不是人为定的!不是人为定的!是根据“月收入实行超额累进制,3000 以下税率为 5%,3000 至 12000 部分税率为 10%”这个业务逻辑推导出来的,这点都理解不了还讨论个屁的业务逻辑,要是月收入那里敢以任何的理由在 5%、3000 和 10%这几个数字不变的前提下把 210 改动任意一点,你猜会不会被喷出翔,年终奖那里吃亏就吃亏在没有把“超额累进”这四个字明确写出来,所以给你们这种人留下了一点诡辩的空间
至于方案 B ,只要是只以年终奖除以 12 的结果去月收入表里查税率,那就跟方案 D 一样都是分摊到额外的 12 个月,这点都理解不了,确实没有任何讨论的必要了,祝大家春节快乐
301 天前
回复了 unt 创建的主题 职场话题 今天才知道年终奖一次性计税的惊天 bug
@snw 本来我还觉得你前面说的从业务逻辑角度出发的分析还体现出了你比其他人更理性的一面,别人喷你喷得有点冤,但是从这里的回复看你已经开始逐渐往为杠而杠的方向上发展了,好吧,我继续回应
你要说“速算增添数”不比“速算扣除数”优秀,OK ,我同意,因为这本来就不是这个类比的重点,这个类比是想要说明,无论“速算扣除数”还是“速算增添数”,在计算上都是完全等价的,因为它们分别都是从超额累进的原始定义出发推导出的两种中间结果,这两种中间结果在正确使用的前提下都没有问题,但是一旦忽略了适用条件产生了误用,就会形成完全相反的结果
你说的应该是-3000 而不是-36000 ,这个错误简直比起“-210 还是-2520”那个错误还要离谱,但是好处是足够明显,所以也许可以作为一个很好的切入点来帮你理解-210 到底错在哪里,先叠个甲,接下来我会使用一些需要具备一定的抽象思维能力才能理解的不严谨的设定,如果你理解有困难,请自行去咨询学数学和学物理的朋友,让他们给你解释,如果我们给前面出现过的所有公式里的一些数字添加上量纲,年终奖的数字量纲为“元”,12 的量纲为“月”,那么元除以月得到了“元/月”,“元/月”乘以月得到元,于是你就会发现 36001 这个和 3000 这两个数字的量纲都不一样,而量纲不一样的数字之间根本就不可能执行加减运算,其实原本的那个错误里之所以-210 应该变成-2520 ,根本原因绝不是像你想的那样“一群数学家为了让数字变得好看而强心凑上去的一个值”,而是乘以 12 后把量纲从元/月变成了元,这样才能和元进行加减运算,“速算扣除数”和“速算增添数”的两个例子里,都是减去或者加上了一个量纲不正确的量,而一旦把量纲修正了,二者都能同时得到正确的结果 1800.1 ,这从另一种角度揭示了原本那个错误的本质
1  2  3  4  5  6  7  8  9  10 ... 20  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1126 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 36ms · UTC 18:57 · PVG 02:57 · LAX 10:57 · JFK 13:57
Developed with CodeLauncher
♥ Do have faith in what you're doing.