你调用add_item方法的时候要传入一个对象（item）
比如：my_home.add_item(bed) 那么item.area 就是bed.area
关注这个问题快一周了，到目前来说还是没发现什么太大的惊喜。我感觉建筑设计界还是要学习一个，不要看到深度学习很火，就弄个大新闻，把这玩意往建筑设计上搬呀。
其实深度学习这事儿到底怎么就能和建筑设计挂钩上？如果单单指“深度学习”，那我的理解是套用了许多层的人工神经网络，这种技术能在建筑设计中扮演什么角色？我目前还真没发现直接用深度学习这种技术来辅助建筑设计的例子。但是如果把题主提问的概念放宽松一点，变成“如何使用机器学习等算法来帮助建筑设计”，那我想还是有比较好的例子的。
机器学习技术是用来让程序的运行性能随着输入量和时间的积累慢慢提高的一种技术。例如你写了一个程序来预测一栋别墅的房价，这个程序的作用是能根据输入数据的[城市，街道，区位，面积，户型，..]等参数预测房价，为了提高程序预测的准确度，你需要先给程序喂一些已经有了估价结果的数据，程序学习一定的数据以后就能自己预测房价了。那么，这种程序工作的方式和我们做建筑设计的工作流程有什么联系呢？ 我们做设计时，同样也是先调研和参考大量同类建筑的案例，积累到一定量以后，才能自己动手开始做设计。了解了这一点，便可以设想一种利用机器学习来辅助建筑设计的思路：先让程序学习以前的建筑设计方案，然后程序就能自己去做设计了！
这篇2010年的论文 Computer-generated residential building layouts 可以说就是以上思路的典范。作者自称“使用数据驱动的方式设计了能自动创建视觉效果非常好的建筑布局的工具”，但我觉得论文的质量是远远超过了这样谦逊的描述，因为论文实现的思路极大程度借鉴了现实中建筑师开展设计工作的流程，而且用了贝叶斯网络这个非常漂亮的数学模型描述了一个建筑program在空间中的分布，而贝叶斯网络的训练数据全部来自真实的建筑师的设计方案。个人认为用机器学习的思路去处理建筑布局问题相比于过去十年来Shape Grammar的那种Procedural Modeling的思路来得更为正确。
论文是怎么展开的呢？首先，作者总结了前人工作，说明了以前基于穷举的算法都行不通，要在3D空间中去穷举这么复杂的空间分配问题就和猴子随意敲键盘得到一部莎士比亚作品的难度差不多。接着作者又批判了上个世纪90年代Muller搞的Shape Grammar那一套也不行，因为Shape Grammar就是图形语法，我们知道，编程语言是是基于有限规则的语法集生成的，而建筑设计中这样的规则条款很难形式化描述，而且会倾向于让语法数量变得无穷多。顺带一提，几十年前计算机科学家在攻克语音识别和机器翻译难题的时候，也是认为自然语言是完全基于有限的规则生成的，但后来才发现行不通，直到后来改成基于统计的方法进行研究后，才有了突破性进展。 那么shape grammar不适合建筑设计的另外一点在于，建筑设计不是玩弄图形变换的游戏，每一个建筑空间都有基于功能，心理和效用等因素的考虑。之前也有过用shape grammar分析赖特壁炉式住宅的语法规则的论文，但是应用范围实在太窄。所以这条路是走不通的。
论文作者认为，做方案，一定要基于人的舒适和心理需求，习惯和社会关系等因素，将他们综合考量后才会有比较合理的结果。例如，房间的形状最好是凸包而不要做成凹的，因为在采光上，家具摆放和视线上方正规整的形体都更优；建筑各个功能要形成开放性 - 私密性的梯度，因为这正反映了建筑被使用的方式。 为了研究更好的方法，作者去找到了一家建筑事务所的建筑师们向他们咨询职业建筑师的工作方式，得到了一个特别有用的结论：建筑师在初期和客户咨询后，在画平面的详图之前，一般都会用泡泡图来思考问题，而泡泡图则反映了一个建筑方案高度浓缩的信息，包括私密性，房间邻接关系，采光，业主喜好和文化习俗。
泡泡图在在建筑师看来是展开方案设计工作的第一步，在计算机科学家看来则是一种复杂的数据结构——图。从使用者或者任务书弄出一张泡泡图是建筑师专业能力的体现，不管这种能力是基于长期训练的素养也好，还是临时起意的构想也好，我们知道这张图包含的信息量很大就对了。 那现在问题是，如何让计算机来生成这样一张泡泡图呢？
这个时候就要轮到本回答开始的机器学习算法登场了。作者用来一个概率图模型——贝叶斯网络来描述建筑师做出来的泡泡图。用人话说，就是用这玩意来描述建筑方案中每一个部分在空间中的概率分布。好像说起来还是不太容易懂，但总之，我们知道了，这个模型可以让电脑知道对应一个成功的建筑方案，客厅、卧室和走廊等出现在某些位置的概率比出现在另外一些的位置的概率高，而概率高的位置正是合理的位置，这样就更容易生成好的方案。
针对贝叶斯网络的训练，作者搞了120套住宅建筑方案作为训练数据来喂给程序吃。现在程序总算是知道建筑方案的基本做法了，以下就是基于贝叶斯网络生成的泡泡图：
搞定了泡泡图之后，怎么从这玩意生成建筑平面呢？ 作者几经周折，最后用了Metropolis算法来搞定。具体的生成过程描述都在论文里面有写，我就不详细写了（其实是看不懂。） 再下一步是生成3D模型，作者比较自豪地说，他搞的这个算法真正实现了多层建筑方案的生成，而以前的基本只能生成单层的平面，作用有限。以下是一些成果：搞定了泡泡图之后，怎么从这玩意生成建筑平面呢？ 作者几经周折，最后用了Metropolis算法来搞定。具体的生成过程描述都在论文里面有写，我就不详细写了（其实是看不懂。） 再下一步是生成3D模型，作者比较自豪地说，他搞的这个算法真正实现了多层建筑方案的生成，而以前的基本只能生成单层的平面，作用有限。以下是一些成果：
6张平面有几张是人做的方案，剩下的都是机器做的，大家可以猜一下机器做的是哪几个。答案论文里面有说。6张平面有几张是人做的方案，剩下的都是机器做的，大家可以猜一下机器做的是哪几个。答案论文里面有说。
最后是生成的3D模型，家具是手工布置的。还是颇具真实度呢！
作者最后提到，准备把这个东西运用到更多的建筑类型上，例如办公楼等。如果这玩意儿成熟，再也不用担心建筑师不失业了，偶也！
最后我再说说对这玩意的评价吧。最近几十年知识工作的自动化简直如火如荼地吹遍天南地北的各个行业，许多人都担心低端的劳动职位会不会被取代，例如驾驶汽车，快递，写新闻稿，翻译，速记等等等，这种担心真的不是毫无理由啊！当优雅简洁的数学模型遇到计算机这个可以暴力计算的机器，结合起来就创造了一类又一类可成规模复制的智能机器，想想还是让人后怕的。不过也不用太担心就是，建筑设计行业人所占的因素还是很大的，很多时候甲方找人做设计，都是看重设计师本身，出了专业能力外，沟通，人格魅力，背景，执照等的背书也是很重要的，不过未来这种建筑界持续了很久的行业模式会不会被颠覆就不得而知了。另外，程序也需要吃许多训练数据才能提高自己的设计修养，在目前来看建筑设计的各位同行都把自己搜集的方案当成宝一样藏着，数据量的大而全也很难保证，不知道以后BIM的普及会不会让这方面得到改善。
默认的Gtk.Window是继承自Gtk.Bin的, 只能放置一个控件, 如果想要放置多个控件就需要容器container, 常用的容器有 盒子, 网格, 笔记本, 固定板 等, 下面的文章会慢慢讲解
首先, 来说盒子容器
self.box = Gtk.Box() 可以实例化一个盒子, 默认是水平盒子
垂直盒子可以 self.box = Gtk.Box(orientation=Gtk.Orientation.VERTICAL)
或者 self.box = Gtk.VBox()
Gtk.Box().pack_start(sub_widget, expand, fill, padding)
Gtk.Box().pack_end(sub_widget, expand, fill, padding)
第一个方法是从开始放置, 第二个从末尾
sub_widget 是被放置的控件
expand(bool) 是否分配额外的空间
fill (bool) 是否填充额外的空间, 当expand = False时, fill 无效
padding(int) 向外扩展的像素
例如
下篇文章讲grid 网格容器
欢迎大家留言
![Golang nethttp 爬虫[1]](/aiimages/Golang+nethttp+%E7%88%AC%E8%99%AB%5B1%5D.png)
