CRVV 最近的时间轴更新
CRVV
ONLINE

CRVV

V2EX 第 79825 号会员,加入于 2014-11-02 20:41:57 +08:00
今日活跃度排名 10655
卖两个青轴机械键盘, Cherry G80-3000, Filco Minila 67
二手交易  •  CRVV  •  2017-02-06 20:07:05 PM  •  最后回复来自 CRVV
4
卖台 PS3, 送 6 个游戏, 一共 700
二手交易  •  CRVV  •  2017-02-05 20:09:34 PM  •  最后回复来自 YORYOR
8
测试 135
沙盒  •  CRVV  •  2016-11-06 20:22:09 PM
CRVV 最近回复了
@CRVV 日期写错了,是 2022.01.01 - 2022.12.05
@sublimeyue

> 截至 2022 年 12 月 2 日,全球已累计报告逾 6.43 亿例确诊病例,其中逾 663.7 万人死亡[9],病死率约为 2.09%
世界各国对该病病死率的估计值差异甚大,多数国家该病的观测病死率在 0.5%-5.0%之间

你无意或有意地忽略了病毒有多个变种且多个变种的致死率不同这个事实,用全部的确诊病例数和全部的死亡数来算死亡率。这样显然高估了当前的实际死亡率。

> 那么做个大概估算, 如果现在向美国一样, 中国也 90%多的人都感染新冠, 那么会死多少人? 我觉得并不会少.
所以我有夸大吗? 我觉得没有.

你没说估计出来到底会死多少人,你连说都没说,当然没有夸大。
如果你想暗示中国的死亡数字会是 14 亿 * 0.5%-5.0% = 700 万 - 7000 万,那么你有夸大,理由前文已述。


我换一个更准确的方法来估算死亡率。
因为中国一直在积极的防控这一传染病,一直都防得不错,所以只有传染性大增的 O 变种真的对中国造成了实质性的影响。之前的所有变种对中国的影响,和其它国家相比几乎都可以忽略。
还有第二个原因,中国做核酸检测的次数非常多,应该说远比其它任何一个国家都多,这样能得到全世界最准确的病例数据。每一个确诊病例死亡病例肯定都做了核酸检测,而其它国家的就不一定了。
O 变种出现 2022 年,所以我们直接看 2022 年中国的数据。
2022.01.01 - 2022.12.15
总病例数是 1648293 ,总死亡数是 345 ,死亡率是 0.02%,或者说万分之二。远比你说的 0.5-5.0% 低。
1. 「公司付 X%,个人付 Y%」是以什么为基准计算的,扣完五险一金之后个人所得税又怎么计算?

比如谈的每月工资 10000 ,个人和公司的 x% 都用这个 10000 来算


2. 既有年终奖又有月基本工资的时候又该怎么算

年终奖不用交五险一金,税好像有不同的算法吧我不太确定。


3. 我看到个人所得税速算扣除数就觉得头晕,完全不知道怎么拿来算,而且现在个税制度一直在改革,好像每月的个税比例都不一样,就更难算了;

个人所得税的算法是这样的
五险一金部分不用交所得税,先减掉,比如月薪 50000 ,假设扣完五险一金还有 40000 。
每个月有 5000 的免税额,就是说这里面有 5000 不用交税,这样还剩 35000 。
然后有那些租房养娃什么的免税额,比如有 3 个娃 1 个老人,这样又有 5000 不用交税,这样还剩 30000 要交税的收入。
这样,每个月的 30000 ,叫做应纳税所得额。

一月,当年的应纳税所得额是 30000 ,税率 3%,交税 900
二月,当年的应纳税所得额是 60000 ,其中 36000 以下的部分是 6000 税率 3% 就是 180 ,36000 以上的部分是 24000 税率 10% 就是 2400 ,这个月要交税 180+2400=2580
三月,当年的应纳税所得额是 90000 ,这个月的收入都是 36000 以上的部分,税率 10% 交 3000 的税
四月,当年的应纳税所得额是 120000 ,这个月的收入都是 36000 以上的部分,税率 10% 交 3000 的税
五月,当年的应纳税所得额是 150000 ,这个月的收入在 144000 以下的部分是 24000 税率 10% 交 2400 的税,还有 6000 在 144000 以上税率 20% 交 1200 的税,这样一共交 3600 的税
后面都是这样算下去的。

