台北是否真的出現異常暖冬現象?我們用機率分布來回答

台北是否真的出現異常暖冬現象?我們用機率分布來回答
Phote Credit: 林澤民

我們想讓你知道的是

台北市1897~2020年低溫時間序列顯示,1897年台北市的最低溫是攝氏5度。以此為資料中的第一個紀錄,124年來,有9個新的紀錄出現。這樣算是正常現象嗎?這個問題,可以用機率理論做精確的回答。

台灣這幾天比較冷,但暖冬仍然是全球暖化過程中一個明顯的趨勢。一般以為全球暖化始於19世紀末葉先進國家積極工業化的時候,然而世界各地工業化的進程不同,暖化的趨勢也會有所差異。當工業化在全球範圍內日益普及,各地暖化趨勢便益見明顯,但還要等到20世紀下半葉,這趨勢才明顯到引起各國的注意。

在美國一直要到1988年,氣候變化才正式成為官方關切的議題。這一年的6月23日,NASA太空研究所(GISS)主任James E. Hansen,在參議院能源及自然資源委員會作證指出:「全球暖化的程度,已經顯著到讓我們確信溫室效應與暖化趨勢具有因果關係。依我的意見,我們已經偵測出了溫室效應,而且這效應正在影響我們的氣候。」

以筆者居住的德州奧斯汀市而言,氣溫紀錄始於19世紀末期。我用統計學「改變點」(change point)的方法分析每年最高溫及最低溫的時間序列,檢測出年低溫最顯著的改變點在Hansen作證之後3年的1991年,而年高溫的改變點還要更後,在1998年。這與筆者個人體驗大致相符。

台北氣溫變化趨勢的「改變點」

「改變點」的檢測是時間序列分析的統計方法,它用來判定時間序列的資料產生過程,是否有不連續點的存在。它在1930年代就曾被產業界用來監控產品的製造過程,其後經過數學家的深入研究,在近20年來蓬勃發展,廣泛被應用於環保、疫情、醫療、軍事、反恐等各領域。

筆者個人就曾用類似的研究方法,發現美國歷史上選民的投票行為,在20世紀20~30年代之間,曾經發生過質性的變化。去(2020)年5月,頂級學術期刊《Science》也有研究論文檢測新冠肺炎在德國傳播趨勢的改變點,肯定了政府干預措施的有效性。CBS電視影集《數字》(Numb3rs)甚至有一集,演出「夢幻棒球」玩家用改變點方法,檢測大聯盟球員使用禁藥提高打擊率的故事。

台灣的氣溫紀錄也始於19世紀末。根據Jasmine Kuo提供的台北市年低溫歷史資料,台北市每年最低溫的改變點在1975年,而年高溫的改變點則要到2001年。台北市年低溫的改變比奧斯汀要早,這也許跟地形、地理位置、人口以及工業化程度有關。

理論上,年高溫及年低溫都不是常態分布,而是呈現所謂極端值分布(extreme value distribution)。圖一及圖二以上述改變點為斷點,分別估計年高溫及年低溫在各自改變點前、後的極端值分布。這兩張圖讓我們清楚看出改變點前後的明顯差異:改變點之後,年高溫及年低溫的分布均明顯往高溫方向移動。年高溫在2001之後的平均值增加了攝氏1.44度,而年低溫在1975之後的平均值則更誇張地增加了將近兩倍的2.81度!

1
Phote Credit: 林澤民
2
Phote Credit: 林澤民

時間序列資料產生過程的變化,除了可以用改變點的統計方法來檢測斷點以外,也可以用「紀錄」(record)發生的機率理論來分析異常現象。事實上,事件發生頻率的改變也是改變點研究的數學方法之一。本文以下即以紀錄理論,進一步探討台北市年低溫在1975年之後新紀錄節節升高的現象。

破紀錄次數的機率分布

台北市1897~2020年低溫時間序列顯示,1897年台北市的最低溫是攝氏5度。以此為資料中的第一個紀錄,124年來,有9個新的紀錄出現,分別是:1899(7.2度)、1905(7.6度)、1909(8.1度)、1912(8.2度)、1976(8.5度)、1983(9.3度)、1988(10度)、2017(10.4度),以及2019(11.6度)。(見圖三時間序列中的黑點)

3
Phote Credit: 林澤民

124年間有10個紀錄是正常現象嗎?這個問題,可以用機率理論做精確的回答。

