从数学角度分析为什么要戴口罩

通过SIR模型解析口罩在疫情防控中的关键作用,展示其如何降低感染率,避免小概率事件演变成大概率灾难。

很多人不重视不愿意戴口罩,主要是因为他们觉得自己离感染还很远,着是小概率事件。但是,聪明的你却可以通过数学告诉他们:虽然现在是小概率事件,但是要是他们不戴口罩和采取其他控制措施的话。马上就要演变成大概率时间。

具体来说,我们用到的是经典的SIR传染病模型:

imgSIR Model

其中N为总人口,S为未被感染的人,I为已经被感染的人,R为被治愈的人。

上面三个微分方程假设:

\1. 感染速度正比于总人口,2. 治愈率保持不变。3. 治愈了不会再发病

我们可以用现在的公开数据来模拟一下:

img

武汉一共有1000万人,假设1/10 100万人有机会接触到冠状病毒,12月8日第一个发病者发病,至今约45天。

我们可以根据公开数据大致算出上述模型的参数:

Beta(感染率/天)=0.00000015

gamma(治愈率/天)= 0.0077266

然后依据以上信息,可以随手写个代码:

imgR Code

imgS: 未感染人数; I:感染人数 R:治愈人数

我们可以看到第四十五天的时候,程序预测的:感染人数为602,治愈人数为32。和真实数据:确诊644,治愈30还是十分接近的。

然而可怕之处在哪里呢?如果我们现在什么都不做(不戴口罩也不限制出行),那么感染人数会成指数级上升,具体来说:

\1. 第50天感染超过1,000人

\2. 第65天超过10,000人

\3. 82天(3月1日)超过100,000人

\4. 第100天(3月29日)武汉一半的人都感染肺炎

5.第124天(4月12日)达到峰值全武汉79%的人都感染

画个图:

img感染人口占总人口比率随时间变化图

我们可以看到70天以前,比率都在1%以内,然而一过70天,比率开始飞速增长到总人口的80%。这样你还觉得是小概率事件吗?可能你说,那我又不在武汉我不怕。可你要这样想啊:武汉12月8日也就只有一个人得病啊,假设今天你城市来了一个病人,那么你的今天难道不是12月8日的武汉吗??这样你还会觉得离你生活很远吗?

那么戴口罩有什么用呢?

从数学上讲,戴口罩可以显著减少Beta(感染率/天),假设我们戴口罩可以让上面的beta减少y一半的值(变成0.000000075)。那么120天后,感染人数只有不戴口罩的1/100。

img

img

并且现实中,口罩的作用还能是使beta(感染率)的值减少一半还多(可能能减少到1/10),那样疫情就变得非常可控了。

所以明白了吗?一定要带口罩!


注:上面模型还没有考虑病人的死亡。假设有2.5%的死亡率,都会有2万5千人去世。所以现实情况远远比模型假设的要恐怖。

转载自: https://zhuanlan.zhihu.com/p/103890822

虽说无须指明出处,还是指明一下。

所以还是那句:别以为离你很远,要戴口罩。

image-20200125100609949

image-20200125100618672

答案是戴口罩。。。。

**项目名称:** 基于Vue.js与Spring Cloud架构的博客系统设计与开发——微服务分布式应用实践 **项目概述:** 本项目为计算机科学与技术专业本科毕业设计成果,旨在设计并实现一个采用前后端分离架构的现代化博客平台。系统前端基于Vue.js框架构建,提供响应式用户界面;后端采用Spring Cloud微服务架构,通过服务拆分、注册发现、配置中心及网关路由等技术,构建高可用、易扩展的分布式应用体系。项目重点探讨微服务模式下的系统设计、服务治理、数据一致性及部署运维等关键问题,体现了分布式系统在Web应用中的实践价值。 **技术架构:** 1. **前端技术栈:** Vue.js 2.x、Vue Router、Vuex、Element UI、Axios 2. **后端技术栈:** Spring Boot 2.x、Spring Cloud (Eureka/Nacos、Feign/OpenFeign、Ribbon、Hystrix、Zuul/Gateway、Config) 3. **数据存储:** MySQL 8.0(主数据存储)、Redis(缓存与会话管理) 4. **服务通信:** RESTful API、消息队列(可选RabbitMQ/Kafka) 5. **部署与运维:** Docker容器化、Jenkins持续集成、Nginx负载均衡 **核心功能模块:** - 用户管理:注册登录、权限控制、个人中心 - 文章管理:富文本编辑、分类标签、发布审核、评论互动 - 内容展示:首页推荐、分类检索、全文搜索、热门排行 - 系统管理:后台仪表盘、用户与内容监控、日志审计 - 微服务治理:服务健康检测、动态配置更新、熔断降级策略 **设计特点:** 1. **架构解耦:** 前后端完全分离,通过API网关统一接入,支持独立开发与部署。 2. **服务拆分:** 按业务域划分为用户服务、文章服务、评论服务、文件服务等独立微服务。 3. **高可用设计:** 采用服务注册发现机制,配合负载均衡与熔断器,提升系统容错能力。 4. **可扩展性:** 模块化设计支持横向扩展,配置中心实现运行时动态调整。 **项目成果:** 完成了一个具备完整博客功能、具备微服务典型特征的分布式系统原型,通过容器化部署验证了多服务协同运行的可行性,为云原生应用开发提供了实践参考。 资源来源于网络分享,仅用于学习交流使用,请勿用于商业,如有侵权请联系我删除!
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值