時光筆記

近期關於生成式AI的一些想法

Mon, 03 Feb 2025 12:23:52 +0800

An image captured on Yugung Island at sunset.

前言

回歸之作就獻給生成式 AI 吧。剛好也是最近使用的最多也嘗試得最多的領域。

實際上甫從 chatGPT 問世，我幾乎是馬上就去使用了，當然一開始只是圖個新鮮，畢竟可以流利對話的聊天機器人到之前幾乎都是不出現的。當然，那個時候真的就只是一個新鮮感的玩具，儘管對於他的對話能力感到新奇，但當時幾乎並沒有任何生產力的想法。

直到 OpenAI 開始發布更新，從 3.5, 3.5-turbo, 4, 4o，GPT 也從只可以文字輸入的娛樂，到現在多模態，支援圖片，語音，甚至是即時影片做為輸入的多樣化工具。

而這些進步僅僅發生在 ChatGPT 推出的兩年以內，他就從娛樂進化成了可以提供各類協助的工具，於是，也讓我開始思考，究竟接下來人類與 AI 工具會有什麼樣的發展（又或是 Ilya Sutskever 認為的，可能是一種全新的智能體物種），而我又該如何去面對這些幾乎是突破性的發展。

當然 AI 影響的可不僅僅是日常生活而已。

2024 諾貝爾獎應該是非常特別的一年，這年的諾獎開創性的頒給了不少 AI 相關的研究，例如諾貝爾物理學獎的得主 John J. Hopfield 和 Geoffrey E. Hinton，表彰他們在人工神經網路的基礎研究。諾貝爾化學獎也頒給了利用 AI 研究蛋白質結構與設計的學著。

這些獎項頒給了與 AI 相關的科研內容，可以說是一大震撼彈，代表在學術界的頂級榮譽，也認可了目前的 AI 科技。儘管諾獎看似離我這種普通人應該都是太遠了，但當一個人類文化智慧結晶的殿堂都開始接受這項科技的成果時，這個衝擊應該不會過很久就會席捲整個社會。

甚至其實 AI 們早就在內捲人類的生活了。根據 Who Is AI Replacing? The Impact of Generative AI on Online Freelancing Platforms 調查了 Freelancer 市場在 ChatGPT 出現前後以及 AI 繪圖相關工具出現前後的工作需求佔比，而這是他們的其中一段結果摘錄：

摘要

• Within eight months of ChatGPT’s release, job postings for automation-prone roles (e.g., writing, coding, and automation) decreased by 20.86% more than manual-intensive jobs.

• Writing jobs saw the largest decline (30.37%), followed by software development (20.62%) and engineering (10.42%).

• The introduction of AI-powered image-generation tools (Midjourney, Stable Diffusion, DALL-E 2) led to a 17.01% decline in job postings for graphic design (18.49%) and 3D modeling (15.57%).

也就是說，就算只是截止到目前(2024)的 AI 工具，對於人類的影響已經可以說是非常大的了。那我就在想，在這個可能是時代變革的時間點上，究竟我該拿什麼態度去對待這些工具，才能夠再好好利用工具的情況下又不會失去我原先該有的能力。

那些 AI 工具對我的影響

欸？失去什麼原先該有的能力？難道人會被 AI 取代？我會沒有工作？其實我並不是在擔心這個。不過如果這件事情真的發生了其實我也沒有太多的驚訝，畢竟現在任何的科技（或是說 AI）發展真的都是不斷超乎想像的。誰能想像 2022 才出現的 ChatGPT，發展了僅僅兩年就已經可以勝任原本只有真人才能做得到的工作，甚至有些還做得更好。

實際上我一邊使用這些工具並享受著這些東西帶給我的便利性時，我一邊也開始有點惶恐，當我對這些好用的工具產生依賴性時，是否會失去什麼原先我該具備的能力。

舉個例子，之前有段時間我在與朋友討論相機的成像原理時，對於 CoC (Circle of confusion) 這個名詞感到陌生，於是我很順手的就直接丟給了 ChatGPT 請他解釋，但當時為了方便直接是使用中文問的（一般在使用時我還是覺得英文的問答品質會比中文高很多），於是 ChatGPT 給我了一個似是而非的解答，而當時我也沒有太在意，就把他的回答當作我的理解給記了下來。

結果大概是中文語意的問題，實際上 ChatGPT 上的解釋是具有誤導性的，而這個誤導讓我後續對於整個模糊圈（CoC）的判斷又出現了問題，後面跟朋友的討論就出現了雞同鴨講的情況。

後來我回想一下整件事情的發生，我才突然驚覺自己好像因為太過於依賴 ChatGPT 的回答導致我喪失了當初多方求證的能力。儘管每個在教你使用任何大語言模型工具的課程，大多都會提到所有的 AI 工具都會有一定程度的錯誤，使用者都必需自己花時間去審慎評估。

但是當看似高品質的資訊越來越易於取得時，求證的過程就會漸漸的被省略，至少我是如此。

當然影響也不僅僅只有這樣，還有包括自己在寫程式的習慣漸漸的在改變，也越來越倚靠 AI 快速先幫我打底，我再去慢慢精修的結果。又或是碰到問題，直接習慣性地先丟給 ChatGPT 的語言模型幫我做一次 Survey，這樣得到答案的效率更高。

這樣不好嗎？很好，老實說。無論是我工作上或是生活中，效率都有提高。只是似乎，倚靠著自己“思考“的過程在慢慢地減少。

卡茲停止了思考

關於 AI 工具應用的一些小結

其實這篇真的就比較偏向一些 MurMur，怕越寫焦點會越模糊掉。（其實是太久沒寫文章開始詞窮了Ｘ）之後或許會根據某些主題再多 MurMur 一點？

儘管 AI 工具帶來了非常多的方便，但當我們有許多能力漸漸的因為這些方便而疏於使用後，究竟會帶來哪些副作用目前仍是沒有肯定的。至少對我自己來說我已經受到些許的負面的副作用影響了。

曾經在聽了某個跟 AI 工具相關的演講，當時的講師表示:

引用

在接下來的的 AI 時代，你必須找到自己真正熱忱的事情，才能夠讓自己更能夠面對這些衝擊。

更進一步地說，AI 工具已經能夠滿足不少工作及格分左右的需求，剩下的就是需要靠自己的熱忱去完成更多的分數。但也可以說，當你對某些事情有熱忱時，能夠擋住實現這些熱忱的門檻已經越來越少了。例如一個毫無程式能力基礎的，甚至連 Python 要去哪裡執行都不知道的財務統計專業人員，可以通過不斷地詢問 ChatGPT 在僅僅一天之內來完成一個功能非常完整，能夠自己搜尋到各類財務資料並且自己出報告的程式。沒有繪畫能力的我，也能非常簡單地透過幾句指令，就能在我的投影片裡面加入有意義且精美的插圖。

達成目標的門檻越來越低，但“及格”的標準也會越來越高了。我認為在接下來的時代，把握自己熱忱相關的技能，透過 AI 帶來的方便性工具來弭平可能的困難，並且用來持續精境支持自己熱忱的那些能力，不要讓輕易的讓自己的這些能力退化成能夠被輕易取代。

這大概是，我認為接下來艱難的時代我需要學習的內容。

週末的一點前端小旅程

Mon, 14 Aug 2023 21:20:55 +0800

從零開始的一點前端小旅程

前言

