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.

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


因此,按照這些思路思考,我試圖抽象出我們在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,

顯然,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.


// 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.


這是個好主意。這就是我在做什麼的前提。我會創建另一個線程來解釋我的方法。但是,是的,一切都可以用 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,

它可以以不同的方式進行抽象。關係可以建模爲粒子糾纏、函數,類似於 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,

// 有數學專家嗎?我需要對一組完整的操作數進行分類 [..] 原子風格

我認爲你會受益於邏輯和符號推理專家、本體論和知識工程專家,而不是數學家。

[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.


好的。我確實容易被迷住。我重讀了你的想法。你建議把所有東西都分解成結構,也就是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,