颱風天解數學

颱風天Facebook上出現學弟提出的一個問題，感覺是個國中/國小數學競賽的程度，適合幾年沒碰數學的人回憶一下 orz

題目：98/49 = 8/4 = 2，相當於分母分子消掉重覆的數字9；64/16 = 4/1 = 4，相當於分母分子消掉重覆的數字6。還有其他解嗎？

為了定義清楚，以及稍微縮小範圍，以數學的語言重新描述：
找到所有a, b, c符合(10a+b)/(10c+a) = b/c，其中a, b, c為1~9的整數

• 整理後得a(10c-b)=9bc，所以左方被9整除，考慮
• a=9 → 10c-b=bc → 10c=b(c+1)，右方為10的倍數，考慮
• b=5 → c=1，95/19=5/1
• 2|b → b=8, c=4，98/49=8/4
• 9|10c-b，考慮
• 10c-b = 9 ~ 81共九種可能性，不難發現都是b=c → a * 9b = 9b^2 → a=b，也就是無聊解99/99=9/9, 88/88=8/8, ..., 11/11=1/1
• 3|a 以及 3|10c-b
• a=3 → 10c-b=3bc → 10c=b(3c+1)，類似前面的分析可知無論b=5或2都無解
• a=6 → 20c=b(3c+2)，考慮
• b=5, c=2，65/26=5/2
• 3c+2=5, c=1, b=4，64/16=4/1

回過頭來考慮其他三類型：

• (10 a+b)/(10a+c)=b/c 或 (10b+a)/(10c+a)=b/c 都會是無聊解因為就是分子分母一樣
• (10b+a)/(10a+c)=b/c其實就是前面的解b, c互換，變成19/95=1/5，49/98=4/8，26/65=2/5，16/64=1/4

iOS 9.3.3 JB

偶然發現盤古已釋出iOS 9的JB，機不可失馬上來升級！升級資訊主要參考瘋先生，在Mac環境完成iPhone 6及iPad Mini 2的升級與JB。略整理如下：

• 不論是Mac或Windows，我會先更新iTunes（也只有JB時才在更新），然後用iTunes完整備份（包含app）。另外我習慣關掉iTunes的自動同步，避免發生非預期的同步。越獄時建議關掉iTunes。
• 備份的同時可以下載iOS 9.3.3的ipsw，可以google的到，並選擇對應的機型下載。如果忘記是哪個機型，Apple官網有提供辨識方法。
• 這次的JB方式有兩個，自行選擇所需要的軟體下載
• 下載PP助手，PP助手導入盤古越獄：但PP助手安全性一直受質疑，所以...
• 利用Impactor導入盤古：下載Impactor及盤古越獄安裝檔(NvwaStone_1.1.ipa)
• 基本上越獄的步驟都是「備份→升級→回復備份→越獄」，只要注意不要把最後兩步驟搞混就好；另外如果哪邊不順利或是死機就是從第二步驟再跑一次
• 升級是用iTunes的「回復iPhone」，搭配Windows的Shift或Mac的Alt按下按鈕，可選擇剛才下載的ipsw。升級後在iPhone做些初始設定後，最後一步選「從iTunes回復」，然後在iTunes選擇最近的那個備份來回復。
• 在電腦開Impactor，將盤古越獄安裝檔ipa拖曳進Impactor，裝完iPhone裡就有盤古越獄app。這次越獄比較特別需要用到憑證，要照瘋先生網誌裡講的到「設定」裡去信任憑證。
• 越獄的方法就是打開盤古app，點START，然後按電源鍵一下。跳出訊息後再解鎖進去看桌面有沒有Cydia，有Cydia就越獄成功。
• 事實上這次越獄號稱是「比較有彈性」的越獄，或者其實像以前的「非完美越獄」，也就是重新開機後就變成沒越獄的狀態，Cydia和其他Cydia安裝的app都還在，但無法開啟會閃退，要用盤古app再越獄一次。
• 有些偵側JB的app，就可以重開機使用而不用重刷
• 因為平常使用很少會重開機，影響不會很大；以前要從電腦上的盤古來JB，但這次盤古直接裝在iPhone裡，方便很多！