週五下班前和同事聊到公司的某個系統功能開發的想法，聊著聊著就突然來了興趣，想著坐而言不如起而行，直接上手試試看最不熟練的前端。

由於公司是用 Vue 當作開發框架，然後我想試試看 TypeScript 進行開發，因此整個開發便是在 Vue.js + Three.js + TypeScript 底下完成。

開發功能描述

先簡略描述一下系統狀態，有個 3D 模型，上面會有數個測量點顯示在模型上，如下圖所示：

Demo1

然後每個點上都會有個針對這個模型的一些數值，主要就是想開發一個功能，如果點擊/搜尋到畫面上的任意測量點，會把視角移動到最適合使用者看到點的位置，如下圖所示：

Demo2

那對我來說會有幾個難點：

因為前端網頁以及框架的不熟悉，所以幾乎需要從零開始學習這次所需要的 Vue 框架，前端 3D 套件 Three.js，以及 TypeScript 。
由於模型多少還是有一定的複雜度，因此在移動相機視角的時候必須根據測量點在模型上的哪個位置進行視角改變，如果測量點在模型傾斜 45 度角的位置，就必須讓視角也跟著傾斜 45 度角，才能達到最好的視角角度。
因為希望能夠讓這份程式有重用性，以及希望嘗試一點設計方法，因此會需要在一開始就規劃一下程式架構。

程式架構講解

架構簡述

主要架構大致如下：

classDiagram
 class BaseModel{
 model_type : model_base
 allBaseObject : Array
 search_points(x : number, y : number, z : number, d : number) Vector3
 }
 class model_base{
 << interface >>
 construct_Mesh() Array
 calculate_and_compare_point(point_height : number) number
 getCameraPosition(x : number, y : number, z : number, distance : number) Vector3
 }
 class cylinder_model{
 CylinderArray : Array
 params : Array
 layer_Height : Array
 layer_TRadius : Array
 layer_BRadius : Array
 calculate_y_offset() number
 record_layer_info(height : number, tradius : number, bradius : number)
 construct_Mesh() Array
 calculate_and_compare_point(point_height : number) number
 getCameraPosition(x : number, y : number, z : number, distance : number) Vector3
 }
 class other_model{
 construct_Mesh() Array
 calculate_and_compare_point(point_height : number) number
 getCameraPosition(x : number, y : number, z : number, distance : number) Vector3
 }
 BaseModel --> model_base : Contains
 model_base <|.. cylinder_model : implements
 model_base <|.. other_model : implements

我希望利用 interface 來隔開實際上不同模型的實現方式，如可以利用圓柱層層疊加產生的模型、球體模型、透過外部引入的模型等… 最後再透過最外層的 BaseModel 操作整個模型，讓上層應用的開發者在操作時不必知道實際上操作的是哪個模型，這樣之後再增加模型時也會比較好增加，只需要增加新的 Class 並實現 Interface 中的方法。（如 other_model）

提示

實際上這應該是 Abstract factory pattern
也是因為 TypeScript 有 interface 所以我才決定用 TypeScript 而不是 Javascript

大概的程式碼檔案結構如下

src/components/
- HelloWorld.vue —> 主要視圖和 Vue 掛載
- ts/
  - TBaseModel.ts —> 這次主要程式碼，司職模型的建構以及計算
  - TData.ts —> 毫無反應，就是一個紀錄 Data 的檔案
  - TEngine.ts —> 網路上文章參考的 Three.js 渲染程式
  - THelper.ts —> 網路上文章參考的 Three.js 輔助程式
  - TLights.ts —> 網路上文章參考的 Three.js 光線程式
  - TPoints.ts —> 用來生成測量點模型

模型分類

考量到會有不同的模型，因此我先設想了幾個可能性：

圓柱模型：此分類主要特色為透過軸心一樣的圓柱體（包含上下圓半徑不同的圓柱體）來組成模型，用圓柱座標系能夠輕易描述
球體模型：利用球座標建立的模型系列
複雜模型：透過直接外部引入模型檔的方式進行建立的模型系列

目前手上的模型資料大部分都是由第一個模型組成，因此這次會主要建立圓柱模型。

利用 Three.js 圓柱體模型( CylinderGeometry 類 )的彈性（上下半徑可以不同），在建立圓柱體模型時可以利用不同層疊加的方式建立出多樣化的模型，如上圖的錐形實際上就是利用兩個圓柱體實現而成。

但在建立模型類時希望能夠操作同樣一個實體，透過參數自動進行調整就能讓整體的模型順利建立。

例如順序傳入第一層上半徑、下半徑、高，第二層上半徑、下半徑、高，然後就能自動建立出模型。

因此 cylinder_model class 的建構子如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


constructor(params: Array<number>) {
 this.params = params
 let index: number = 0;

 if (params.length > 0) {
 while (index < params.length) {

 let CylinderHeight = params[index++]
 let CylinderTopRadius = params[index++]
 let CylinderButtomRadius = params[index++]

 let y_offset = this.calculate_y_offset(CylinderHeight) // 求出每一層的起始高度

 /* 建立 各層 CylinderGeometry 實體 */
 this.CylinderArray.push(
 new CylinderGeometry(CylinderTopRadius, CylinderButtomRadius, CylinderHeight, 32)
 .translate(0, y_offset, 0))
 /* 每層高度計算方式 */
 /*
 * 若共 N 層，每層高度為 H_k，k = [1,N]
 * 則第 K 層的高度偏移為 SUM(H_k) 當 k=[1,K-1]，再加上 0.5 * H_K 
 */ 

 this.record_layer_info(CylinderHeight, CylinderTopRadius, CylinderButtomRadius) // 紀錄每一層的數據
 }
 }
} 

可以看到建構子傳入為一個 number array，裡面依序存放著從最底層至最高層的高，上半徑，下半徑。

而由於會需要計算出每一層的起始高度，calculate_y_offset()則是用來實現計算每層累積高度的方法。

1
2
3
4
5
6
7
8


/* 簡單計算每層起始高度 */
calculate_y_offset(current_height: number): number {
 let height: number = 0;
 for (let i = 0; i < this.CylinderArray.length; i++) {
 height += this.params[i * 3]
 }
 return height + 0.5 * current_height
 }

計算每層起始高度的公式如下：

若 $H_i$ 代表每層的高度，$i\in(1,N)$，而目前要計算第 $K$ 層的高度，$1 \leqq K \leqq N$，則第$K$層起始高度為： $$\sum_{1}^{K-1} H_i+\frac{1}{2}H_K$$

最後為了之後計算相機移動座標方便，先記錄下每層的三個參數資訊。

1
2
3
4
5
6


/* 記錄每層資料 */
record_layer_info(height: number, tradius: number, bradius: number) {
 this.layer_Height.push(height)
 this.layer_TRadius.push(tradius)
 this.layer_BRadius.push(bradius)
}

計算相機座標

上面終於建立好模型了（實際上省略不少部分，但簡單來說就是建立了:rofl:）

那接下來終於能開發主要的功能了，讓相機（視角）移動到所選點位的正前方。

首先要確定一下“正前方“的定義，如果選的點位是在與 XZ 平面垂直的地方，那相機直接移動到距離點位同高度並且平視即可。

Camera_p1

但是如果所選點位是和平面有夾角的，那是觀測最佳視角就應該有相應的傾斜角度，使相機位置就會需要進行偏移計算。

Camera_p2