这样算需要一个月一个月地累加,有人觉得麻烦,就搞了个速算扣除数。比如第二个月的总数是 60000 ,36000-144000 之间的速算扣除数是 2520 ,60000*10% - 2520 = 3480 就得到了总的税额,再减掉一月的 900 ,得到二月的税是 2580 。
如果要算一年的税额,直接 30000*12 = 360000 ,税率是 25%,36000*25% = 90000 ,再减掉速算扣除数 31920 ,得到全年的个人所得税是 58080 。这样比一个月一个月加上来要少按几下计算器,如果用 Excel 来算我觉得这东西完全没必要。

因为工资是按月发的就每个月都这么算,但如果在 10 月 31 日离职了,后面两个月没有工资,但免税的额度还在,全年的应纳税所得额就变成了 30000*10 - (5000+5000)*2 = 280000 ,但是在 10 月已经交了 300000 对应的税,这样第二年就可以申报把多交的 20000*20% = 4000 的税钱退回来。这个情况我的理解是这样,但我也没操作过,不保证正确。


4. 每个城市的算法还不太一样!

五险一金不一样,差别不会很大,税是一样的
21 天前
回复了 qiyong 创建的主题 程序员 面试中遇到的一道 sql 题
@raysonlu

“不让 mysql 高负荷运行复杂查询”

这应该是一个对关系型数据库的误解,来自于 MySQL 的 planner 太弱。

要得到一个查询的结果,不论查询是不是分步的,总的工作量一定有下限。在 planner 足够好的情况下,一定是分步查询的工作量大,一条大 SQL 的工作量小(因为不需要把可能很大的中间结果传回来),所以写一条大 SQL 才是节约数据库的做法。

在 MySQL 上,“planner 足够好” 通常不成立,这事就反过来了,分步查才是工作小的做法,所以才有分开写简单 SQL 的习惯。换成 PostgreSQL 就不是那么回事了。

至于其它的很多都是需求问题,很多时候产品经理的需求就要分页要搜索,总不能直接说这东西做不了吧。
21 天前
回复了 qiyong 创建的主题 程序员 面试中遇到的一道 sql 题
@raysonlu

如果能分步处理当然分步处理是很多人首选的方案,因为代码比较好懂,会写复杂 SQL 的人没那么多。

但就这个题来说,如果商品有 1 亿个,销量表是分小时的,要查所有商品,按近一个月的销量倒序排列,要能搜索能翻页,还是那种能直接跳到第 10000 页的设计。这样的不太可能分步来处理吧,每一个中间步骤的结果都很大。实际的需求通常都比这个复杂。

写一个大 SQL 可能直接就把数据库弄死了,当然也不行。
所以我上面说 BigQuery ,这东西就是干这个事用的,应该算是解决这种问题的方案之一。
22 天前
回复了 qiyong 创建的主题 程序员 面试中遇到的一道 sql 题
@DinnyXu
这种 SQL 在很多地方都用得到,而且这个题其实不难。
如果每个表都有几亿行,用 BigQuery 写一句 SQL 就能实现,速度也不慢。如果不写 SQL 你打算怎么做?
22 天前
回复了 qiyong 创建的主题 程序员 面试中遇到的一道 sql 题
首先把销量的类型改成数字, `sales_volume` INT

最后都需要套一层子查询来重新排序,就不写了。
这三种写法都是用 ORDER BY volume DESC LIMIT 3 来选出前 3 ,还可以用 rank <= 3 来选前 3 的,如果有重复的会得到不同结果
都可以在最新的 MySQL 上执行