過程中遇到的一些問題及心得：

• 雖然有PkgBackup之類的Cydia備份工具但一直無法正常用，所以都是用最陽春的備份方式：手機錄影。用另外一隻手機錄Cydia的已安裝套件，一頁頁滑到底。
• 目前Cydia會裝的是
• Activator：各種自訂手勢
• CCSettings：自訂開關控制器，例如3G網路、wifi、藍牙、定位
• Fully Masked Passwords：輸入密碼時，按鍵盤不會出現放大的字元
• iFile
• Speed Intensifier：加快iOS各種轉場動畫
• WiFi Passwords：記憶並呈現曾經輸入過的wifi密碼
• ActionMenu：選取文字後的選單增強，尚未支援iOS9
• Six Icon Dock：尚未支援iOS9，先裝了betterFiveIconDock
• 因為之前裝Six Icon Dock後來改betterFiveIconDock，Dock最右邊的app會被隱藏起來，只能靠搜尋app來執行很不方便。用iFile到 /var/mobile/Library/SpringBoard 把IconState.plist和IconSupportState.plist刪掉後respring，重新整理桌面和dock。
• 不知道是不是越獄的bug，在越獄狀態下iOS自己的「設定」會閃退開不起來，但在裝了Cydia的PreferenceOrganizer 2後就解決了。

2016 日本行

Google相簿：https://goo.gl/photos/Bpz6Vs61TqbWZKWR

Day 1

• 桃園→名古屋 
• 機場快速列車搭至名鉄名古屋駅 
• 車站附近領車：Subaru Impreza、Mazda 5 MPV、Mazda 6 Wagon、Toyota老車 
• 開車至惠那峽，搭遊船，沿岸很多被命名的石頭但不一定認得出來

品字岩

• 開車至馬籠宿，大家不知道10am-4pm以外的時間可以開車上去，傻傻地拖行李爬坡。馬籠茶屋附晚餐、早餐。

血紅色的生馬肉

• 晚餐畢四處走走，但其實店都關了，後來硬闖了一家還沒鎖門裡面燈還亮著的雜貨店XD

Day2

• 早上行程是臨時增加的中山道健行，因為茶屋主人非常推薦！
• 前一天晚餐後熱烈討論行程怎麼走，狀況當時有四台車、18個人，有一位痛風發作所以不能走，大家想要完整走完全程(將近8公里)。
• 結論是兩隊人馬+病患先開兩台車到妻籠，病患待在妻籠停車場，其他人從妻籠走向馬籠，再開另外兩台車。另兩隊當然是直接從馬籠走向妻籠。
• 缺點是開車的兩隊會花比較多的時間：除了剛開始開車，馬籠比妻籠高一些，所以妻籠往馬籠的上坡較長。優點是上坡較緩，而且走到後段有一間免費喝茶處，到馬籠時商店、郵局也都營業了可以逛逛。

有熊的話要搖鈴示警

免費喝茶休憩所

• 中山道走完，時間有點趕，買了些零食後就往合掌村邁進(各車各走各的)。這天是我開車，高速公路上一直跟著前車飆，最先抵達目的！
• 雖然時間不多，能看的點都盡量看了。走到展望台實在有點累，畢竟今天已經走過中山道了…

• 開車至高山Alpina Hotel，我們這車最先到所以先去有名的飛驒牛肉店訂位。可惜沒那麼多空位，最後只有6個人去。Hotel印的優惠券可換得每人一大杯免費啤酒，很划算。結束後又去居酒屋續攤，喝些地酒，五個人各點一種(我拿到深山菊)，苦的到甜的都不錯喝。

Day 3