機率理論對「記錄」的研究有很完整的系統。其數學繁複,但相當有趣,有興趣的讀者可以找相關書籍來看,例如Jiri Andel(2001)的《Mathematics of Chance》。

這個理論從一個前提出發:觀察序列中的資料是遵循相同機率分布,而且相互獨立(iid)的隨機變數。在這個假設之下,我們可以導出在n個資料點中有r個紀錄(包括第一個資料點)的機率分布。

這個前提可以說是「正常」狀況的「虛無假設」:它代表觀察序列中資料的產生過程完全相同,沒有任何異常現象或動態趨勢。如果我們的經驗資料與這個假設之下的機率分布不相諧,根據傳統次數主義(frequentist)統計推論的方法,我們可以在一定的統計水平之下拒絕虛無假設,而判定異常現象的存在。

以台北市年低溫的歷史資料來說,我們可以算出在n=124個觀察值的序列資料中,出現r(r=1,2,3,…,124)個紀錄的機率分布,然後從這分布算出r大於或等於10的右尾機率。如果這個機率小於約定成俗的顯著水平0.05,我們判定歷史資料與虛無假設不相諧,從而排除台北市年低溫變遷沒有異常現象的前提。依照傳統統計推論,我們可以做出「台北市年低溫變遷有異常現象」的結論。

以Rn代表在iid假設之下,n=124個序列資料中有r個紀錄的隨機變數,圖四便是Rn=r的機率分布。從這個機率分布我們可以算得Rn的期望值是E(Rn)=5.40,變異量是Var(Rn)=3.76,也很容易直接算得右尾機率P(Rn≥10)=0.025。因為這個機率小於0.05,單尾檢定讓我們得到台北市年低溫屢破歷史上限紀錄,是異常現象的結論。(如果一定要用雙尾檢定,這個結論就有點勉強)

32
Phote Credit: 林澤民

Rn的機率分布並不容易算,有一個遞歸公式,當n較大時,需要很大的計算能量或很久的時間才算得出。要迅速算出,必須用到所謂「第一類史特靈數」(Stirling Numbers of the First Kind)。如果你的軟體沒有這個函數,可以利用這兩個很漂亮的公式,來算Rn的期望值和變異量:

0

利用這兩個公式也可算出當n=124時,E(Rn)=5.40,Var(Rn)=3.76。如果我們假設Rn的分布是常態分佈,則可以輕易算出以以期望值為中心的95%信心區間為(1.49,8.88)。因為經驗值10個紀錄在信心區間之外,這個分析也支持台北市年低溫變化異常的結論。不過因為Rn的分布並非常態,這個分析並不精確。

新紀錄的等待時間

應用紀錄之機率理來分析台北市氣溫變化,也可以看出1975年前後是一個轉捩點。

在1897年之後的9個新紀錄當中,出現在1975年之後短短45年之間的就有5個,平均每9年就有一個新紀錄。而在1976年前的80年中,則平均要將近16年才有新的紀錄。事實上,1912年的紀錄保持了64年才被打破。

也許你會說1897~1912,在短短16年之間不是就有4個新紀錄嗎?然而新紀錄的頻率在紀錄開始之時,本來就會比較頻繁,日久後要破紀錄會越來越難。紀錄的機率理論,可以算在一定時間之內舊紀錄會被打破的機率,其公式如下:

9

這公式所求的是在第r-1個紀錄發生之後,下一個紀錄的等待時間小於或等於m之機率。下面表一之第六行顯示:從第一個紀錄發生在1897年開始,第二個紀錄等待了兩年就發生了,按照上式,第二個紀錄在2年之內發生的機率為0.67。第二個紀錄發生在1899年之後,第三個紀錄等待了6年發生,而其在6年之內發生的機率也是0.67。第三個紀錄發生在1905年之後,第四個紀錄要等待13年才發生,而其在13年之內發生的機率是0.31。

依此類推。這些機率都不小,雖然紀錄頻頻被打破,並不令人意外。尤其是第五個紀錄發生在1912年之後,第六個紀錄要等64年才在1976年發生,因為等了夠久了,其在這一段期間發生的機率是很高的(0.80)。

8
Phote Credit: 林澤民

但從1976年以後,這個等到下一個紀錄的機率就急遽下降了。第七個紀錄在7年內發生,其機率是0.08;第八個紀錄在5年內發生,其機率是0.08;第九個紀錄等了29年,其機率稍大,但它發生之後,第十個紀錄只等了2年就發生,其機率小於0.03。

這樣的小機率事件發生了,如果還說氣候沒有異常,在統計學理上是無法接受的。

