※ 引述《jaw109 (潑文章都是為了養小雞)》之銘言： : 我想紅綠的的控制應該很簡單吧 : 就算路口有sensor, 你要加演算法在裡面 應該也難不倒幾個大學專題生 紅綠燈的控制多半不是只處理一個路口的紅綠燈， 也要考慮周邊其它的路口的連動，才不會造成走一小段就要等一次紅燈的情況。 因此它的演算法本身是相當複雜的。 如果我們把紅綠燈 reduce 到作業系統裡面的 scheduling 問題， 我們可以作以下的 mapping 將一堆車從一處送到另一處 -> task (process) 轉換燈號 -> context switch 每個燈號的時間 -> 執行的 interval 啟動波 -> context switch overhead 各燈號的連動關係 -> task dependency 事實上我們可以把簡化過的紅綠燈問題看作跟作業系統的排程同構， 同時也有相同的最佳化目標， low latency 與 throughput (low latency 對每個人而言都不要等太久 throughput 總共能通過的車流最多 ，兩個目標之間是有衝突的) 要取得一個最佳平衡點的演算法是 NP-Hard ， 也就是我們目前還找不到在 polynomial time 的解， 簡言之，一次考慮越多的路口，要作的計算時間就會呈指數大增。 (當然這樣的講法有點過度簡化，看得懂的人知道意思就好了) 講得更直接一點，要處理紅綠燈問題又解得漂亮， 絕不是大學專題可以做得出來的，如果真的解了， 請寄信給我，我要拿去當博士論文。 : 我無法理解 幾個簡單的線路 控制面板的箱子做那麼大的原因是什麼 控制面板的箱子裡面除了控制這個路口的燈號， 也可以控制附近的燈號，另外裡面有 modem (或是其它的通訊系統)， 可以透過中央控制一次，從遠端一次控制很多地方的紅綠燈。 絕不是只是固定時間就切換一次燈號那麼簡單。 : 說防彈 防止民眾撬開還比較好說服人 交通號誌對 reliability 的需求非常高，馬路如虎口， 如果今天交通號誌不小心出了個錯，兩邊都是綠燈，恐怕就被罵到臭頭了， 裡面絕不是一台控制的機器就好了，一定會作 redundency ， 同樣功能的機器至少要有兩台，避免一台壞掉，就失去作用。 當然自我修復或自我檢測的功能也必須要有。 紅綠燈不亮還算事小，亮錯就爆炸了。 : 題外話. 春節期間在楓港還遇到999秒的紅燈，有夠扯。停紅燈還可以下車買飲料...XD -- --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.112.31.132