• 走到附近的高山陣屋，也就是以前的國稅局，看裡面的房間、構造。

• 到附近的老街，飛驒牛的商品很多，各式的吃法都有。

• 往上高地國家公園是禁止私人車輛通行的，所以是先停在停車場再搭巴士或計程車上去。反觀台灣，大家都開車塞爆各大山上景點，最美的風景是廢氣和塞車。
• 到hotel下行李後，往大正池的步道來回(3.5公里*2)。時而看到野生猴子，靠太近其實會有攻擊動作，要小心。

大正池

• 晚餐極度豐盛，還有舖床服務，加上在國家公園內，難怪這間要那麼貴T_T

Day 4

• 開車至松本車站，大家下車後司機開車去加滿油還車，然後租車店再載司機們到車站。
• 坐火車到信濃大町，將行李直接寄到晚上的hotel，然後坐巴士到扇澤開始黑部立山路線。接下來就是一直換交通工具。

• 沿途有很多蓋章的點，集滿可以換紀念品，但大家在第二個點就miss了...
• 黑部水壩
• 六月底才洩洪，只好以後有機會再來
• 傳說中的水壩咖哩飯有點弱...

• 黑部平
• 有步道可以走但大家趕下一班纜車，未久留
• 大觀峰
• 室堂
• 可惜剛好超過開放時間(3:15pm)，無緣參觀6公尺雪壁，只好走步道摸摸雪

• 美女平
• 立山
• 搭火車至富山
• Hotel就在富山車站旁，晚餐也是去很近的拉麵いろは。吃完再走一公里多到著名的Starbucks環水公園店。

Day 5

• 下雨，逛藥妝店搜刮後，坐巴士到富山機場，回國

Hotstring優化：追求極致速度

AutoHotkey的最大優點就是簡易的語法，方便設定hotstring及hotkey。不過畢竟最後是CPU在跑，寫一行程式碼，不一定比三行程式碼還快，要讓程式跑得快，還是要以電腦的角度去思考。例如以最簡單的 ::btw::by the way 為例，trigger之後AutoHotkey會模擬鍵盤傳給Windows的code，Windows再送到active的文字編輯器，文字編輯器被接收到一個鍵會觸發/更新一些內建數值（例如目前是第幾個字元、總共幾個字元、儲存上個狀態以便Ctrl+Z可以復原等等），然後更新文字輸入區的畫面，讓使用者知道程式沒當掉依然有反應。在AutoHotkey的範圍內可做到幾點優化：

• SetBatchLines -1
• 預設設定下，AutoHotkey每執行一行程式碼，會短暫休息，再執行下一行，以避免讓CPU太操。但既然用AutoHotkey就是要效率，給他催下去！
• SendMode, Input
• 預設的Send是SendEvent模式，但SendInput在大部分的狀況下是Z>B，包括
• 送字速度快
• 因為有buffer，如果程式正在send字串時使用者也按下鍵盤，使用者按的鍵會在字串送完時接上，而不會中斷（最多buffer 5000個字元）
• SetKeyDelay, -1, -1
• 這個設定也是類似SetBatchLines，為了模擬正常人類按鍵，按下去會有一定duration，兩個按鍵間一定有一些delay，通常是遊戲才會偵測有沒有cheat
• 雖然這個設定影響的是SendEvent，但有非常少數情況下AutoHotkey會自動從SendInput轉換成SendEvent或SendPlay，所以還是可以設定
• 複製貼上法
• 對於較大量的字串，例如某個procedure note的範本，用send會非常慢。比較直覺的方式是用剪貼簿當作媒介來複製、貼上

sendByClipboard(ByRef str){<br /> ;clip:=ClipboardAll<br /> clipboard:=str<br /> send ^v<br /> ;ClipboardAll:=clip<br /> }