那觀測的角度我認為是以視線垂直於平面為最佳觀測角度，因此底下會以這個角度設計。

首先要解決的是，必須先計算出選擇的點在哪層圓柱體上，才能夠根據圓柱體的參數進行視角的計算，好在圓柱體模型要確認層數只需要利用 Y 軸進行判斷即可。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


/* 計算傳入的點在哪一層 */
calculate_and_compare_point(pointX: number, PointY: number, PointZ: number) {
 let result: number = 0

 /* 線性比較高度 */
 while (PointY > 0) {
 PointY = PointY - this.layer_Height[result]
 result++;
 }

 return result - 1
}

計算出點位在哪層之後就能開始計算相機位置，那先給個計算示意圖：

camera_p_calculate

$TR$ 是上半徑，$BR$ 是下半徑，$H$ 是層的高度，$D$ 是相機距離量測點的距離。

其中 $\theta$ 是相機與水平的夾角，而我們其實主要要求的是 $h’$ 和 $r’$，也就是相機對於觀測點的Ｙ軸偏移量以及 R 軸偏移量（於圓柱座標系)。

求出 $h’$ 的公式如下： $$h’=D*\sin{\theta}$$ 而求出 $r’$ 的公式如下： $$r’=D*\cos{\theta}$$ 而 $\theta$ 則可以透過下式算出： $$\theta=\arctan{(\frac{TR-BR}{H})}$$ 則最後合併式子： $$h’=D*\sin{[\arctan{(\frac{TR-BR}{H})}]}$$ $$r’=D*\cos{[\arctan{(\frac{TR-BR}{H})}]}$$ 得到 Y 軸偏移量後，還需要進行座標轉換，先將觀測點的圓柱座標 $Point = (r,\theta,y)$ 求出，再根據 y 軸的偏移量進行修正 $Camera = (r+r’,\theta,y-h’)$，就能得到最後的相機位置。

程式實現如下

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


/* 計算出傳入的點會需要將照相機移動到何處 */
getCameraPosition(pointX: number, pointY: number, pointZ: number, distance: number) {

 /* 先確定點在哪層 */
 let layer_index = this.calculate_and_compare_point(pointX, pointY, pointZ)

 /* 計算偏移角度 theta */
 let theta = Math.atan((this.layer_TRadius[layer_index] - this.layer_BRadius[layer_index])
 / this.layer_Height[layer_index])

 /* 計算照相機的 y 軸偏移(於圓柱座標系) */
 let camera_y_offset = distance * Math.sin(theta)
 
 /* 計算照相機的 r 軸偏移(於圓柱座標系) */
 let camera_r_offset = distance * Math.cos(theta)

 /* 將座標轉換回笛卡兒座標 */
 let c = new Cylindrical().setFromCartesianCoords(pointX, pointY, pointZ)
 let c_new = new Cylindrical(c.radius + camera_r_offset, c.theta, c.y - camera_y_offset)
 let v = new Vector3().setFromCylindrical(c_new)
 return v
}

提示

當 $TR = BR$ 的時候，由於 $\arctan{0} = 0$，而 $sin{0}=0$ 且 $cos{0}=1$，則回歸到 Y 軸偏移量為零，R 為 1 的簡單狀態。

而 $TR < BR$ 時，由於 $\arctan{-\theta}=-\arctan{\theta}$，而 $\sin{-\theta}=-\sin{\theta}$ 且 $\cos{-\theta}=\cos{\theta}$，因此完全符合實際狀況。

Interface

最後講到利用 interface 實現的好處，我建立一個 BaseModel 用來控制所有實現介面的類別。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


export class BaseModel {

 model_type: model_base;
 allBaseObject: Array<Mesh>;

 constructor(model_type: model_base) {
 this.model_type = model_type
 this.allBaseObject = this.model_type.construct_Mesh()
 }

