Network of Functions

+2  

Document the world's entities like we document the functions of code, and build their network.

YAML 想法

How the world works can be understood by viewing at all things as functions, and building their network. For example, a shop nearby takes in electricity, people's work, monetary inputs from customers, etc., and returns products to customers, and a number of other "side effects". A shop outside, thus, is a function with I/O.

The same applies to companies. A company takes something in (e.g., natural resources), and returns something else (e.g., products, or their parts).

This is also true to schools, hospitals, etc. A hospital takes in sick people, and returns healthy people.

There are many other examples of functions, e.g., a mobile phone takes in electric power, and input, voice gestures, microwave radiation, etc., and returns things like differences in pixel luminosities, frequencies of speaker vibrations, other electromagnetic impulses and so on., even based on the input of code.

The very surface of a stone nearby you takes in photons of one type of characteristics, and returns photons of different type of characteristics.

Anything that interacts can be thought of as a function.

The idea would be to document the world, as if the world were to be build out of functions.

Hopefully, this would help us really understand how the world works, and what is possible, in terms of abstract state spaces. This is actually related closely to the previous idea of Technology Maps ™ on Halfbakery, and inspired by thinking that in fact, the idea of "Function Networks" (FNs) is much broader than the idea of "Neural Networks" (NNs), in a sense that the NNs are composed of narrower set of possible functions. For example, mostly linear functions, and with a couple of non-linear ones as activation functions, and thinking of -- what if we would simply allow all the functions, in the most general sense, and built a network of them.

In fact, this extends quite broadly, and branches very fast, because -- every website, every protein, every lab and institution is a function too, and this type of documentation of the world would best be done by a collaborative effort, perhaps starting with the cooperative open project by world's nations, open knowledge organizations, and largest search engines, taking into account the fact, that openness needs to be with wise constraints.

We had some progress with websites in fact, in a sense, that recently websites had increasingly taken on to implement their APIs to document themselves.

However, most of the world remains remains undocumented.



(别通知) (可选) 请,登录

好的。我确实容易被迷住。我重读了你的想法。你建议把所有东西都分解成结构,也就是funcs的排列,每个func都有文档记录,通过查看结构就可以看出事物是如何构建的。函数很容易记录。这些函数如何组合成结构是另一个主题,你不这么认为吗?只是初步的想法。但我确实喜欢尝试将知识组织成一个合理的结构的想法,有层次,人们可以在其中遍历功能范围到零细节。 这似乎是一个好主意,但它与现有实践有何不同。很高兴有一个样品。我认为您在谈论将知识分解为原子片段,每个片段都有其描述。是吗?

Ok. I do tend to get fixated. I reread your idea. You suggest that everything is broken down into structure, which is arrangements of funcs, and each func is documented, and it can be seen how the things are build by examining the structure. Funcs are easy to document. How these funcs fit together into structure is another subject, dont you think so? Just initial thoughts. But i do like the idea of trying to organize knowledge into a sensible structure, with layers, where one can traverse functional scopes to zero in on specifics. It seems like a good idea, but how would it be different from existing practice. Be nice to have a sample. I think you talking about breaking up knowledge in atomic peices, each with its description. Is that right?



    : Mindey
    :  -- 
    :  -- 
    

skihappy,

// 有数学专家吗?我需要对一组完整的操作数进行分类 [..] 原子风格

我认为你会受益于逻辑和符号推理专家、本体论和知识工程专家,而不是数学家。

[skihappy],我有一种感觉,你所关注的东西,穿过了你正在构建的系统的“棱镜”,但你没有明确提到它,所以读者不会明白你在说什么,正是...所以,您能否至少在句子中明确提及主语,例如,说这几句话,例如:

“为了构建一个具有(一些表示和能力)的知识图谱,我们需要 A,它得到它,我们需要 B 和 C。”,

不要偷懒,语境化使思考。

// Any math experts? I need to classify a complete set of operands [..] atomic style

I think you'd benefit from experts in logic and symbolic reasoning, experts in ontologies and knowledge engineering, not so much from mathematicians.

[skihappy], I get a feeling that what comes to your attention, gets through the "prism" of your system that you're building, but you're not explicitly mentioning it, so readers won't understand what you're talking, exactly... so, could you at least mention subjects in your sentences explicitly, for example, saying those few sentences, like:

"In order to construct a knowledge graph that has (some representations and capabilities), we'll need A, and it get it, we'd need B, and C.",

Don't be lazy, contextualization makes thought.