• 註解掉的兩行是為了保留原本的剪貼簿內容，但在連續輸入的情況下不太需要
• 有一說要搭配ClipWait，但日常小量字串應該都能順利運作，所以沒有使用
• 實測比較SendInput和sendByClipboard，發現大概以7~10個字元為分界，更多的字元後者較快，較少的字元前者較快。
• sendByClipboard的缺點：
• 組合鍵（用到Ctrl, Alt, Shift, Win等）無法用（不過通常也不會很大量）
• 單行定義的Hotstring會依據首字是否大寫/全部大寫，送出相對應的字串（首字大寫/全部大寫），sendByClipboard只能用笨方法來模擬。（注意後兩個搭配c選項）

::btw::<br /> sendByClipboard("very very long string")<br /> return<br /> <br /> :c:Btw::<br /> sendByClipboard("Very very long string")<br /> return<br /> <br /> :c:BTW::<br /> sendByClipboard("VERY VERY LONG STRING")<br /> return

• 直接送字法
• 利用剪貼簿畢竟多了一道程序，可以直接設定輸入框裡要顯示的文字。
• Standard edit control可以搭配Edit library，測試會比剪貼簿方法還快，但缺點是全部文字整個更新，畫面可能會閃一下，或者捲軸的位置不一樣：

#include <edit><br /> <br /> sendEdit(ByRef str){<br /> Text:=Edit_GetText(Focused:=getFocused())<br /> ,Edit_GetSel(Focused, s, e)<br /> ,Edit_SetText(Focused, SubStr(Text, 1, s) str SubStr(Text, e+1))<br /> ,Edit_SetSel(Focused, sel:=s+StrLen(str), sel)<br /> ,Edit_ScrollCaret(Focused)<br /> }<br /> <br /> getFocused(){<br /> static GuiThreadInfoSize = 48<br /> VarSetCapacity(GuiThreadInfo, GuiThreadInfoSize)<br /> ,NumPut(GuiThreadInfoSize, GuiThreadInfo, 0)<br /> ,DllCall("GetGUIThreadInfo", uint, 0, str, GuiThreadInfo)<br /> return FocusedHWND := NumGet(GuiThreadInfo, 12) ; Retrieve the hwndFocus field from the struct.<br /> }

• Scintilla control是SciTE、NotePad++所使用的，可以搭配Scintilla wrapper以及自己寫的RemoteScintilla，速度和standard edit差不多，優點是很多強大的功能。
• 在自己的gui建立及操作Scintilla control要用Scintilla wrapper，但如果要access或modify其他process中的Scintilla control，則要用RemoteScintilla，利用_RemoteBuf library搭配Scintilla Documentation裡列出的messages（AutoHotkey的ControlGetText和ControlSetText只針對standard edit）。
• 利用SCI_ADDTEXT，可以在游標處插入字串，而且游標會跳到加入字串的最後面，和Hotstring或是複製貼上的動作是一致的。

#include <remotescintilla><br /> <br /> sendSci(ByRef str){<br /> sci:=new RemoteScintilla(getFocused())<br /> sci.AddText(str)<br /> }<br /> <br /> getFocused(){<br /> static GuiThreadInfoSize = 48<br /> VarSetCapacity(GuiThreadInfo, GuiThreadInfoSize)<br /> ,NumPut(GuiThreadInfoSize, GuiThreadInfo, 0)<br /> ,DllCall("GetGUIThreadInfo", uint, 0, str, GuiThreadInfo)<br /> return FocusedHWND := NumGet(GuiThreadInfo, 12) ; Retrieve the hwndFocus field from the struct.<br /> }

Automatic Lung CAD

Low dose chest CT漸漸成為趨勢，幾乎是chest X-ray般的輻射劑量，卻提供超多細節，以及chest radiologist的工作量 T_____T

本院chest CT檢查量就像物價一樣漲個不停，打起來最爽快的莫過於cancer follow up，爽點包括：