如果我們換一個角度來看,把1976年當作氣候質變之後的第一個紀錄,則其後發生在1983、1988、2017的新紀錄其等待時間的機率(0.88,0.38,0.69)都不小,不算奇怪。只有2019的紀錄還在0.05的水平之內,不過這也可以說氣候變化越來越厲害了。

從新紀錄的等待時間來探討氣候變遷,還可以看看新紀錄發生的平均時間。不過很奇妙的是:機率理論告訴我們,新紀錄雖然一定會發生(發生的機率為1),其發生時間的期望值或理論平均數卻是無窮大,即使第二個紀錄也是一樣。

以第二個紀錄為例,其發生時間為2,3,4,…,t,…年的機率分別為1/2,1/6,1/12,…1/t(t-1),…,所以期望值為1+1/2+1/3+…+1/(t-1)+…。這是有名的無窮和諧數列,它不是收斂數列,其和無窮大。其它的紀錄也是一樣。

不過我們雖然不能算發生時間的期望值,卻能算中位數,也就是發生機率最接近1/2的時間點。表一的第七行列出各紀錄發生時間的中位點。我們可以看到,一直到1976年的第六個紀錄為止,中位時間點都還算合理。

此後,第七個紀錄的中位發生點要在1897年算起的第424年,第七個紀錄在第1166年,第九個紀錄在第3200年,第十個紀錄在第8717年。這些紀錄的中位發生時間在這麼久遠之後,如果說沒有氣候變化,誰能相信?

補充

附帶一提,1897~2020之間台北市年低溫往下探的紀錄,包括1897年的第一個紀錄,124年之間只有三個:1897(5度),1898(3.3度),1902(-0.2度)。從1902年以來,118年之中,-0.2度的紀錄沒有被突破!(不過P(Rn≤3)=0.162並不足以作為氣溫變化異常的統計證據)

本文經林澤民授權刊登,原文刊載於此

責任編輯:朱家儀
核稿編輯:翁世航


猜你喜歡


加速敏捷開發腳步!AWS Amplify 協助企業打造高效能應用服務

加速敏捷開發腳步!AWS Amplify 協助企業打造高效能應用服務

我們想讓你知道的是

台灣企業勢必需要明確轉型策略,搭配適合的雲端工具作為入場券,一來降低數位化門檻、二來減少摸索資源的浪費。

打造敏捷開發流程、加速前後端工程師的協作效率,是許多企業在面臨疫情之後,認為亟需將彈性元素納入為企業文化當中。雲端運算服務領導業者 AWS 台灣,觀察到前端工程師主要負責處理最貼近用戶的 Web、行動應用程式,但他們往往需要與後端團隊合作過程,遭遇耗費大量討論時間,才能處理使用者介面事項。

為了降低前後端的溝通成本,有些前端工程師在掌握介面管理能力之後,開始橫跨到後端的伺服器、資料庫開發經驗,甚至進一步培養技能,成為能負責測試、安全、效能多面向的全端工程師。

有的人會透過 Side Project(利用業餘時間開發有興趣的專案)或參加 Hackathon(黑客松)方式,運用 AWS 雲端工具嘗試自行擴展後端,並建立簡單易用的工具程式。究竟,AWS 平台提供哪些資源幫助前端工程師擴展更多元的技能樹?

掌握入門教學!前端工程師如何將 REACT 程式快速上雲

前端工程師運用 AWS Amplify,快速在雲端建立 REACT 應用程式

事實上,AWS 的入門課程指出,運用 AWS Amplify 在雲端建立 React 應用程式及服務集,只需五個學習歷程,包含建立 React 應用程式、初始化本機應用程式、新增身份驗證、新增 API 和資料庫、新增儲存體。如果想快速了解 REACT 程式快速上雲的方法及示範教學,本文節錄 AWS QUICKSTART 學習資源內容,幫助前端工程師更快掌握重點。

首先,何謂 AWS Amplify?AWS Amplify 是一項全托管 Front-End Web & Mobile 服務,採取無伺服器模式,在後端建立、部署和託管單一頁面 Web 應用程式或靜態網站的 Git 型 CI/CD 工作流程,加速開發過程直接整合其他 AWS 服務。舉例來說,像是整合封裝好的 Library 資源、或運用一些 Components UI 軟體去配置後端,以及利用 Admin 的 UI 做資源上的管理。

打造第一個你在 AWS 上的應用程式

AWS Amplify加速Develop、Deliver 與 Manage流程

