偏差值與 PR 值的轉換器
偏差值：
PR 值：
(4333) 的詛咒
有 (4333) 牌型的時候會因為王吃比較困難，所以王牌合約很可能無法比無王多打一墩。Richard Pavlicek 的統計數據探討了以下狀況中有黑桃配合時各種牌型的成約率比較：
- 3NT vs 4♠：(4333) + 平均牌及 6322 + 2344 時 3NT 比較好打。
- 2NT vs 3♠：5(332) + (4333) 及兩手 4333 時 2NT 比較好打。
- 1NT vs 2♠：只有兩手 4333 時 1NT 好打。
- 6NT vs 6♠：都是 6♠ 好打。
總體趨勢是，聯手力量越強，無王相對好打的情況越多。以下我們討論要如何應用在叫牌中。
1NT 後續
答叫人持 (4333) 不要叫 Stayman，當成沒有高花的平均牌就好。
在 Stayman 問到高花後，答叫人回另高花 1NT-2♣; 2♥♠-3♠♥! 可能是平均牌的 choice of games 或滿貫試探。
自然制 4-4 配合
在 1♣-1♠; 2♠ 之後，答叫人有 2NT 到 3♠ 共 5 格空間可以邀請。這時候，如果答叫人有 4333 牌型，就可以叫 2NT 邀請；叫自然 3♠ 則是 5 張平均牌邀請。新花可以自行討論要叫長門、（反向）短門、或 help suit。
本站 Discord 伺服器
為了方便大家交流，我們建立了一個 Discord 伺服器，歡迎大家加入！
我們通常討論橋牌叫牌制度，偶爾也會談論日麻和其他遊戲，也會討論數學和程式相關的議題。
迫叫梅花之路
我喜歡資訊理論，也喜歡研究叫牌制度。去年開始看 Good, Better, Best (Larsson 2021) 一書，覺得波蘭梅花是很適合自然制橋手學習，理論上又能贏過自然制的制度，於是入坑至今。書中認為含 canapé 的強梅花制更強一些，但是跟波蘭對戰的實驗不多，也跟自然制差異較大，我還在研究當中。另一方面我也在撰寫橋牌函式庫 pons 當中，雖然進展很慢但還是希望未來能做一些有趣的實驗。
一、調整弱二開叫
現代橋牌當中竄叫的重要性不亞於建設性叫牌，而且改動的話因為空間比較少，所以要記的東西比較少。電腦模擬顯示不顧牌組品質的五張高花弱二是最佳的自然竄叫1。而且五張弱二贏過六張的差距，大於自然制五張高花開叫贏過四張的差距2，但仍小於迫叫梅花與自然制的差距3。
至於 2♦ 要拿來做什麼呢？有兩個很不錯的選項能輔佐五張高花竄叫，而且都比自然方塊好4 5。
考慮長遠目標是要打迫叫梅花制，我認為 Multi 是較好的選擇。
- 如果要打小梅花制，自然梅花可以用 1♣ 叫，騰出 2♣ 給 Ekren 使用6。
- 如果要打強梅花制，最好搭配 canapé 倒叫，這樣高花就只保證 4 張。既然 4 張高花平均牌會開叫高花，Ekren 就沒那麼必要。
- 2♦
- Multi，6 張以上高花，4–10 HCP
- 2♥♠
- 恰好 5 張，4–10 HCP
Multi 後續的版本很多，可以選一個自己喜歡的
- 葉庭佑編寫的 Multi 2♦ 後續
- 我編寫的火斑喵波蘭梅花裡面的 Multi 2♦ 取材自 FunBridge 及上述葉庭佑的版本
至於高花弱二我建議就用火斑喵波蘭裡面的版本。要特別注意的是蓋叫新花不迫叫，因為需要逃跑的場合變多，例如 5-1 跟 5-0 通常不想打。
二、波蘭梅花
除了電腦實驗的證據外，有太多跡象顯示 1♣ 作為迫叫叫品比自然叫品還要好。
- Pierre Albarran 發明的強 2♣ 開叫已經成為自然制的標配，而且實戰上也贏過強二7以及跟 EHAA 打平8。如果需要擺一個無上限的迫叫叫品，為什麼不移到空間更多的 1♣？
- 自然制橋手也逐漸發現 1♣-1♦ 作為自然方塊其實很垃圾，常常跳過 (bypass) 4 張甚至更長的方塊去答叫高花。讓 1♣ 迫叫，然後 1♦ 負性答叫，對於留下大量空間的 1♣-1♦ 叫序似乎是更好的歸宿。
- 其實 2NT 開叫放強牌也不是好選擇。在精準制各版本的對抗當中，2NT 作為兩低花竄叫的現代版本清一色贏過傳統 22–23 HCP 的版本9。
跟自然制相比，波蘭梅花尤其是專業版，建設性開叫變化不大，是我最推薦自然制橋手學習的迫叫梅花制度，也是我個人只打自然制十幾年後最先學習的人為制度。
建設性的牌，也就是成局一半力量以上的牌，只有兩種我們挪到 1♣ 裡面開叫：
- 所有 18 點以上的牌
- 只有 4 張方塊的低限平均牌 (12–14 HCP)
波蘭梅花專業版不再使用類似精準制的自然 2♣。整個 2 線我們都拿來做竄叫。
- 1♣
- 18+ HCP，或者 2 張以上梅花、12+ HCP
- 1♦
- 11–17 HCP，5 張以上方塊或 4♦(441)
- 1♥♠
- 11–17 HCP，5 張以上
- 2♣
- Ekren，高花 (44) 以上，4–10 HCP
- 2NT
- 低花 (55) 以上，4–10 HCP
後續可以參考我的火斑喵波蘭梅花以及原版的波蘭梅花 2020 專業版10。
三、強梅花制
（待續）
參考書目
- Jassem, Krzysztof (2020). Polish Club 2020: Expert. Translated from Polish by Tomek Brus. ISBN 978-1771402248
- Larsson, Jan Eric (2021). Good, Better, Best: A comparison of bridge bidding systems and conventions by computer simulation. ISBN 978-1771402415
註腳
在 Linux 上使用 Nintendo Switch Pro 手把
今年發現用鍵鼠玩遊戲會導致機械鍵盤暫時接觸不良，於是 11 月初在朋友的推薦下就買了 Switch Pro 手把。按起來真的很很舒服，不過卻從此開啟了惡搞之路……。
首先，在 Linux < 5.16 並沒有 hid-nintendo 這個任天堂系列手把的驅動程式，所以 Steam 自幹了透過 hidraw 去抓手把的動作的驅動程式。所以如果插線接電腦然後打開 Steam，其實 Steam 可以抓到手把。然而最初我遇到的問題就是右蘑菇頭會一直亂飄，飄到我需要用 Steam 的手把校正功能把死區調大才解決。
然後到月底直接不演了，放在桌上都可以各種亂飄，並且產生莫名其妙的按鍵輸入。用 Gamepad Tester 一看才知道原來時脈被當成按鍵，然後被當成軸的意義不明，可能是陀螺儀吧。
hid-nintendo 核心模組
Daniel Ogorchock 大大寫的 hid-nintendo 終於要進 Linux 5.16 了。然而，我所使用的 Fedora 35 此時的核心版本仍然是 5.15.4。幸好我們可以利用 dkms-hid-nintendo 自行安裝。（-v 所接的版本可能會再更新，請到官網再確認。）
git clone https://github.com/nicman23/dkms-hid-nintendo
cd dkms-hid-nintendo
sudo dkms add .
sudo dkms build nintendo -v 3.2
sudo dkms install nintendo -v 3.2
安裝過後，一般的 Linux 程式和瀏覽器都能正確讀取 Switch Pro 手把的輸入。
joycond 常駐程式
然而 Steam 直至今日仍然不支援 hid-nintendo，所以我們還需要 Daniel Ogorchock 大大的 joycond 才能玩 Steam。它的原理是去模擬一個未知的任天堂手把，然後再讓 Steam 讀取這個虛擬的手把。
既然是不認識的手把，那就需要自己定義按鍵的定義了。我建議直接使用 Steam 預設的按鍵配置就好。雖然它看起來是 Xbox 或美版 PS 的配置，但是最後存檔的時候只要選擇它是 Switch Pro 手把，Steam 就能透過「使用 Nintendo 按鍵配置」(Use Nintendo Button Layout) 把 A/B 和 X/Y 調整回來。
然後因為 hid-nintendo 會過濾掉雜訊，所以死區也可以再縮小，讓手把的反應更敏捷。
思源宋體來啦！
思源宋體真的來啦！
終於有字重齊全的宋體啦！不用再讓思源黑體 cosplay serif
字型啦！本來我還想要募資把王漢宗明體補完的說……。XD
我已經把字型檔整理起來，並且也附上轉換成更適合作為網路字型的
WOFF 檔。歡迎各位下載或以 @font-face 套用於網頁上。感謝
GitHub 願意成為大家的 CDN。
Clerkship 懶人包
為了維護病人隱私，如果簡報中有個案資料，無論真實或虛構，則需要登入北醫帳號才能讀取。
內科
- 新陳代謝科
- 翁瑄甫《糖尿病之治療及新趨勢》
- 血液腫瘤科
- 陳博明
Oncologic emergencies
🔒 - 胸腔內科
- 吳宗翰《胸腔 X 光片基本判讀》 🔒
- 麻醉科
- 陳建宇《美國 ACGME Milestones 之導入與建置⸺以麻醉科為例》
- 腎臟內科
- 高治圻《腎絲球疾病》 🔒
- 學術討論
- 倪衍玄《糞土黃金》（影片）
- 小考解答
- 小考解答 🔒
- 胸腔內科
- 柯信國
Dual bronchodilator in GOLD 2017
案例討論 🔒###
此處只列出日期和講者，因為講題可能包含病人姓名，應保密。
讓 nginx 重定向遵循 HTTP
根據 RFC 2616，除了 Location
標頭外，回覆實體（也就是一般使用者看到的網頁）裡面也需要包含重定向的目標。不過基於程式的健壯性原則，瀏覽器等
user agents 會選擇只看
Location，而且從網頁中找尋正確的連結對程式來說比較困難。然而，一般使用者還是有機會看到重定向的網頁，例如重定向失敗1的時候。
不過 nginx 的錯誤頁面（狀態碼 ≥ 300）其實都沒有附連結。以 302 重定向為例：
幸好 nginx 可以讓我們自訂錯誤頁面，並且支援 SSI。所以我就自己寫了重定向頁面。這樣就有符合 HTTP 標準的重定向頁面了。
該頁面已經搬家囉！
==================
它的新家在 <a href='<!--# echo var="sent_http_location" -->'><!--# echo var="sent_http_location" --></a>。
-
依規定 301, 302 重定向只接受 GET 和 HEAD，因此以其他請求方式就會停在回覆實體。 ↩
在 nginx 上調整所有文本的編碼
全站的文字檔都使用相同編碼是很常見的。尤其是 UTF-8
儼然是今日的實作標準。然而，nginx 預設的 charset_types
設定不包括 text/css，遑論其他非純文本。（例如 text/markdown）
預設的 charset_types 應該要是 text/* 才對，因為為了向後相容，許多 text/*
格式預設解讀為 ASCII (us-ascii)。就連 text/xml
也是如此，即使檔案中有 BOM 和 XML
宣告也徒勞無功。所以，現在我們應該用 application/xml 來傳遞
XML。
然而 charset_types 設定只檢查完全符合的 MIME，不然就必須用 *
匹配所有類型。幸好 nginx 有可以匹配正則表達式的 map，而且 charset_types
也接受變數。
map $sent_http_content_type $charset {
~^text/ utf-8;
}
charset $charset;
charset_types *;
這樣的設定會讓 nginx 指定所有文本為 UTF-8，例如 text/css; charset=utf-8。
如何用嘸蝦米打出〇
嘸蝦米從〇到十都是一碼字。取 O 就可以打出〇
了。
事情不是憨人想的這麼簡單。
實際在 Unicode 查碼網站查詢用嘸蝦米打出來的○
其實是空心圓圈
(U+25CB WHITE CIRCLE)
而不是漢字〇
(U+3007 IDEOGRAPHIC NUMBER ZERO)
為什麼會用錯誤的○
代替漢字〇
呢？這也不是嘸蝦米願意的。過去台灣使用的中文編碼是 Big5，當初 1970 年的溪頭會議就堅決把〇
當成符號而不是字，因此也就只收錄符號○
。在嘸蝦米輸入法設計的時候，Unicode 尚未興盛，當然就是收錄 Big5 中的○
了。
直到 Unicode 興盛以後，嘸蝦米也從善如流把〇
加入字根。然而為了向後相容，要打出〇必須選字。不過多數使用者，包括過去的我，仍然一直傻傻地把 ○ 當成中文的〇……。
把 ○ 當成〇有什麼影響
對機器來說 ○ 就只是個符號。這對於電腦翻譯是一大阻礙，更會干擾視障人士的輔助設備。視障輔助軟體把二○一七
唸成二, white circle, 一七
甚至二、十七
都有可能，留下滿頭問號的使用者。
此外，對明眼人來說，把 ○ 當成〇也很醜。因為 ○ 是符號，所以字型的設計上會與漢字脫鉤，和漢字擺在一起就很不協調。而且文字加粗時，符號應該保持原狀。粗體的 ♠、斜體的 ♠ 看起來仍是 ♠。
| 錯誤版 | 正確版 |
|---|---|
| 二○一七 | 二〇一七 |
| 二○一七 | 二〇一七 |
| 二○一七 | 二〇一七 |
| 二○一七 | 二〇一七 |
| 二○一七 | 二〇一七 |
| 二○一七 | 二〇一七 |
〇字的身世
〇
是則天文字中的星
。南宋算草中亦以圓圈符號代表 0，於是後來〇才假借為 0。雖然〇也可以算是符號，但是使用上與一、二、三等漢字無異，字型設計上應視為漢字。而且〇
與表示正確、圈選的○
的意義迥異，應該視為不同的字元。