随笔 - 106  文章 - 2  评论 - 2017  阅读 - 43万 

前些天,试着编程解一下爱因斯坦出过一道著名的智力题,多年前就见过,当时尝试编程解决,失败了。经过几年编程实践,不参考别人的,看能不能独立写出一个比较好的算法。

如今以不可同日而语之犀利眼光,一眼发现这些条件真面目,不过是一个个Predicate委托而已。当然先建五个枚举:

又刷刷刷地敲出了这样的代码:

写了几段,就意识到不对劲了。主要是每个条件最后一句,是该判断呢,还是该赋值呢?比如说如果一个人,住在红房子里,那他一定是英国人。那就要看这个人有哪些属性已经确定了。

而且,如果既现在既不确定哪个住红房子,也不知道谁是英国人,怎么办?经过反复思考,我想每个条件,除了能提供判断,以及合适时赋值,还要提供推断,即可能的方案以供尝试。先选一种方案,然后下个条件再判断现在的状态是否合法,是的话再提出一组方案,不然就选上一条件中的下一个方案。

想到这里,算法的轮廓大致浮现了出来。每个条件,将成为一个个Condition类的实例。而另一个领域模型,之前没有想到的类,已经呼之欲出,即将登上舞台成为主角。导演,自然是偶了。

这场好戏,现在该考虑故事背景了。想在潘多拉星球上拍神雕侠侣,大概观众会吐血,当然更别说种山楂树,观众不吐我都要吐了。在上下班路上,内心经过痛苦的斗争,偶决定放弃风花雪月的属性,因为给每个属性创建状态标识的成本太高。于是偶移师海阔天空的大自然,不加雕琢的Dictionary成了这部戏的主要外景。

Guy类的主要函数,就是围绕Guy.Properties这个属性字典进行操作,如何封装取决于Condition类的实现。对于条件中单独一个属性,本来可以用 KeyValuePair<string,int>表示,不过太长,所以自己写了个Property类。要是类型能定义别名就好了。看题目中的条件,不少都是根据位置作判断的,所以位置是特殊的属性,如果能用来作Guy的主键,应该可以事半功倍。

下面,期待中的主角露出了庐山真面目,完全是我们以抽象思维创作出来艺术形像。其实很简单,但没艺术细胞的想不出,不会创作的写不出,大家认为呢?

接着来参观下为主角量身打造的舞台吧,大导演拍大片,当然要打造大舞台,比世博园还大,看个样子就行了 :)

这场戏分十几场来拍,有了前面的准备,剧本一气呵成:

看上去万事俱备,只欠东风了。事实上要借到东风,还须一些神通,最后一步还有一道难题,这么多场景如何串联在一起?这种戏偶以前从未拍过,考验功底的时候到了。在僵局的时刻,“搜索树”在脑中灵光一现,对,听这名字就是我要的。虽然不知所谓,也从未用过,但“树”我懂的啊。实话说,偶很讨厌写这些树啊图啊的,不过关键时刻,难不倒偶的。

非常顺利,人就要敢于尝试和突破。照例,杀青前,测试下结果:

image

有点奇特是吧,结果差距怎么这么大?可千万别被迷惑了,由于输出结果时用了Enum的反射,这是个绝对的性能杀手。在我Core7200处理器,32位Win7电脑上,真正计算过程不到2ms!

源代码下载,里面几个类都重写了ToString方法,在VS下调试时相当方便,这是其它开发环境望尘莫及的。怎么样,还是不够快啊。那好,下期再来优化它。

posted on   小城故事  阅读(3431)  评论(4编辑  收藏  举报
编辑推荐:
· Linux系列:如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列(二):开始使用ML.NET
· 记一次.NET内存居高不下排查解决与启示
· 探究高空视频全景AR技术的实现原理
· 理解Rust引用及其生命周期标识(上)
阅读排行:
· 阿里最新开源QwQ-32B,效果媲美deepseek-r1满血版,部署成本又又又降低了!
· 单线程的Redis速度为什么快?
· 展开说说关于C#中ORM框架的用法!
· SQL Server 2025 AI相关能力初探
· Pantheons:用 TypeScript 打造主流大模型对话的一站式集成库
点击右上角即可分享
微信分享提示