W
wfzha
Unregistered / Unconfirmed
GUEST, unregistred user!
DarwinZhang兄:
1、我说的是返回随机数。意思是,不论你提供什么“已知”的东西,我都返回随机数,
这符合你的定义--“从已知到未知的能力”吧?
2、"说服creation-zy兄确实比说服你困难,这一点我承认[]"。个人看问题的角度不同。
3、实物的抽象,与抽象概念的抽象,没有太大的区别,知识基础不同而已:下面,我
分析一个事物概念和抽象概念的例子:
实物概念:首先,我们假设有水果的概念。假设一共有三种水果:苹果、香蕉、橘子。没有别的食物
假设已经有形状的概念,红色、黄色的概念(能看到具体颜色,能看到图形),假设有味觉。假设现在程序只
认识苹果和香蕉。那么,程序判断物体到底是什么的时候(不考虑水果以外的食物),可能会先判断形状,如
果是圆的,就是苹果,如果是长条的,就是香蕉。这样,就可以区分了。由于程序本身也有"惰性"(我们自己
设定的),能通过一个条件区分的时候,就不会通过两个或更多的条件。所以,仅凭形状就可以区分两种水果
(为了简化过程,我们假定已经有了水果的概念)。这时,我们给他第三种水果--橘子,由于告诉他是水果了。
他通过形状,判断是苹果。然后,吃了一口。然后,通过味觉,他能知道这不是苹果。这样,程序就知道判断过
程出错了,然后,他就比较二者的不同。我们假设橘子和苹果的颜色总是不同的。通过大量的比较,最后程序能
发现这个特点。因为,所有的经验都告诉他,橘子和苹果的颜色总是不同。于是,他就会在适当的时候简化判断
条件,只通过形状、颜色两个概念来判断水果到底是什么。我们假设不同的程序通过文字来区分水果来进行交流
,就像人通过语言一样。那么,他就会把水果描述为“不是苹果的圆形的水果”(我在这里假设他有语言能力,
当然,实际的程序很可能没有),即使只有说单词的语言能力,对于水果,他总是要与别人交流的。他会说苹果,
香蕉,但是不会说橘子。而他又知道橘子的存在,所以,就会给橘子起一个名字。如果这个名字碰巧叫“橘子”
(为了我们与程序沟通方便,我们的程序要通过有人控制的同类程序教的)。这样,橘子的概念就形成了。
抽象的概念:假设有多种水果可以用颜色简单的区分,那么,程序在区别水果的时候,就不会再用其他的属
性。假设这时程序还没有具体的概念。但是,由我们人控制的程序已经有了。这时,由人控制的程序如果想教
会这个程序颜色的话。就会拿一些其他属性相同,但颜色不同的东西来教他。假设程序只吃水果就可以成活,假
设现在他有了水果的概念。如果我们拿出不同的水果来告诉他,红色的水果,黄色的水果....,时间长了,他就
会认识到红色,黄色是我们看水果的时候看到的颜色(使物体属性数据库中同一个字段)。但是他心里明白,却
没有颜色的概念(不知道说“颜色”就代表颜色),这时,我们可以说,水果 颜色 黄色,水果 颜色 红色。
在做这个训练的时候,需要用到临时数据库保存短期记忆的信息,通过对临时数据库的分析,程序就应该能察觉
颜色是区分水果这个食物的那个属性的名字,他就会在区分水果的那个字段(属性)与颜色这个名词对应起来。
我不知道说得明白与否,但大体过程就这样了。事物的,我从不同的角度来分析的。其实,这两个过程一样。
只是实物的我假定由人控制的程序也不知道新水果的名字。
再抽象一点的概念也一样:
我们在从另一个角度来看问题:
假设教的程序这道方向的概念,学的程序没有方向的概念,但有东西南北的概念(比如用太阳和人的左右判断)。
我们无论走到什么地方,总是指着一个方向说:方向:南/方向:北/方向:西...程序通过分析概念数据库,就会
发现,方向就是表示东、西、南、北这一类数据的属性(字段)的名字。(方法,说到东的时候,从数据库中调出
“东”这个概念的框架。说到“西”的时候,从数据库中调出"西"这个概念的框架。在这些框架之间,能找到他们
与实际事物的关联,这个关联,在不同的事物中有相同的标识符,把这个标识符的名称的属性,与方向关联就行了)
我这里面有一件事情说得不清楚,就是框架,框架的概念很重要,比如,我们一说到
桌子,就会想到有桌子腿、桌面、抽屉等。我们为每一个概念都要建立这样的框架。这
样,才有可能实现上面说的数据库结构。框架不单包括实物有,抽象的东西也有,无论
有没有名称。比如,我们可以为程序建立一个识别水果的框架,可以不起名称,程序能
自己识别就行。然后,定义从形状上来区分不同的水果。在完成上面识别橘子的例子
后,这个框架中就会加上颜色这个识别属性。每个概念,都有自己的框架。他们都会根据
环境的改变而不断的变化。
写到这里,我发现这样的数据库设计和计算起来好复杂啊,至于怎么设计数据库的结构能实现这样的表示方法,
我现在还没考虑。如果没有别的问题讨论的话,我会认真考虑一下的。我现在只是觉得能行而已。
发现一个问题:如果我的程序在完成认识水果的框架的工作的时候,如果不观察自己所
作的步骤(需要记忆下来),就没有办法发现自己的不足(用了过多的条件)。而一下来
的话,就需要感觉的支持,不能简单得把数据传给程序,让程序随便读取,再读取的时候,
要有程序的感觉系统读取自己需要的部分。否则,很多东西不能实现。感觉实在是重要啊
1、我说的是返回随机数。意思是,不论你提供什么“已知”的东西,我都返回随机数,
这符合你的定义--“从已知到未知的能力”吧?
2、"说服creation-zy兄确实比说服你困难,这一点我承认[]"。个人看问题的角度不同。
3、实物的抽象,与抽象概念的抽象,没有太大的区别,知识基础不同而已:下面,我
分析一个事物概念和抽象概念的例子:
实物概念:首先,我们假设有水果的概念。假设一共有三种水果:苹果、香蕉、橘子。没有别的食物
假设已经有形状的概念,红色、黄色的概念(能看到具体颜色,能看到图形),假设有味觉。假设现在程序只
认识苹果和香蕉。那么,程序判断物体到底是什么的时候(不考虑水果以外的食物),可能会先判断形状,如
果是圆的,就是苹果,如果是长条的,就是香蕉。这样,就可以区分了。由于程序本身也有"惰性"(我们自己
设定的),能通过一个条件区分的时候,就不会通过两个或更多的条件。所以,仅凭形状就可以区分两种水果
(为了简化过程,我们假定已经有了水果的概念)。这时,我们给他第三种水果--橘子,由于告诉他是水果了。
他通过形状,判断是苹果。然后,吃了一口。然后,通过味觉,他能知道这不是苹果。这样,程序就知道判断过
程出错了,然后,他就比较二者的不同。我们假设橘子和苹果的颜色总是不同的。通过大量的比较,最后程序能
发现这个特点。因为,所有的经验都告诉他,橘子和苹果的颜色总是不同。于是,他就会在适当的时候简化判断
条件,只通过形状、颜色两个概念来判断水果到底是什么。我们假设不同的程序通过文字来区分水果来进行交流
,就像人通过语言一样。那么,他就会把水果描述为“不是苹果的圆形的水果”(我在这里假设他有语言能力,
当然,实际的程序很可能没有),即使只有说单词的语言能力,对于水果,他总是要与别人交流的。他会说苹果,
香蕉,但是不会说橘子。而他又知道橘子的存在,所以,就会给橘子起一个名字。如果这个名字碰巧叫“橘子”
(为了我们与程序沟通方便,我们的程序要通过有人控制的同类程序教的)。这样,橘子的概念就形成了。
抽象的概念:假设有多种水果可以用颜色简单的区分,那么,程序在区别水果的时候,就不会再用其他的属
性。假设这时程序还没有具体的概念。但是,由我们人控制的程序已经有了。这时,由人控制的程序如果想教
会这个程序颜色的话。就会拿一些其他属性相同,但颜色不同的东西来教他。假设程序只吃水果就可以成活,假
设现在他有了水果的概念。如果我们拿出不同的水果来告诉他,红色的水果,黄色的水果....,时间长了,他就
会认识到红色,黄色是我们看水果的时候看到的颜色(使物体属性数据库中同一个字段)。但是他心里明白,却
没有颜色的概念(不知道说“颜色”就代表颜色),这时,我们可以说,水果 颜色 黄色,水果 颜色 红色。
在做这个训练的时候,需要用到临时数据库保存短期记忆的信息,通过对临时数据库的分析,程序就应该能察觉
颜色是区分水果这个食物的那个属性的名字,他就会在区分水果的那个字段(属性)与颜色这个名词对应起来。
我不知道说得明白与否,但大体过程就这样了。事物的,我从不同的角度来分析的。其实,这两个过程一样。
只是实物的我假定由人控制的程序也不知道新水果的名字。
再抽象一点的概念也一样:
我们在从另一个角度来看问题:
假设教的程序这道方向的概念,学的程序没有方向的概念,但有东西南北的概念(比如用太阳和人的左右判断)。
我们无论走到什么地方,总是指着一个方向说:方向:南/方向:北/方向:西...程序通过分析概念数据库,就会
发现,方向就是表示东、西、南、北这一类数据的属性(字段)的名字。(方法,说到东的时候,从数据库中调出
“东”这个概念的框架。说到“西”的时候,从数据库中调出"西"这个概念的框架。在这些框架之间,能找到他们
与实际事物的关联,这个关联,在不同的事物中有相同的标识符,把这个标识符的名称的属性,与方向关联就行了)
我这里面有一件事情说得不清楚,就是框架,框架的概念很重要,比如,我们一说到
桌子,就会想到有桌子腿、桌面、抽屉等。我们为每一个概念都要建立这样的框架。这
样,才有可能实现上面说的数据库结构。框架不单包括实物有,抽象的东西也有,无论
有没有名称。比如,我们可以为程序建立一个识别水果的框架,可以不起名称,程序能
自己识别就行。然后,定义从形状上来区分不同的水果。在完成上面识别橘子的例子
后,这个框架中就会加上颜色这个识别属性。每个概念,都有自己的框架。他们都会根据
环境的改变而不断的变化。
写到这里,我发现这样的数据库设计和计算起来好复杂啊,至于怎么设计数据库的结构能实现这样的表示方法,
我现在还没考虑。如果没有别的问题讨论的话,我会认真考虑一下的。我现在只是觉得能行而已。
发现一个问题:如果我的程序在完成认识水果的框架的工作的时候,如果不观察自己所
作的步骤(需要记忆下来),就没有办法发现自己的不足(用了过多的条件)。而一下来
的话,就需要感觉的支持,不能简单得把数据传给程序,让程序随便读取,再读取的时候,
要有程序的感觉系统读取自己需要的部分。否则,很多东西不能实现。感觉实在是重要啊