 /* Demo用方法，傳入需要聚焦的點位和希望相機離目標的距離，回傳相機該移動到的地方 */
 search_points(x: number, y: number, z: number, d: number): Vector3 {
 return this.model_type.getCameraPosition(x, y, z, d)
 }

當我想建立一個圓柱形模型類別時，我只需要如下建立資料並傳入相應的參數：

1
2
3
4
5
6
7


let test_base_model = new BaseModel(new cylinder_model(
 [data.ConeHeight,
 data.ConeTopRadius,
 data.ConeButtomRadius,
 data.Height,
 data.TopRadius,
 data.ButtomRadius]))

這樣我之後在操作模型時，只需要操作最外層的模型類別，並不用在意到底現在是哪個種類的模型實現，如下：

1

let v = basemodel.search_points(point.x, point.y, point.z, 10)

結語

最後是功能展示影片：

Your browser does not support the video tag.

老實說這次的 Vue 輕旅程還滿有趣的，難得的在一定的時間沈浸在完全的程式裡面進行開發（可憐的嵌入式工程師總需要編寫程式邊確定硬體有沒有出錯:cry:）

再加上能夠多少測試一下一些開發的方式，其實收穫還滿大的:laughing:

原始程式碼會放在 github 上。

讀後感 - The Clean Coder（ㄧ）

Fri, 28 Jul 2023 13:35:24 +0800

The Clean Coder 第一章讀後感

前言

最近又重新把 The Clean Coder 重新拿出來讀了一遍，根據這一年工作的一些經歷，又有更多的思考和體悟（？打算來記錄一下。

因為 The Clean Coder 太多章節，我認為許多章節都很值得單獨拿出來寫，所以可能這也會是一整個系列的讀書心得。

先簡短簡介一下 The Clean Coder 這本書，中譯 “無瑕的程式碼番外篇-專業程式設計師的生存之道”，作者為 Robert C. Martin，是很著名的軟體工程師，以提倡許多軟體設計原則和開發方式聞名。這本書其實也是 “The Clean Code” 的番外篇，主要是在敘述如何成為一名“專業的”程式設計師。

這本書我認為其實也不僅僅只適合工程師閱讀，其中有不少對於工作上專業態度的解釋與例子，也很適用於其他情況。

Be careful what you ask for

第一個章節，主要就是要探討到底何謂 Professionalism 以及一個追逐專業態度的人該有的表現。

但是最重要的是 “What you ask for”，追求專業一定不是一件簡單且輕鬆的事情，會需要承擔的責任一定會比不用追求專業來的沈重，但我認為不追求專業並不能讓自己逃避掉什麼，因為該負的責任本身就會隨著自己的年齡增長開始受到外界的期待，如果持續抱持著"不專業"的態度，僅僅只會讓自己與社會期待脫節，而到那個時候所需要付出的心理壓力並不會更小。

就如同社會期待一名父親需要做好養育孩子，教育孩子，以及與伴侶扶持家庭的責任，或許可能因為很多原因在身為父親的角色不夠“專業”，但是社會的期待如此，外界看到的結論也只會是你有沒有做好這件事情。你可以選擇在其他的部分上“專業”下心力，但所有的都是取決於 “What you ask for”，而你選擇的道路，就會承擔相應的責任。

稍微離題了，但總之，選擇了一項專業，隨之而來的就是相應的責任。

引用

“You can’t take pride and honor in something that you can’t be held accountable.”

“Professionalism is all about taking reponsibility.”

– «The Clean Coder»

拿我自身為例，我在公司裡因為本身有一點相關背景和知識，所以時常擔任著公司在做相關決策時的諮詢討論者。從一項 Project 的功能增加，時程預估；又或是一個產品的品質控管，或是一項技術的引入與否，很常都會徵求我的意見。

對，這是我的專業，我願意這樣想，但隨之而來的是責任的沈重感。當我認為這是我的專業並給出我的建議時，我就該付出相應的責任，因為每句話都可能影響到整個公司接下來的發展，以及大家以後吃不吃得飽飯。

我很聰明嗎？並沒有；我很有經驗嗎？更不可能有。那當我決定給出我的建議，我的“專業”看法前，我就需要花很大量的時間去思考，去搜集各種資訊，去詢問各種比我更有經驗的專家，去佐證我給出的建議是有跡可循的，是可以付諸實行的。

然後更重要的是，我要有心理準備是，我如果犯錯了，我就該承擔責任。

所謂專業人士，就是能對自己錯誤負責的人

摘要

It is the lot of a professional to be accountable for errors even though errors are virtually certain. So, my aspiring professional, the first thing you must practice is apologizing. Apologies are necessary, but insufficient. You cannot simply keep making the same errors over and over. As you mature in your profession, your error rate should rapidly decrease towards the asymptote of zero. It won’t ever get to zero, but it is your reponsibility to get as close as possible to it.

如同上述書中所言，人不可能完全不犯錯，沒有人永遠保證自己犯錯的機率為零，但是專業就體現在由於經驗的累積和持續不斷的修正，犯錯機率會持續下降直到趨近於零。

Zero would be nice

然後當犯錯的時候，大方承認自己的錯誤並且找到該修正的點。如果是自己疏失的錯誤，要狠狠地記上一筆（心裡面），然後提醒自己下次需要注意。但如果不是自己疏失，可能是因為外界因素的錯誤，其實也是需要修正的。

我認為永遠不該把任何的錯誤結果僅僅歸咎於外界因素，例如電腦當機，天氣太熱。這些可以是 “原因”，但不能是 “結果”。永遠無法完全控制外界的干擾因素，只能去適應外界的干擾。

舉個例子，曾經有次公司產品出外 Demo 時意外發生了電腦無故無法開機，最後查證是電池沒電的問題，但是我們在前一天都確認過電量和所有狀態都是 OK 的了，怎麼會有這種問題？

後來才發現可能是有其他同事改過電腦設定導致關機程序改變，因而並沒有完全進入關機，只是休眠狀態，我們也沒有注意到，就造成了錯誤的結果。

這是我們犯下的錯誤嗎？不完全是。但是這是我們應該負起的責任，因此我們馬上重新審視了外出工作的前置作業檢查，把有可能的出錯情況降到最低。

那要應對不同的錯誤進行改正，需要的就是不斷的學習。

了解自己的領域並堅持學習

學習很重要，尤其對追求專業來說，更為重要。除了理解新知識，也需要去回顧歷史。

引用

Remember Santayana’s curse: “Those who cannot remember the past are condemned to repeat it.” – «The Clean Code»

過去的知識並不是一文不值，更多的是能夠讓我們理解到知識發展的脈絡，讓以後的路更加清晰。

當然更重要的是需要在自己的領域深耕並堅持學習，其中包含兩個方面：

理解自己的領域

專業就是在自己的領域有著一定程度深耕，就如書中建議軟體工程師需要理解的內容：

摘要

Here is a minimal list of the things that every software professional should be conversant with:

Design patterns. You ought to be able to decribe all 24 patterns in the GOF book and have a working knoledge of many of the patterns in the POSA books.
Design principles. You should know the SOLID principles and have a good undersatanding of the component principle.
Methods. You should understand XP, Scrum, Lean, Kanban, Waterfall, Structured Analysis, and Structured Designed.
Disclilines. You should pratice TDD, Object-Oriented design, Structured Programming, Continous Integration, and Pair Programming.
Artifacts. You should know how to use: UML, DFDs, Structure Charts, PetriNets, State Transition Diagrams and Tables, flow charts, and decision tables.

真的慚愧，我上述有很多都很不了解，看來需要認真惡補惡補。

另外，除了 “自己的領域”，書中也有提到需要了解 “業務領域”，開發什麼，就必須了解相對應的業務領域。

我今天想開發一個工業應用上的自動化設備，除了理解本身軟體開發的領域，也需要去理解到底工業自動化都是怎麼設計的，需要怎麼樣的連接接口，應用設備。我不需要成為那個領域的專業人士，但我一定需要具備能與相關領域專業人士溝通的能力。

引用

“It is worst kind of unprofessional behavior to simply code from a spec without understanding why that spec makes sense to the business. Rather, you should know enough about the domain to be able to recognize and challenge specification errors.” – «The Clean Coder»

好像可以參考領域驅動開發 (Domain-Driven Design,DDD) 的相關知識。因為很多時候問題並不是寫寫程式就能夠簡單解決的，會需要更多的專業知識支持，僅僅只是固守自己的專業是沒有用的，還需要具備與其他專業溝通的能力。

堅持學習

引用

“Would you visit a doctor who did not keep current with medical journals? Would you hire a tax lawyer who did not keep current wth the tax laws and precedents? Why should employers hire developers who don’t keep current?” – «The Clean Coder»

堅持學習除了學習新知識以外，還需要堅持反覆練習。本書作者有提到他會使用一種 “kata” 來持續反覆練習已有的技巧，保持技巧成熟。並非使用難以解決的問題，而是使用已知解決但疏於練習的問題，來增加熟練度。

摘要

The point of doing the kata is not of figure out how to solve the problem you know how to do that already. The point of the kata is to train your finger and your brain

這也是我目前需要增進的地方，很多東西我儘管都知道要怎麼做，但是真正上手的時候也都會需要卡一陣子才能夠真的寫出來。

修改與測試

好的程式碼應該保持靈活可維護的軟體結構，而如果想要讓程式碼靈活，則必須時常去修改它。

引用

“If you want your software to be flexible, you have to flex it!” – «The Clean Code»

而能保證修改後不會破壞整個程式的運行結構，就需要建立良好的測試環境以及流程。書中建議，不，是要求要做到覆蓋 100% 的單元測試，去測試每行程式碼，這樣才能保證每次修改後不會產生預期外的錯誤。

而要有辦法做到覆蓋率如此高的測試，就需要在設計階段就要有良好的模組化思考和測試驅動開發思維（Test-Driven Developement, TDD）

謙遜

書中提到，程式設計是一門及其自負的行為，畢竟程式設計師們是本質上是一名創作者，透過自己的程式去構成相應的結果。

我認為的確如此，我們需要對自己寫出的每行程式極度自信，因為花了時間去理解了到底寫了什麼東西，並且經過的大量測試，那是應該要對自己的程式抱持著十分的自信。而這種自信的確也是一種自負的狀態。

但這種自負是建立在，因為需要謙遜地去對待過去的所有錯誤，以及小心的去看待每一行自己寫出來的程式，所以才會有這種心態。而每當發生錯誤時，更要毫不保留的去承認自己的錯誤，然後去找出問題。

專業人士是謙遜且自信的，對待所有未知謙遜且小心，而在已知的地方則自信並大膽。

“我保證這部分可行”

這是我很常對我的組員說的:rofl:，儘管我離真正的專業人士還差得遠呢！

RT_Thread 學習紀錄（一）

Fri, 21 Jul 2023 20:44:24 +0800

初探 RT-Thread

緣起

從大學上過作業系統（OS）課程以後，對於整個系統運作就一直抱有一種很不明的情愫（？

透過一段程式調度整個硬體設備，包括邏輯運算中樞，各種通訊界面，還有控制外部週邊單元，還要應付~~毛病一堆~~的使用者，如果把作業系統放在現實生活根本就是神一般的人物吧？

總之，在學到作業系統以後對於運用和編寫作業系統這件事一直都抱有憧憬。

Kira

後來大學開始使用 Linux 系統，並因緣際會的學到了一些 Kernel 知識和 Kernel module 開發，對作業系統更加著迷了，但受限於 Linux 這種大型且複雜的作業系統，我也只能在旁邊摸摸皮毛過過乾癮，但總覺得參與感不夠。

後來大學專題因為主題是 BLE Mesh，為了能夠良好的移植 Bluetooth 的協議層，接觸到了 Linux Foundation 底下的 Zephyr Project，開始接觸並使用 RTOS，不過這時還是以應用為主。但是心底一直有個想法，應該真正的去摸清楚整個 RTOS 的實做，並且透過自己重新實現來加深理解整個作業系統的概念。但是可以說自己懶，或是一直找不到很合適的專題或機會去真正實現這個想法。

到現在剛好在工作上碰到系統需要規劃使用 RTOS，決定正式開啟這個學習計劃。

至於選擇 RT-Thread 也沒有什麼特別的理由，第一是程式組成順眼，至少我可以比較輕鬆的了解整個檔案架構（相比於最早接觸的 Zephyr OS，儘管功能很強，可是整個架構太多可以學習的地方讓人不知道要怎麼下手），第二是程式碼風格也很簡潔，組成也易懂，第三是 RT-Thread 有一個很簡單的內核實現 RT-Thread Nano，能夠讓我很簡單的剝離出我最想先學習的內核架構使用，並且在整合進 STM 系列生態系也簡單許多。

RT-Thread 簡介

資訊

以下內容主要出自於 RT-Thread 官網

RT-Thread 是源自中國的一個開源 RTOS，主要由 C 語言撰寫，而且是使用 OOP (Object-oriented programing) 方法撰寫的。其主要 Architechture 如下：

RT-Thread Architechture

RT-Thread 的實現功能非常豐富，而我對下面幾個已實現部份感興趣：

Hard Real-time Kernel : RTOS 主要的核心功能，用這個部份來熟悉整個作業系統的運作模式
IoT Connection Components : 包括底層通訊規範（ETH、Lora…）到上層的協議規範（LwIP）或是更上層的應用，透過已經實現的規範更了解通訊機制，而且也想嘗試移植其他工業用規範或應用。
Exception Handling / Log : 通常在建構整個系統，尤其是複雜的整合系統時，最麻煩的就是如何紀錄系統的錯誤，如果有良好的錯誤日誌機制，在系統執行任務出現問題時才能夠快速的定位出問題。
Network Framwork : 如上面的 IoT Connect Components 一樣。
FinSH Console : 過去在開發 bare metal 的應用時，沒有標準化輸入輸出介面真的有點麻煩，能夠蹭別人開發好的當然讚。
Key Value DB : Key-Value 結構在之前開發應用的時候很常用到，尤其是 JSON 輸出，在應用層協議真的用起來很有彈性。
Device Framework : 抽象化介面對於應用開發真的是一個福音，但是建立一個良好的設備系統真的是大學問。
POSIX API : POSIX 畢竟行之有年，而且許多應用也都是會根據 POSIX 進行開發，如果能夠移植 POSIX 對於各類應用的適配性一定有幫助。
RTI SystemView : 過去在使用 FreeRTOS 時有使用過一次 SystemView，對於圖形化整個 RTOS 運作的強大功能印象深刻。
Utest : RT-Thread 下的單元測試框架，能夠針對運行在 RT-Thread 上的程式模組進行 Unit test 並記錄結果。

除了上述功能以外，也對 RT-Thread 實現的一些手法感興趣，例如：

Object Oriented : RT-Thread 是使用 Object Oritened method 進行程式編寫的，並且對於內核的一些物件有特殊的機制去管理。
Kconfig : 過去對於 Linux 的內核配置選單就很感興趣，之前在 Zephyr 也體驗過，這次想深入了解到底要怎麼用。

目前規劃

首要目的當然是希望透過理解 RT-Thread 的 Source Code 更理解整個 RTOS 乃至 OS 的概念，以及實現辦法。所以應該會先就 RT-Thread 的內核實現進行一系列學習和研究：

內核 Object 的實現
IPC 的實現 (Mutex, Semaphore, Event, Mailbox …)
Scheduler 和 Thread 的實現
內存管理

由於目前使用的是 Nano 版本，希望能夠自己移植其他感興趣的功能上去，除上述原先 RT-Thread 標準版就有的功能以外，還想嘗試增加：

針對整個程式（包含 Kernel 部分）的 Unit Test（目前候選是 Unity）
DDS 的移入
針對有限狀態機的實現

就，慢慢來開始建構自己想要的東西 :rofl:

後語

這篇只是簡單寫寫目前自己的規劃，也沒包含什麼太有意義（？的東西，主要是寫來督促自己，希望自己能夠持續的更新這系列文章。

Integer Promotions

Sun, 09 Jul 2023 22:32:01 +0800

來討論一點整型提升

Overview

C語言的發明人 Dennis MacAlistair Ritchie 與 Kenneth Lane Thompsont 創設以下規則：

引用

“A character, a short integer, or an integer bit-field, all either signed or not, or an object of enumeration type, may be used in an expression wherever an integer maybe used. If an int can represent all the values of the original type, then the value is converted to int; otherwise the value is converted to unsigned int. This process is called integral promotion.”

也就是所謂的 Integer Promotion （整型提升）。
Wiki - 整型提升：

Wiki

整型提升的意義在於：表達式的整型運算要在 CPU 的相應運算器件內執行，CPU內整型運算器 (ALU) 的操作數的字節長度一般就是 int 的字節長度，同時也是CPU的通用暫存器的長度。因此，即使兩個 char 類型的相加，在 CPU執行時實際上也要先轉換為 CPU 內整型操作數的標準長度。通用 CPU（general-purpose CPU）是難以直接實現兩個 8比特字節直接相加運算（雖然機器指令中可能有這種字節相加指令）。所以，表達式中各種長度可能小於int長度的整型值，都必須先轉換為int或unsigned int，然後才能送入 CPU去執行運算。

C Standard (C99 / N1570)

C99 中有關 integer promotions 的地方分別在：§5.1.2.3, §5.2.4.2.1, §6.3.1.1, §6.5.2.2, §6.5.3.3, §6.5.7, §6.8.4.2 以下將不按照順序，按筆者的閱讀邏輯講解：

§6.3.1.1

§6.3.1.1 / 2, 3

The following may be used in an expression wherever an int or unsigned int may be used:

An object or expression with an integer type (other than int or unsigned int) whose integer conversion rank is less than or equal to the rank of int and unsigned int.
A bit-field of type _Bool, int, signed int, or unsigned int.

If an int can represent all value of the original type (as restricted by the width, for a bit-field), the value is converted to an int; otherwise, it is converted to an unsigned int. These are called the integer promotions. All other types are unchanged by the integer promotions.

The integer promotions preserve value including sign. As discussed earlier, whether a “plain” char is treated as signed is implementation-defined.

此處講明了假設一個原始的型態能夠被 int 表達，則會被轉換至 int；要不然則會被轉換至 unsigned int，此行為稱作 integer promotions。

前段也敘述了 integer promotions 會發生的情境：

Integer type 且 Integer conversion rank 小於或等於 int 或 unsigned int
bit-field type

並且 promotion 以後的數值是會保持著原本的正負。

提示

Integer conversion rank 同樣於 §6.3.1.1 / 1 有描述。

§5.1.2.3 / 11

EXAMPLE 2 In executing the fragment

1
2
3


