逻辑难题-问路

简介: 逻辑 难题 问路

问题

‍A国只有两种人,一种永远说真话,一种永远说假话,你来到A国,到了二叉路口不知道哪条道通向首都,路口有这个国家的一个守卫人员(A国人),你只能问一个问题,守卫只回答是或不是,请问怎样问才能确定哪条路是通往首都的路?

答案

(你指向一条路,问他)如果我问你“这条路是去首都的路吗”,你会回答“是”,是不是?

分析

令p为守卫人员是永远说真话的人,那么非p就是永远说真话的人

情况1

假设你指的路是去首都的路,你遇到的人是p,那么你问得去首都的路他应该回答是,所以他回答你的问题“你会回答是”是一致的,所以他会回答是。

情况2

假设你指的路是去首都的路,你遇到的人是非p,那么你问得去首都的路他应该回答不是,所以他回答你的问题“你会回答是”是不一致的,因为他是永远说假话的人,所以他会回答是,因为如果回答不是的话。他就说真话了,所以他要说假话是。

情况3

假设你指的路不是去首都的路,你遇到的人是p,那么你问得去首都的路他应该回答不是,所以他回答你的问题“你会回答是”是不一致的,所以他会回答不是。

情况4

假设你指的路不是去首都的路,你遇到的人是非p,那么你问得去首都的路他应该回答是,所以他回答你的问题“你会回答是”是一致的,但是由于他是永远说假话的人,所以他要回答不是。

结论

这样基于情况1和2,情况3和4,就可以得到回答是的话就代表你指的路是去首都的路,回答不是则你另一条路是去首都的路。这样问一个问题就确定了去首都的路。

目录
相关文章
架构师必备底层逻辑:设计与建模的技术深度探索
【8月更文挑战第13天】在软件开发的浩瀚星海中,架构师如同星辰指引,他们不仅规划着系统的蓝图,更在底层逻辑上精雕细琢,确保系统的稳健与高效。其中,“设计与建模”作为架构师的核心能力之一,是连接业务需求与技术实现的桥梁。本文将深入探讨架构师在设计与建模过程中的关键思维与实践方法,为工作学习中的技术同仁提供一份宝贵的干货分享。
119 3
业务系统架构实践问题之在某些情况下,将能力代码和业务逻辑严格分层可能是一个挑战问题如何解决
业务系统架构实践问题之在某些情况下,将能力代码和业务逻辑严格分层可能是一个挑战问题如何解决
业务系统架构实践问题之充血模型在实现上可能会带来问题如何解决
业务系统架构实践问题之充血模型在实现上可能会带来问题如何解决
业务系统架构实践问题之模型本身会变得复杂臃肿如何解决
业务系统架构实践问题之模型本身会变得复杂臃肿如何解决
关于DEFI模式系统详细方案技术开发逻辑讲解方案
关于DEFI模式系统详细方案技术开发逻辑讲解方案
系统的混乱并业务本身之复杂,我们并不擅长处理『简单』
![](https://ata2-img.oss-cn-zhangjiakou.aliyuncs.com/neweditor/846d5052-1e21-4f9c-8f52-aaa37cacc407.png) # 前言 一群高智商青年在餐厅吃饭,餐桌上一个瓶盖标识为盐的瓶子里装得是胡椒粉,而标识为胡椒粉的瓶子里装得却是盐,他们想出了一个充满才气的方案来完成对调--仅需要一张餐巾纸、一根吸管和两个
48737 10
系统的混乱并业务本身之复杂,我们并不擅长处理『简单』
系统的混乱并非业务本身之复杂,我们并不擅长处理『简单』
软件工程最大的成本在于维护,为了未来可扩展、为了未来更灵活,我们往往会增加很多很多奇奇怪怪可有可无的代码,增加这些代码可能只需要几分钟,但移除这些代码花费的精力与承担的风险,却数倍于此。我们不断 YY 着所谓的未来,却让现在越来越糟。系统的混乱并非业务本身之复杂,我们并不擅长处理『简单』。
1246 1
系统的混乱并非业务本身之复杂,我们并不擅长处理『简单』
降低前端业务复杂度新视角:状态机范式
无论做业务需求还是做平台需求的同学,随着需求的不断迭代,通常都会出现逻辑复杂、状态混乱的现象,维护和新增功能的成本也变的十分巨大,苦不堪言。下图用需求、业务代码、测试代码做对比:
390 0
降低前端业务复杂度新视角:状态机范式
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等