• 已經有診斷、有治療，定期追蹤看有沒有復發、轉移，大部 分都是post-op changes, non-specific changes，以及一些雜魚tiny stable nodules。
• 有前人打的報告，copy & paste再做些修改。
• 之後會繼續來追蹤，有nodule沒看到，下次總會有機會再看到。
• Multiple bilateral lung metastases最為#無痛，而且可以#秒殺，因為就已經是一堆nodules了啊！

相反地，low dose chest CT可怕之處在於：

• 通常是較健康的人（例如健檢），只有非常少、非常小的nodule
• 因為是健康的人，氣吸很飽，肺變得很大，守備範圍加大…
• 這個檢查要看細切影像（1mm），動輒兩三百張，非常耗神耗眼…
• 萬一沒找到lesion，下次回診時可能已經真的有cancer了，雖然不一定有相關性，但被告的機率感覺比較高，#怕怕der
• 因為low dose，soft tissue看不清楚，liver到底有沒有tumor只能瞎猜

當LDCT成為事實，CAD就是義務！

目前部內的架構是：

• 做完CT → 細切傳至部內RAID（Osirix, iMac）
             ↘ 粗切傳至醫院資訊室PACS

為了自動化CAD，幻想中的流程是

CT → 某台強大電腦運算CAD  ← user query

• 可惜本人image processing很弱，只看paper無法自己拼成可用的程式
• 也是有別人寫好的現成的matlab code，但效果沒有很好…

於是規劃了複雜的流程
CT → RAID → Workstation (CAD) → Orthanc server   ← user query

細節如下：

• 做CT，series name需要改為「LungCARE」，傳至部內RAID
• Osirix設定auto-routing，有「LungCARE」的series會自動傳至#S牌工作站
• 工作站設定「LungCARE」的study自動apply為MM Oncology，而且會在背景先做CAD
• AutoHotkey程式，每天早上三點（所謂三更半夜四下無人）會執行
• 登入
• 篩選「昨天」的「LungCARE」
• 打開study
• Show lung CAD results
• Accept all candidates（本來是要醫師自己到場accept或reject每一個candidate）
• Complete and archive：result會存成一個新的series
• 工作站設定result的series再自動re-routing到自己架的server（Orthanc）

主要的考量包括：

• S牌工作站
• 可以找GGN，accuracy還算OK
• 軟體介面是AutoHotkey可以access到的
• 向工程師要到某種帳號，可以做進階設定
• CAD可以pre-processing，不用現場等，前提是一定要命名為LungCARE
• 其他工作站：
• G牌：本部最舊的，很久沒更新；軟體只能一次處理一個case，無法批次處理；用linux系統，不熟…
• P牌：CAD很弱...
• T牌：介面無法用AutoHotkey抓，不能找GGN或是4mm以下的nodule
• RAID轉運站
• 每一台CT都會傳到RAID，而且Osirix可以設定auto-routing，就不再麻煩放射師要另外傳到工作站
• 缺點是主機老舊，硬碟容量小，其實就是一個外接硬碟而已，還要常常手動更換，和「RAID」完全沾不上邊…
• Orthanc server
• 支援web介面查詢、瀏覽series、基本影像操作（亮度/對比）
• 支援REST API，可以用http request配合json查詢、抓影像

使用者端（chest radiologist們）則用另一個AutoHotkey程式，將下列動作綁在一個hotkey：

• 抓RIS目前報告的病歷號
• 用http request去查自架server是否有符合的result，有的話…
• 在已開啟/新開啟的firefox或chrome打開連結，直接連到web viewer的頁面

目前要再做一個server，針對非LDCT，可以丟一個病歷號過去，然後：

• 從RAID拉影像（用dcm4che）
• 修改series name為「LungCARE」（用ExifTool，或是出動Python）
• 將dicom傳到工作站，等CAD
• 登入工作站，accept candidates，export result
• 回傳通知CAD已完成

雖然很複雜，但目前能力只能做到這樣，希望以後有更好的流程～