 char c1, c2;
 /* ... */
 c1 = c1 + c2;

the ‘‘integer promotions’’ require that the abstract machine promote the value of each variable to int size and then add the two ints and truncate the sum. Provided the addition of two chars can be done without overflow, or with overflow wrapping silently to produce the correct result, the actual execution need only produce the same result, possibly omitting the promotions.

這邊用了一個例子來簡單說明了 Integer promotions，在 C Standard abstract machine model中，這段運算的 char c1, char c2 都會被整型提升至 int，使其不會產生 overflow 的結果，或悄悄地 wrap overflow。

§6.5.2.2 / 6

If the expression that denote the called function has a type that does not include a prototype, the integer promotions are performed on each argument, and argument that have type float are promoted to double. These are called the default argument promotions. If the number of arguments does not equal the number of parameters, the behaviors is undefined. If the function is defined with a type that includes a prototype, and either the prototype ends with an ellipsis (,…) or the type of the arguments after promotion are are not compatible with the types of the parameters, the behavior is undefined. If the function is defined with a type that does not include a prototype, and the types of the arguments after promotion are not compatible with those of the parameters after promotion, the behavior is undefined, except for the following cases:

one promoted type is a signed integer type, the other promoted type is the corresponding unsigned integer type, and the value is representable in both types;
both types are pointers to qualified or unqualified versions of a character type or void.

這邊解釋了 function argument 的 promotion 情境，當：

Function without prototype
Function has variable arguments

會使用 default argument promotions 。

參考以下解釋：

stack overflow - I want default argument promotion’s example

可以得知 default function prototype 的使用情境。

提示

另，在 stack overflow - Function without prototype called with non-compatible type 之中有說到了 function declare without prototype 的講解，底下的 comment 也有提到 function without prototype is old syntax you should not use in new code.

針對 function 的 parameters 和 arguments 的 integer promotion，有幾個會造成 UB (Undefined Behavior)：

如果 function 的 prototype 是 defined，但經過 promotion 之後的 arguments 和 parameters 是無法匹配起來的，會造成 UB。
如果 function 的 prototype 是 not defined，parameters 和 arguments 雙邊進行 promotion 之後是無法匹配的，也會造成 UB。

提示

也可以參考以下資訊 stack overflow - Default argument and parameter promotions in C

§6.5.3.3

The result of the unary + operator is the value of its (promoted) operand. The integer promotions are performed on the operand, and the result has the promoted type.

The result of the unary - operator is the negative of its (promoted) operand. The integer promotions are performed on the operand, and the result has the promoted type.

The result of the ~ operator is the bitwise complement of its (promoted) operand (that is, each bit in the result is set if and only if the corresponding bit in the converted operand is not set). The integer promotions are performed on the operand, and the result has the promoted type. If the promoted type is an unsigned type, the expression ~E is equivalent to the maximum value representable in that type minus E.

The result of the logical negation operator ! is 0 if the value of its operand compares unequal to 0, 1 if the value of its operand compares equal to 0. The result has type int. The expression !E is equivalent to (0 == E).

此段講解了 unary arithmetic operator 使用上的 integer promotions 場景：

Unary + operator
Unary - operator
Unary ~ operator

此三個 unary operator 都會表現出 promoted result，+E 甚至可以當作主動觸發 Integer Promotion 的方法。

§6.5.7 / 3

The integer promotions are performed on each of the operands. The type of the result is that of the promoted left operand. If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined.

此段是對於 Bitwise shift operators 的更多說明，當使用 Bitwise shift operators 時，兩邊的 operands 都會 integer promotions，並且若右側的 operand 是負數或其 shift 的位數 (bits) 大於等於左側 promoted 以後的位數 (bits)，則是 undefined behavior。

提示

在 jserv 老師的 <2021年「Linux核心」暑期課程> 中的 <位元旋轉實做和Linux核心案例> 中有講解到關於 Linux 核心在實做位元旋轉時因應 integer promotions 所做出的不同實做。

節錄位元旋轉實作和 Linux 核心案例

Linux Kernel 曾經的 32 位元旋轉實作如下：

1
2
3
4