AWS Amplify 主要優勢展現在三大項工作階段,分別是 Develop、Deliver 和 Manage。Develop 部分可利用 CLI(Command-Line Interface)或 Admin UI 設定後端,使用 GraphQL 或 REST API 設定也是可行的,進而快速建構一個前後端專案。此外,開發者還能搭配 AWS 其他服務,例如使用 AWS Authentication 全托管認證服務,或 DataStore、Storage 等多項 Feature Categories。

到了 Deliver 階段,若是要透過 AWS Amplify 執行 Web Hosting 任務,可拆解出三個流程。首先是將 Repository 與 AWS Amplify 進行連結,這邊可整合 Amplify Console 提供的支援資源包含 Github、Bit Bucket、Gitlab、以及 AWS 的程式碼代管工具 AWS CodeCommit。一旦連結以後,開發者可透過自己的 Configuration,决定在各個不同的 Build 要執行什麽樣的指令,最後再透過 Deploy 方式,幫助工程師進行前端的 Hosting。

在最後一個 Manage 階段,開發者則可利用 AWS Amplify 的 Admin UI,以開啓瀏覽器方式,透過視覺化介面統一管理資源。例如在 Admin UI 介面左側選單,涵蓋 Content、User Management 的區塊,讓參與專案但沒有 AWS Console 權限的使用者,可利用 E-mail 方式邀請使用者進到 Admin UI,進行一些設定或觀看其他相關資源;甚至在 Set Up 區塊還有相關選項,例如要針對 Data Modeling 或 APP User 做權限管理,以及可連結到 AWS 其他服務。

透過 AWS 增加你的雲端技能 在組織發揮你的影響力

運用開放資源 AWS Amplify Framework,打造高效能應用服務

AWS QUICKSTART 學習資源還介紹到另一個 AWS 提供的開放資源 Amplify Framework,一樣可利用 Amplify CLI 的方式,配置 Web 和行動應用程式的前後端,以及開發者需要用到的服務,讓應用程式更易於構建,並獲得安全、高性能的使用體驗。

Amplify CLI 一樣有支援多個不同 Category,例如較常使用的幾個 Comment Line,像是Amplify Init 指令做初始化或創建幾個不同資源;或是 Amplify Status 指令,隨時在開發過程查看各個 Category 狀態;甚至專案結束後,可利用 Amplify Delete 直接把 Amplify 所創建的資源做一次性删除。另外也可透過 AWS Amplify Client 利用比較抽象化方式,讓開發者直接利用 Component 實現想要完成的項目。

實際示範給你看,設定 React 程式可以如此簡單

假設前端工程師現在要快速部署一項有驗證功能(Authentication)還要搭配 Rest API、GraphQL、Analytics 等服務的應用,如何快速設定 React 程式?在 AWS QUICKSTART 的學習資源後半段,有詳細說明要啟動這類型專案的操作方法。

開發者可以先利用 AWS Lambda Function 結合 Amazon API Gateway 方式,創建出一個 Rest API,到了 Authentication 階段,則使用到 AWS Cognito 的服務,接著針對 GraphQL 需求,可利用 AWS AppSync 服務,以及最後如果有 Analytics 的需求,也可以串聯 Amazon Pinpoint 工具。Amazon Pinpoint 是一項彈性而可以擴展的行銷通訊服務,開發人員可利用 Amazon Pinpoint API 追蹤 Web 使用者的行爲,或是針對 APP 推送、電子郵件、簡訊點擊行為蒐集到具體的資訊。

在這整套流程示範之後,值得特別強調的是,AWS AppSync 是一項全托管的服務,能及時更新,甚至在使用者離線時仍可以持續去創建和修改數據。一旦設備連上線之後,這項應用程式就可重新連線,並接到後端同步數據,達成彈性、自動化擴展或減縮各式 API 的請求。

AWS 最後強調,Amplify 是相當適合建構出一個靜態 Web、Apps 服務模式,例如說像是打造部落格,或者是一項 APP 內的代辦事項應用等;加上 Amplify 具全托管服務特色,可串聯上述 AWS 在雲端所提供的資源,都能在部署過程加以整合,加速開發流程及效率,並且有效節省開發資源。如果想用低門檻的雲端解決方案,其實前端工程師是能在開發流程更靈活配置資源,甚至為公司的商業、服務模式挖掘出創新價值。

填寫表單諮詢專人 快速在 AWS 找到適合你的快速上雲服務與工具!

了解更多:AWS 開發者系列


猜你喜歡