工具論

作品

書籍

課程

程式集

小說集

論文集

散文集

影片集

編輯雜誌

程式人

電子書

JavaScript

計算語言學

微積分

Blender 動畫

C# 語言

系統程式

高等 C 語言

Java

Android

Verilog

Wikidot

R 統計軟體

機率統計

計算機數學

組合語言

人工智慧

開放原始碼

網路資源運用

計算機結構

相關訊息

常用工具

友站連結

在家教育

RSS

最新修改

網頁列表

簡體版

English

理論 + 工具 + 善用之人 = 智慧 + 生產力
理  → 工
論  ← 具
  ↑ ↓ 
 善用之人
 

  • 定義:工具
    • 1. 可以沿伸一個人能力的任何實質或的抽象的人、事、物。
    • 2. 能增加生產力的任何事物。
  • 加工函數 (f)
    • f(投入物品, 投入工時, 工具) — (產出成品)
  • 生產力 (p)
    • p = ($產出成品 - 投入物品)/$投入工時
  • 工具的相對效用( p(A/B) )
    • p(A/B) = p(A) / p(B)
  • 新增元件的附加效用
    • {T1, T2, .., Tn} Tn+1
    • {T1, T2, .., Tn} T'n+1
  • 工具 Ti 的長期效用

.. t-1 — Tit — t — Tit+1 — t+1 .. Σt p(Tit)

  • 工具 Ti 對於整體的附加效用
    • 工具的效用需依 scope 而定, 例如 Object Oriented Language 對 coding 的效用可能是 5 倍, 但對整個 analysisdesigncoding 的效用可能就只有 1.2 倍
    • Architecture 中的 amadhal's law 在這理仍然是適用的.
  • 工具 Ti 相對於過去 {T1,..,Ti-1} 的效用
  • 工具 Ti 相對於新加入元件 Tn+1 的效用
  • 演算法的相對效用 p(A/B)
    • p(A/B) = time(fA(n))/time(fB(n))
  • 新演算法 Ai' 對於整體的附加效用
    • p(Ai') = time({A1..Ai..An})/time({A1..Ai'..An})

 

  • 修改的功用:
    • 使工具 Ti 的功用與 Ti+1..Tn 更為一致 (Ti 對 Ti+1..Tn的效用增加)。

 

  • 流程的相對效用 p(s/r)
    • (流程 x 相對於流程 y 的效用)
    • p(s/r) = time{Ts1, Ts2, …, Tsx}/time{Tr1, Tr2, …, Try}

 

  • 可預期工具 vs. 不可預期工具

 

  • bug 的代價
未知 bug 之所在處 已知bug 之所在處
可避免性 bug 探測 bug 所在處之成本 更換另一 component 所造成的效用之折損
不可避免性 bug 偵測、追蹤之成本 除錯、改正之成本

 

  • 隱藏性 bug
    • Bug 發生的次數 * Bug 發生所造成之損失
    • = Bug 發生的次數 * ( Bug 沒發生時之利潤 + Bug 發生時所花費之人工 + 中間產品之損失 + 信用之損失 )

 

  • 測試之效用 = 所避免的 bug 損失 - debug 所花的成本
  • 概念不一致的代價
    • programmer v.s. modified code : I(P | C)
    • programmer v.s programming language : I(P | L)
    • programmer v.s. programmer : I(P1 | P2)
  • 概念不一致度可以用資訊理論中的互資訊來衡量
    • I(P | C) = I(Cp | C) = the smallest program that translate Cp into C
  • Object member function v.s. Object member function
    • 若兩個物件有 A,B, function Fa, Fb, 兩者不一致(會使程式設計師混淆),則在程式設計時會產生下列成本,
      • 1. 決策的成本
      • 2. 錯誤的成本
        • 決策就可能產生錯誤,錯誤的點將需要 debug 的成本,令錯誤率為 P(error), 則 debug 的成本 = Σ P(error) * debug_cost
        • 程式設計師與既有程式之間的不一致
        • 解決方法:
          1. programmer 調整概念到 code 上。
          2. programmer 將 code 改為符合自己概念的 code.
  • 理論的相對效用 = f( 控制力的大小 )

 

  • 工具的種類:
    • 人 :(貫穿有限時空)最多樣化、最難掌控、但卻能力最強 — 權力即為掌控此工具的人所具有的屬性。
    • 錢 :(無限空間延伸)最具可交換傳遞性的工具。
    • 知識:(無限時間延伸)最具有時空穿透性與延續性。

 

  • 人的價值:
    • 經濟收入的種類可分為:
      • 1. 資本的收入(投資的利息收入)。
      • 2. 風險的收入(投資的風險使投資收入的總額大於利息的收入、保險的收入)。
      • 3. 工具的收入
      • 4. 勞力的收入
      • 5. 能力的收入
        • 在資訊時代,所有能夠完全自動化的工作,其利潤將會被壓縮到資本的利息收入, 因此、一個人的薪資將視其所能提供的服務的所能增加的產能而定,因此、懂得利用工具與人來創造出比其他人多的價值,此差即是此人與其他人的薪資差異。
        • 每個人所能提供的服務都是一組函數,所有人在單位時間內所能提供的函數所造成的價差,即是此人的價值,一個人的極大價值為其所能提供之函數價值最大的一個。

 