 static inline __u32 rol32(__u32 word, unsigned int shift) 
 {
 return (word << shift) | (word >> (32 - shift));
 }

但上述實作當 shift 為 0 時，其中 » 32 對於 32 位元整數來說，會遇到 C 語言中規範的 undefined behavior（如上述規格書所述）

因此後續進行改善為如下實作：

1
2
3
4


 static inline __u32 rol32(__u32 word, unsigned int shift)
 {
 return (word << (shift & 31)) | (word >> ((-shift) & 31));
 }

但上述主要是因為 32 位元的 integer promotion 的結果造成 UB，如果是 8 位元的實作則並不會有問題：

1
2
3
4


 static inline __u8 rol8(__u8 word, unsigned int shift)
 {
 return (word << shift) | (word >> (8 - shift));
 }

§6.8.4.2 / 5

The integer promotions are performed on the controlling expression. The constant expression in each case label is converted to the promoted type of the controlling expression. If a converted value matches that of the promoted controlling expression, control jumps to the statement following the matched case label. Otherwise, if there is a default label, control jumps to the labeled statement. If no converted case constant expression matches and there is no default label, no part of the switch body is executed.

此段是對於 switch statement 的附加敘述，switch statement 的 controlling expression 會先經過 promote，然後各個 Label 在進行 convert 進行比對。

關於 Integer Promotions 的一些想法與延伸

實際上關於 Integer Promotions 的發生可以說是必然的，就如同 Wiki 上所說的，任何值要送入 ALU 運算時都會需要把數值存進某個 register 中，而這個 register 大小通常等於 int 的大小。當送入 register 的情況發生以後，實際上就等同於發生了 Integer Promotions 。
機器（硬體）上的“必然”在軟體是由規格書特別規範出來，這樣似乎可以針對語言的 Abstract machine 進行討論了…（下集待續？）

其他參考資料來源

ISO/IEC 9899:201X (N1570)

那些生活上的趣事（一）

Sat, 08 Jul 2023 22:26:02 +0800

辦公處近晚照

前言

人生苦短，快樂長存（X

反正這個系列（希望是系列？）打算拿來紀錄一下生活中多少碰到的趣事，大多是短篇分享。

嚴重意外受傷除了痛還可以幹麻？還可以拿來當作地獄題材

大概在五月出的時候，我們的同事 Tim 因為意外工作期間受了很嚴重的傷，左手食指和中指被粉碎性骨折。發生的當下大家都很驚慌，因為 Tim 的慘叫幾乎可以是突破天際。好在是後來送醫手術後目前恢復狀況良好。

但你以為結束了嘛？這個愛好地獄梗的辦公室怎麼可能放過這個題材。

首先是造成意外的機器因為捲進 Tim 的手指，有了新的外號"捲捲號"，以後 Tim 在介紹這台機器的時候甚至可以說

“看，這是我的手指”

還有 Tim 本身也很愛拿自己當題材，他後來回來以後描述那天被送上救護車的時候的心境變化：

“我那天原本在救護車上一直在擔心自己的手指如果沒了要怎麼辦，可是我又突然想到，如果手指沒了，是不是就可以申請殘障手冊了？這樣我找停車位和停車費就可以狠狠的省一筆，手指突然就沒這麼痛了”

萬幸後來手指依然好好的待在 Tim 的手上，可惜 Tim 在救護車上的幻想了。

有次幾個同事一起出去吃飯，Tim 因為手還在康復期間，左手很常會比出一個軟軟的 YA 手勢，我看到了趕快拍下來。

“欸，迅猛龍”

拳上

最近剛結束完拳上的拳賽，那天有幾個同事都有一起看直播，結果隔天有幾個直接瘋了。尤其是 Tien 先生，整天在咻咻的出拳，弄的好像真的想去打拳賽一樣。重點是我和 Tien 先生會一起去健身，那天他臨時有事沒辦法去，發了一則訊息給我。

“欸欸我今天有事就不去練拳了喔？”

我看是想打拳想瘋了。

剛好最近有發生了”嗆人事件“，我們的 Tim 總工程師，因為最近早上有時候會外出去買工程用品，會比較晚進公司。那天有個同事看到 Tim 早上沒進公司以後，說了一句：

“股東是不是都不用準時上班啊？”

掀起一陣波瀾。:rofl:

看來本辦公室可以籌備一場拳上了。

減重計畫

最近辦公室有女同事為了之後想穿上伴娘禮服開始實施減重計話，但是我們幾個 R&D 看到他的飯量真的不敢苟同他的計畫，中午僅僅吃了一小盒花椰菜米和蔬菜，一看熱量就超級低，然後下午開始喊餓。

當然喜歡解決問題~~出餿主意~~的 R&D 們怎麼會坐視不管，當然是開始想辦法解決同事的民生問題，吃不飽怎麼能做好事呢？

我們開始針對辦公室的零食上的熱量精打細算，幫她找出能夠解饞又不至於發胖的吃法。

“不要這鈉含量很高:expressionless:”
“蛤這個我不喜歡:confounded:”
“少騙了這熱量一看就很高欸:unamused:”

真是難纏。

於是我們只好討論熱量吃多一點沒關係，多運動就好，於是討論到了游泳。

Tim：“欸欸以前游泳都喜歡找旁邊都有熱食部的，游完泳起來吃一碗熱食超級舒服”
Tien：“對啊對啊以前小時候我游泳完我爸都端一碗鍋燒意麵給我，哇賽那真的超級讚”

噢不，減重主角看起來又更餓了。

不過後來好像一兩天後他就偷吃零食了，看來總算想開了，可喜可賀。~~減重失敗~~

超涼感症候群

最近一個朋友圈裡掀起了一陣組電腦風潮，幾個以前從沒換過電腦的電腦小白第一次開始自己挑零件，第一次自己組出理想中的電腦。

當然，一同流行起來的還有可怕的 RGB 和一定要讓電腦很涼症候群。

RGB 我可以理解，畢竟幾年前我第一次組電腦得時候也是如此，一定要讓電腦跟電子花車一樣，RGB 插好插滿，多錢也沒問題。

畢竟內行的都知道，RGB 能顯著提高電腦 50% 的效能。

不過後來我開始無法忍受每次晚上睡覺還要有個閃瞎人的夜光燈在那邊閃，還有久了以後根本就不會去注意的燈效，於是 RGB 症候群就自然痊癒了。

但是超涼感症候群我就不太能理解了，我知道電腦溫度太高會降低元組建壽命，但是你到底想要電腦多涼…？

“已保護當事人”

SSD 插那麼大一個風扇的用意是…？想讓電腦感冒嗎？

“會不會下次我去你家你的電腦已經能夠起飛了”

一場從零引發的慘案

Sat, 01 Jul 2023 23:12:03 +0800

討論一點浮點數

前言

不久前，朋友在群組貼了一篇文章，引起了我的興趣，文章內容大致是在討論IEEE 754關於浮點數中+0與-0的差異以及運算性質，看了看突然發現自己對於浮點數的概念幾乎忘的一乾二淨了，再加上對於文中的性質也有不小的興趣，因此乾脆開始了浮點數的學習之旅。

資訊

實際上這篇文章應該是兩年多前寫給自己看的，搬運過來水一篇文章XD

關於浮點數…

浮點數(Floating Number)，是常見紀錄小數手段，相對於定點數(Fixed Number)，浮點數利用 $N = X × 2^y$ 使得小數點的位置並不固定，讓能夠紀錄的數字達到更廣的範圍。

其中，在1985年提出的IEEE 754規範了目前的浮點數格式，並沿用至今。

IEEE 754

先由浮點數的格式入手，可以分為三個部份：

Sign
Exponent
Significand

Sign用來表示此數字的正負號，只有1 bit，Exponent 則用來表示2的乘冪，Significand 則用來表示尾數。大致如下：

$$ (− 1)^s × M × 2^E\quad——— \quad(1)$$

而在C語言中的 Float(32-bits) 和 Double(64-bits) 分別對應如下：

IEEE 754 Float and Double

而其中，一個IEEE 754規範的浮點數又可以分為三個種類：

規格化數 (normalized)
非規格化數 (denormalized)
特殊值 (special: NaN, Ifinity)

規格化數(Normalized Value)

Normalized Value

規格化數是浮點數格式中佔最多的種類，其Exponent的部份介於255和0之間。在這個種類中:

Exponent 的部份會表示為 $E = e − Bias$，$E$ 為上方(1)式的2的乘冪部份，$e$ 為 Exponent 部份所表示的無號整數，$Bias$ 為 $2^{(k − 1)} − 1$，其中 $k$ 表示為 Exponent 部份的 bit 數，因此 Float 的 $Bias$ 為 $2^{(8 − 1)} − 1 = 127$，Double 的 $Bias$ 為 $2^{(11 − 1)} − 1 = 1027$。

Significand 的部份會表示為 $M = 1 + f$，也就是 $1.f_{n − 1}f_{n − 2}f_{n − 3}…$ ，這種方法可以使 Significand 的部份可以增加 1 bit 的精度(因為前方多了一個隱含的開頭1)，因此可以肯定

$$0<=fraction<1$$

非規格化數(denormalized Value)

Denormalized Value

為了表達規格化數無法表達的更小的浮點數，IEEE 754提供了一個特性稱為 Gradual underflow ，讓浮點數表示能夠平滑的向下接近 0 的數字，也就是非規格化數的種類。

非規格化數的 Exponent 全為 0，而 $E = 1 − Bias$，$M = f$，相較於規格化數，非規格化數少了M的隱含開頭1。

其中，當 fraction 全為零，sign 為 0 時，可以得到 +0.0，而 sign 為 1 時，可以得到 -0.0，這樣設計的好處是，假設一個數字經過運算後已經過小到浮點數無法表示的程度，但是 +0.0 和 -0.0 仍然可以讓我們輕鬆知道這個數字原始是大於 0 或是小於 0 的。

提示

+0.0 和 -0.0 在 IEEE 754 規格中是兩個不同的值( sign 不同)，但是其進行對比得出的結果會是 equal 的，但若進行其他運算則又有可能得出不同的結果，而這些特殊運算結果都是有定義的。

提示

關於 $E=1−Bias$ 而非 $E=−Bias$ 是因為這樣提供了規格化數到非規格化數平滑的過度。

特殊值(Special Value)

Special Value

當 Exponent 部份全為 1 時，會得到特殊值，如圖所示。

特殊運算

IEEE 754 有很好的定義了個別特殊運算的結果：

其中 NaN 與任何數字做任何運算都會得出 NaN 的結果。

程式驗證

資訊

以下程式參考於一系列的 blog 並使用 g++(C++14) 編譯與 gdb 進行 debug

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


#include <iostream>
#define _DEBUG

union Float_t{ 

