四道烧脑的数学题目(r11笔记第31天)

今天来点有趣的内容,可能比较烧脑。是四道有意思的题目,来看看大家的数学是不是体育老师教的,当然答不出来就玩个热闹,如果觉得简单就在文章末尾留言,让我们一起膜拜一下。


题目1:

王师傅是卖鱼的,一斤鱼进价45元,现亏本大甩卖,顾客35元买了一公斤,给了王师傅100元假钱,王师傅没零钱,于是找邻居换了100元。事后邻居存钱过程中发现钱是假的,被银行没收了,王师傅又赔了邻居100,请问王师傅一共亏了多少?(这道题目不简单,到底亏了多少?

这种题目真是烧脑,我从黑盒的角度来看待,拆分为下面的几个事件:

事件 王师傅的花费
进1公斤鱼,一斤45元 -90
收到100元钱 100
没零钱,找邻居换了100 0
找给顾客65 -65
邻居发现是假钱,王师傅赔了100 -100

这样一来,答案就是亏了155

当然还有一个王师傅卖鞋的版本,价格不同,思路还是差不多。

王师傅是卖鞋的,一双鞋进价60元甩卖40元,顾客来买双鞋给了张50,王师傅没零钱,于是找邻居换了50元。事后邻居发现钱是假的,王师傅又赔了邻居50。请问王师傅一共亏了多少?

我在知乎上看到了很多有才的人,有人给了四种解法。
可以参考链接:https://www.zhihu.com/question/35359446/answer/62416003
【解法一:按守恒】
算王师傅算不清,我们算别人

  • 邻居:给出50,收到50假币,后来又从王师傅处讨回50真币,所以邻居不赚也不亏;
  • 顾客:付出50假币(价值0),得到进价60的鞋子和10块找零,净赚70;
  • 王师傅:三个人构成封闭系统,价值守恒,所以顾客的盈利来自王师傅,即王师傅损失70。

【解法二:按事件】
王师傅从邻居处拿到的钱后来又换回去了,所以可以直接删掉邻居的戏份。于是王师傅身上一共发生了两件事

  • 卖鞋
  • 收到假币

分析两件事的收益情况

  • 卖鞋:60的鞋卖40,赔20,即-20
  • 收到假币:用真金白银的50换了假的50(实际价值为0),赔50,即-50

综合,赔70

【解法三:按过程】
所以也是赔70

【解法四:按收支】
王师傅的获得:

  • 从邻居处获得50块真币

王师傅的失去:

  • 失去进价60的鞋
  • 找给顾客10块
  • 赔给邻居50块

+50-60-10-50=-70
所以还是赔70块。

题目2:

王师傅很忙,卖鱼又卖鞋,我们再来一道卖鞋的。

王师傅是卖鞋的,一双鞋进价20元卖30元,顾客来买鞋给了张50,王师傅没零钱,于是找邻居换了50元。事后邻居发现钱是假的,王师傅又了邻居50。请问王师傅一共亏了多少?

所以按照同样的思路,那就很简单了。

答案就是-20+50+0-20-50=-40

题目3

如果你有无穷多的水,一个3公升的提捅,一个5公升的提捅,两只提捅形状上下都不均匀,问你如何才能准确称出4公升的水?

这个题目把预先的可用条件都封杀了。

假设3公升的提供为A,5公升的为B,一种思路就是:

1)B中放入5公升的水   A(0)B(5)

2)B中的水导入A中,这样B中还剩下2公升,A中是3公升。 A(3)B(2)

3)倒掉A中的3公升水  A(0)B(2)

4)B中的水导入A中   A(2)B(0)

5)B中倒入5公升的水  A(2)B(5)

6)B中的水导入A中  A(3)B(4)

核心思路就是7-3=4

题目4

在9个点上画10条直线,要求每条直线上至少有三个点?

这道题确实烧脑,我是没做出来。如果想做的可以先不要放下看,自己想一想。

分析:10条直线,每条线至少3个点,总共需要40个点(不考虑重叠)。说明9个点上每个点至少有3或4条直线通过。       

细分化为:有3个点被4条直线通过,6个点被3条直线通过,这样3*4+6*3 = 40才能满足条件需要。

时间: 2024-09-25 09:22:13

四道烧脑的数学题目(r11笔记第31天)的相关文章

MySQL Online DDL(二)(r11笔记第88天)

对于Online DDL,之前简单分析了一些场景MySQL中的Online DDL(第一篇)(r11笔记第3天),其实有一个很关键的点没提到,那就是online DDL的算法,目前有三个操作选项,default,inplace,copy可选 具体可以参考  https://dev.mysql.com/doc/refman/5.6/en/innodb-online-ddl.html > select count(*) from newtest; +----------+ | count(*) |