它可以以不同的方式进行抽象。关系可以建模为粒子纠缠、函数,类似于 qm。限制状态的反应性函数。但是,约束 func 可以表示为一个对象,其中 props 为两个粒子引用和一个符号操作数。那是图中链接的描述符。现在我们得到了图形,我们可以在低代码开发系统中以图形方式构建和操作它

当然,粒子系统之间可能存在关系,例如多对多和一对多等等。他们都是纠缠不清的。有数学高手吗?我需要对一组完整的操作数进行分类,以表示编写约束函数的所有方式,原子风格。

It can be abstracted in different ways. Relationships can be modelled as particle entanglements, funcs, analagous to qm. Reactive funcs constraining the state. But then, a constraining func can be represented as an object, with props as two particle refs, and a symbolic operand. Thats a descriptor of a link in graph. Now we got graph, and we can build and manipulate it graphically, in a low code development system

Of course, there can be relationships between systems of particles, like many to many and one to many and all that. They are all entanglements. Any math experts? I need to classify a complete set of operands, to represent all ways to write constraining funcs, atomic style.



    :  -- 
    : Mindey
    :  -- 
    

skihappy,

这是个好主意。这就是我在做什么的前提。我会创建另一个线程来解释我的方法。但是,是的,一切都可以用 funcs 建模。函数和微分方程是等价的。量子力学可以通过函数来​​表述。我们的编程语言和 qm 非常相似,imo。

Thats an excellent idea. Thats the premis of what im doing. Ill create another thread explaining my approach. But yes, everything can be modelled with funcs. Funcs and differential equations are equivalent. Quantum mechanics can be formulated thru funcs. Our programming languages and qm are very similar, imo.



    :  -- 
    : Mindey
    :  -- 
    

skihappy,

// OPERAND和VALUE,即第5和第6位合并为一个//

这样做意味着不区分“变量”(价值的地方)和“价值”(事物本身)。因此,也许分开是有意义的。

// OPERAND and VALUE, i.e., the 5th and 6th merge into one //

Doing that would mean not distinguishing between a "variable" (a place for value) and the "value" (thing itself). So, perhaps it makes sense to stay separate.


显然,OPERAND和VALUE(即第五和第六)合并为一个,因为它们非常相似,并且那些认为关系不是对象的人是错误的。

Apparently, OPERAND and VALUE, i.e., the 5th and 6th merge into one, as they are very similar, and those who think that a relation is not an object, are mistaken.


因此,按照这些思路思考,我试图抽象出我们在0oo收集到的东西。 基本上

  1. Category 功能类 ,例如目标,类别,问题
  2. Method 功能原型 ,例如,思想,发明,转化 3.“系统”: 功能实例 ,例如计划,项目,代理,组织,团队,人员,设备,工具,资源,工具
  3. Task _Function调用,例如Task,Request,Order。
  4. Place 功能参数 ,例如位置,地址,帐户。
  5. Result 功能响应 ,例如,系统日志,事件,报告,已执行的任务,操作,工作结果,演示,转移,事务,日志,博客文章,新闻稿,产品,服务部署。

看来,这与CS中已建立的概念非常吻合:

1.类型
2.运算符(即功能)
3.流程
4.操作
5.运营商(即参数)
6.价值观

So, thinking along these lines, I tried to abstract the things that we collect here at 0oo. Basically:

  1. Category: Function class, e.g., Goal, Category, Question
  2. Method: Function prototype, e.g., Idea, Invention, Transformation
  3. System: Function instance, e.g., Plan, Project, Agent, Organization, Team, Person, Equipment, Tool, Resource, Instrument
  4. Task: Function call, e.g., Task, Request, Order.
  5. Place: Function parameter, e.g., Location, Address, Account.
  6. Result: Function response, e.g., System Log, Event, Report, Executed task, Operation, Work result, Demo, Transfer, Transaction, Log, Blog post, Press release, Product, Service deployed.

It seems, that this corresponds well to the established concepts in CS:

1. TYPES
2. OPERATORS (i.e., functions)
3. PROCESSES
4. OPERATIONS
5. OPERANDS (i.e., parameters)
6. VALUES


    : Mindey
    :  -- 
    :  -- 
    

Mindey,

我喜欢这个主意。可以与业务云结合。我的想法之一:

https://github.com/samsquire/ideas2

I like this idea. Could be combined with business cloud. One of my ideas:

https://github.com/samsquire/ideas2#98-business-cloud


语言