程式設計方法論

  • 1. 如何最少的工作,完成一個軟體。 (實務上的經濟性) (工作效率)
  • 2. 如何最少的觀念,完成一個軟體。 (理論上的經濟性) (管理效率) (奧坎剃刀)
  • 3. 如何最少的除錯數目,完成一個軟體。 (軟體的可靠性) (除錯效率)

 

Design complexity for 程序導向語言

  • 概念:用 algorithm 來操控 data structure 。

 

  • 一種 algorithm 只能操縱一種 data structure, 每種 data structure 同時需要數個 algorithm.

 

  • 一個軟體,若需要
    • n 種 data structure (d1,…,dn),
    • m 種 algorithm (a1,…,am),
    • data structure di 需要的
    • algorithm 為 a(i,1), a(i,2), …, a(i,ki)
    • sub data 為 d(i,1), d(i,2), …, d(i,li)

* Example

 
Object 1 Object 2 (1) Object 3 (1) Object 4 (2)
Algorithm 1  *   *  
Algorithm 2   *   *
Algorithm 3  * * *  
 
Design complexity = a(1,1) + a(1,3) + a(2, 2) + a(2, 3) + a(3,1) + a(3,3) + a(4,2)

Design complexity for 物件導向語言
概念:使 data structure 與 algorithm 緊密結合。
 
因此,在 OO 中, object 被 reuse 了,但 algorithm 卻無法被 reuse。
一個軟體,若需要
n 種 object (o1,…,on),
m 種 algorithm (a1,…,am),
object i 需要的
algorithm 為 a(i,1), a(i,2), …, a(i,ki)
object 為 o(i,1), o(i,2), …, o(i,li)
 
 
 
若使用 inheritance + polymorphism 可以使 algorithm 在階層架構下 reuse.
物件總數不變,但 Σ |a(i,j)| 的值會降低
 
k'i = ki - inheritance saving.
Example

 
Object 1 Object 2 (1) Object 3 (1) Object 4 (2)
Algorithm 1  *   *  
Algorithm 2   *   *
Algorithm 3  * * *  
Object 2 inherit Object 1
Object 4 inherit Object 2
Design complexity = a(1,1) + a(1, 3) + a(2,2) + a(4,2)
 
在最佳架構下, 一個 algorithm 寫了一次之後只會被其 child 使用到, 因此,

STL (通用性物件架構)
概念:用 object 與 algorithm 所建構出來的矩陣架構。
 
在最佳架構下, 一個 algorithm 完全不須要寫兩次, 因此

Example

 
Object 1 Object 2 (1) Object 3 (1) Object 4 (2)
Algorithm 1  *   *  
Algorithm 2   *   *
Algorithm 3  * * *  
Design complexity = a(1,1) + a(1, 3) + a(2,2)
 
但在實際上, 要達成 algorithm 的通用性, 利用某些基礎的包裝是 compile language 的必要條件, 因此, 還要加上 Σ |pi|.
 
另外, 有太多的特殊用途的 algorithm 只會用到一次, 因此不需要基礎包裝.
 
Programming Language v.s Database Query Language

C, Ada 可以視為 Depth Oriented 的語言,適合處理深而精的選擇性問題。
SQL 可以視為 Width Oriented 的語言,適合處理淺而廣的全面性問題。

  • 決策樹:
    • C, Ada 之類的傳統語言在處理決策問題時很容易落入歧路之中、又有岐焉的窘境,每一次的決策,都會造成某些解被排除在外,並且在深度深的時候決策樹本身就會很大,難以思考與 coding 。

 

  • 套疊評估函數:
    • f(x) = f1(f2(f3(f4…(fn(x))..))
    • 使用套疊函數的先決條件為前函數的評量必須與後函數的評量結果無關,因此、整個函數群 {f1,.., fn} 必須是可套疊的, 因此整個函數群的套疊順序是很重要的, 必`需小心的把含數的 partial order 先定出來, 然後才進行套疊.  
    • 使用套疊評估函數時, 評量程序的設計是很重要的一步,因為整體的 f 評量後不易知道何處出錯或需要改進, 因此 含數最好是可以 incremental 套上的, 也就是 for all i, {f1..fi} , fp=f1(f2..(fi(x))..) 都是可以被評量的.
  • 資料感知元件 
    • 資料感知元件的問題是 GUI 與 Database 結合的太緊, 使兩者無法分開獨立使用, 因此, portability 將會產生問題, 而且目前的狀況是兩項都是 nonstandard, 必須用自己的 interface 格隔開才不會造成 portability 的問題.

Facebook

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License