需要了解的pssh(r11笔记第28天)

   昨天的一篇文章,关于ssh命令的几个使用小技巧(r11笔记第27天),也收到了不少朋友的反馈,其中有个朋友提议说还是用pssh吧,我想想也是.     对于pssh早有耳闻,但是一直没有尝试用过.自己体验了一番,感觉确实不错,对于我们日常碰到的批量操作都可以胜任.当然还有很多可选方式,比如pgm,fabric,puppet,ansible等,只要能实现需求,怎么玩都是套路,而且也急不得,一个学明白了学其他的就会容易很多.      关于pssh的p是什么含义,我和朋友还讨论过,到底是pyt

复杂SQL性能优化的剖析(二)(r11笔记第37天)

    昨天的一篇文章复杂SQL性能优化的剖析(一)(r11笔记第36天) 分析了一个SQL语句导致的性能问题,问题也算暂时告一段落,因为这个语句的执行频率是10分钟左右,所以优化后(大概是2秒左右,需要下周再次确认)的提升很大.    对于优化是一个持续的改进,我们碰到的问题,最终的原因可能五花八门,但是正如柯南所说,真相只有一个.我把这个问题和前几天处理的一个问题结合起来,前几天处理了一个紧急问题,也是有一个SQL语句的执行计划发生改变,这个语句的业务比较关键,触发频率是每分钟一次,如果一旦

百倍性能的PL/SQL优化案例(r11笔记第13天)

我相信你是被百倍性能的字样吸引了,不过我所想侧重的是优化的思路,这个比优化技巧更重要,而结果嘛,其实我不希望说成是百倍提升,""自黑""一下.     有一个真实想法和大家讨论一下,就是一个SQL语句如果原本运行20秒,优化到了1秒,性能提升该说是20倍还是提高了95%.当然还见过一种说法,一条SQL语句每次运行20秒,每天运行100次,优化后每次运行1秒,运行还是100次,那么性能提升是说成优化累计时间为100*20-100=1990秒? 好了,我们来看看PL/S

闪回原理测试(二)(r11笔记第23天)

    对于闪回部分,Oracle本身提供了非常多相关的特性,我个人对于闪回数据库这个特性最为喜爱,尤其是应用再Data Guard环境中,真是一大杀器.     而对于DML的闪回部分其实也相对比较容易理解,毕竟就是原操作的逆操作,之前通过logminer的方式来读取redo来间接得以印证.Oracle闪回原理-Logminer解读redo(r11笔记第17天)     但是对于DDL的闪回,这个特性真是非常强悍了.比如一个truncate操作,它的逆操作改怎么定义,就很难去界定了.当然这个里

一个SQL性能问题的优化探索(二)(r11笔记第38天)

继续前几天的一个案例一个SQL性能问题的优化探索(一)(r11笔记第33天) 如下的SQL语句存在索引字段CARD_NO,但是执行的时候却走了全表扫描,因为这是一个核心表,数据量很大,导致数据库负载很高. SQL_FULLTEXT ---------------------------------------------------------------------------------------------------- SELECT ID,CN,CARD_NO,TO_CHAR(CHAR

用Oracle的眼光来学习MySQL 5.7的sys(下)(r11笔记第25天)

昨天写了篇分析sys的文章,用Oracle的眼光来学习MySQL 5.7的sys(上)(r11笔记第24天)收到了一些朋友的反馈,还不错,今天继续努力,再整理一篇. sys还是很有借鉴意义     今天还和同事偶然聊起sys schema的事情,我觉得有几个地方要值得借鉴. 1)原本需要结合information_schema,performance_schema查询的方式,现在有了视图的方式,显示更加直观 2)sys schema的有些功能在早期版本可能无从查起,或者很难查询,现在这些因为新版

insert导致的性能问题大排查(r11笔记第26天)

今天开发的同学小窗口消息给我,向我咨询一个ORA错误的问题. 错误代码是ORA-30036,使用oerr ora 30036查看,由于是undo空间无法扩展导致. 这是一个统计业务的数据库,而且平时的负载其实并不高,确实有一些奇怪.首先排除了大事务导致的原因,查看数据库日志,和开发同学沟通,没有发现相关的错误信息. 所以第一感觉这是一个偶然发生的情况,不过开发的这位同学貌似碰到了问题,他说从应用端抛出了ORA-30036的错误. java.sql.BatchUpdateException:ORA

Data Guard实现故障自动切换(二)(r11笔记第39天)

   今天下午我的一个朋友碰到了一个Data Guard的问题,大体是主备网络出现问题,因为环境中配置了自动切换,结果备库就自动切换为了主库,这样就成了"双主",我帮忙看了下,对备库做了闪回,然后直接转换主库为备库角色,一个看似繁琐的修复工作就完成了.    在一个一主多备的环境中,的确需要一个强大的工具来支持,所以最后朋友说DG Broker真是个好东西,我回了句 用好了DG Broker,手工管理Data Guard就是小米加步枪啊.    就如同我昨天文章Data Guard故障