SELECT goods.name,
goods_sales_record.sales_volume,
goods_group.name AS group_name,
t.group_volume
FROM goods
INNER JOIN goods_sales_record ON goods.id = goods_sales_record.goods_id
INNER JOIN goods_group ON goods.group_id = goods_group.id
INNER JOIN (SELECT goods_group.id, sum(goods_sales_record.sales_volume) AS group_volume
FROM goods_group
INNER JOIN goods ON goods.group_id = goods_group.id
INNER JOIN goods_sales_record on goods.id = goods_sales_record.goods_id
GROUP BY goods_group.id) AS t ON t.id = goods_group.id
ORDER BY 2 DESC limit 3;

SELECT goods.name,
goods_sales_record.sales_volume,
goods_group.name AS group_name,
t.group_volume
FROM goods
INNER JOIN goods_sales_record ON goods.id = goods_sales_record.goods_id
INNER JOIN goods_group ON goods.group_id = goods_group.id
CROSS JOIN LATERAL (SELECT sum(goods_sales_record.sales_volume) AS group_volume
FROM goods INNER JOIN goods_sales_record on goods.id = goods_sales_record.goods_id
WHERE group_id = goods_group.id) AS t
ORDER BY 2 DESC limit 3;

SELECT goods.name,
goods_sales_record.sales_volume,
goods_group.name AS group_name,
sum(sales_volume) OVER (PARTITION BY goods_group.id) AS group_volume
FROM goods
INNER JOIN goods_sales_record ON goods.id = goods_sales_record.goods_id
INNER JOIN goods_group ON goods.group_id = goods_group.id
ORDER BY 2 DESC
LIMIT 3;
22 天前
回复了 GopherDaily 创建的主题 MySQL [mysql] 混乱的时区
@GopherDaily

utf8mb3 是 MySQL 自己造出来的词,utf8mb4 也是
UTF-8 这个东西,本来是最多 6 bytes 的变长编码,根本没有什么 mb3 mb4
后面觉得 6 bytes 没用,4 bytes 就足够了,就把标准改成了最长 4 bytes

https://en.wikipedia.org/wiki/UTF-8#History
22 天前
回复了 GopherDaily 创建的主题 MySQL [mysql] 混乱的时区
如果已经注意到这种问题了,答案就是别用 MySQL ,这玩意遍地是坑。


@simonCN
@maggch97
op 说的问题不是怎么存时间,怎么用 timestamp.
他说的是 MySQL 的 timestamp ,不是通常说的 unix timestamp
(类似的还有 MySQL 的 utf8 也不是 UTF-8)

MySQL timestamp 的坑至少包含了:
1. 范围是 1970-2038 年
2. TIMESTAMP 直接把输入用本机的时区来理解(如果有冬夏令时,就不可能正常工作),MySQL 8.0.19 才能自己指定时区。
3. 默认自动更新,DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP

这个类型根本就没考虑拿来存一个正常的时间,它的设计就是用来让你 ON UPDATE CURRENT_TIMESTAMP 的

DATETIME 的坑可能更多,一样很难把时区搞定。换个 SQLite 都没这么多坑
26 天前
回复了 RATIONALITY 创建的主题 问与答 求问五年内最稳的 4%收益方案
首先,收益率高的东西,风险一定高。
当然收益率低的东西风险不一定低,比如恒大的债券在 2021 年的收益率还只有 8%。

正常来说,银行存款的风险最小,你找一个利率 4% 的存款,假设银行和存款保险都不破产,这样就是安全的。
至于有没有其它小众方法能做到类似的收益率和风险,这就成高端问题了。
银行和存款保险有多大概率破产,也是高端问题。
高端问题的意思是,如果你自己不知道答案,你就不可能在不花大钱的情况下知道答案。

这里还有个怎么算收益的问题,假设有一家银行给你的人民币存款利率是 4%,然后人民币贬值了 5%,这样你认为自己的收益是正的还是负的?
这是个人偏好问题,根据偏好不同,op 这个问题的答案也不一样。
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   4703 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 26ms · UTC 09:09 · PVG 17:09 · LAX 01:09 · JFK 04:09
Developed with CodeLauncher
♥ Do have faith in what you're doing.