	Float_t(float num):f(num){} 
	bool Negative() const{ return (i>>31)!=0;} //Sign 
	int32_t RawMantissa() const{return i & ((1<<23)-1);} //Significand 
	int32_t RawExponent() const{return (i>>23)&0xFF;} //Exponent 
	int32_t i; //IEEE 754 float的直接轉成正整數表達結果 
 float f; //IEEE 754 float

#ifdef _DEBUG 
	struct{
		uint32_t mantissa:23; //Sign 
		uint32_t exponent:8; //Exponent 
		uint32_t sign:1; //Significand 
	}parts;
#endif

};

int main(){ 
	union Float_t num(1.0f); 
	for(;;){ //Breakpoint here. 
	printf("%1.8e,0x%08X,%d,%d,0x%06X\n",
				num.f, num.i, num.parts.sign, num.parts.exponent, num.parts.mantissa);
	}
}

利用gdb進行debug修改各個部位的數值並觀察，其中下面給出幾個比較特殊的結果：（皆以sign = 0作為範例）

0 (float)
1 (float)
最大標準化數
最小標準化數
最大非標準化數

提示

可以看到由於使用 $E = 1 − Bias$ 的關係，最小標準化數與最大非標準化數之間有平滑的過度
最小非標準化數
NaN
Infinity
最大整數奇數此數字為float所能表示的最大奇整數，由於其Significand為最大，且Exponent經過Bias運算後正好為23，對應Significand 的23 bits，在此數過後由於Exponent將會>23，所以無法在表示出任何奇數，換句話說，在16777216之後的整數，float在表示時精度都會小於同數字的 int表示方法。如下圖所示: 可以看到當>16777216之後的所有奇數都會無法表示。

IEEE 754浮點數以及其整數格式…

當遞增浮點數無號整數表示時的值，其對應的浮點數數值也會朝著遠離零的方向移動。因此浮點數能夠使用整數序函數來進行排序。
以下程式為一道 Computer Systems: A Programmer’s Perspective 書內的題目：撰寫一個函數，只能使用給定的幾個參數測試輸入函數的第一個參數是否小於等於第二個參數，又假設兩個參數不會有NaN，並且+0和-0被認為是相同的。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


// 使用gcc進行編譯
union Float_t{ 
	float f; 
	unsigned int ui;
};

int float_le(float x, float y){ 
 
	union Float_t X,Y;
	X.f = x; 
	Y.f = y; // Get the sign bits 
	unsigned int sx = X.ui>>31; 
	unsigned int sy = Y.ui>>31;

	// Given an expression using only X.ui, Y.ui, sx, and sy
	return sx==sy?((X.ui<<1)<=(Y.ui<<1))^sx:sx|((X.ui<<1)==0&&(Y.ui<<1)==0);
}

Reference

IEEE Standard 754 Floating Point Numbers

Floating Point

Comparing Floating Point Numbers, 2012 Edition

Computer Systems: A Programmer’s Perspective

這就是開始嗎？

Mon, 26 Jun 2023 12:26:32 +0800

A charming café located near the sea in Kaohsiung Mituo. Please enjoy a cup of cofee and take a break.

前言

不免俗的，第一篇先來對於這個 Blog 的誕生，以及對過去自己經歷的反思和對未來的期許充點字數。

可能內容會包含不少冗言閒談，又或是一些很主觀的看法觀點。總之就像封面圖一樣，如果有閒的話，可以泡杯咖啡，當作看個簡單的廢文休息一下。

緣由

到底什麼時候開始萌生架一個網站的想法其實也忘了，或許是過去看了很多前輩在自己的網站上無私的分享著各項技術，以及自己碰過的坑，幫助了最早期懵懂在科技汪洋的我能夠至少抓住點方向。

後來自己稍微有點經驗以後，大概想著也希望自己能留下點什麼資訊，除了紀錄自己曾經走過的路給其他人參考，也是讓自己未來回首時能夠多一份參考資料。

更重要的，其實也是用來逼自己往前走的。

實際上過去的自己，在大學畢業以前，總是懵懵懂懂的，雖然隱約的知道自己的方向。畢竟從小就耳濡目染了工程師的工作，甚至國中開始就參加各類比賽，也早早的就接觸到並參與了一些簡單的業界開發，但實際上，我依然不知道自己為什麼要做，更不知道自己的終點在哪裡。

說終點好像有點過於沈重了，應該說最早的我，完全是沒有目標的在走，看到什麼做什麼，淺淺的觸碰了一點以後就又被其他東西吸引走了注意力。所以你可以說我都做過，但就都做不好。就像當年我申請研究所推甄時，洋洋灑灑的寫了一堆會的東西，後來自己回頭看到以後不經啞然失笑，這麼一大堆不就某種程度上的代表自己什麼都不精嗎？

但至少我當初完全不這麼覺得，甚至很長一段時間一直引以為傲。

於是就這樣如浮萍一般的隨波逐流很長一段時間以後，大學延畢狠狠賞了我一巴掌。

延畢的原因也說來可笑，單純就是我自己某個必修課完全因為提不起興趣的關係，長期的蹺課和不念書，妄想用考前臨時抱佛腳的方式唬弄過去。但很不幸的，完全不行，於是在大四下又一次必修被當掉以後，我才驚覺的開始反省自己的過往種種。

我到底想做什麼，我現在在做什麼，我為什麼要做什麼。從那時候開始我很常詢問自己這些問題。

但是單純的詢問自己，實際上也得不出任何答案，就如同任何的理論就算推論的在過完美，沒有經過實驗證實的理論終究無法得到科學面上的信服。而這個 Blog 就如同我的實驗記錄本，透過寫實驗記錄這件事情，去逼自己在現實中真正的去實踐某先想法，並且透過這些紀錄去反思到底哪個目標是我打算邁向的。

當然另一部分也是怕自己不斷地會忘記某些事情，留點紀錄給以後去提醒以後的自己，或是讓以後的自己感到羞恥也不錯。

至少，這樣代表我有成長了？

期許?

引用黃仁勳的一段話：

引用

“Vision” is an awfully big word to me. First of all, vision matters. But I like to use the word “perspective” because it makes it possible for anyone to have one. When you say vision, it feels like only a few selected visionaries of the world can have one. But everyone has a perspective and that’s, in fact, all visions means. That you see the world in a way that is either different or otherwise than somebody else. And you see opportunities that I think you believe are particularly important to go on and address. That you can address in a particualr way.

所以，我的觀點是什麼？既然每個人都有觀點，那我對於自己，對於生活，對於任何事情，我是否能夠提出一個觀點。

更重要的是，我是否能夠根據我的觀點去實現什麼，去改變什麼，去影響什麼。

期望自己也能夠透過不停地記錄和成長的過程，真正的找出自己的 “Perpective”，去找出我在這條人生經歷上打算實現的，想去感受的，以及願意付出的。