196

196

這篇文章是在寫 temporal 那篇文章時，找資料發現的有趣東西，在那篇文章當中，我有說到目前 date 物件的各種問題，其中第六點是「不支援 Gregorian Calendar（格里曆）以外的日曆（例如農曆）」 ，然後我就好奇起來了，現在還有什麼其他的曆法在用呢？結果找著找著，就看到有個網站提供了很多曆法了線上轉換，像是 Julian Calendar（儒略曆）、Hebrew Calendar（希伯來曆）、Islamic Calendar（伊斯蘭曆）、Persian Calendar（波斯曆）等，用 JavaScript 寫的，而且在程式碼裡面宣告貢獻到 public domain。

由於整個網站非常老派，我就對作者起了興趣，發現這個網站 fourmilab.ch 的所有者是 John Walker，Autodesk 的 founder 之一，他現在已經退休搬到瑞士去了，然後 fourmilab.ch 上就放了他的各種記錄，像是文章，其實就是 blog，看他結構感覺也是個 MovableType 站，還有閱讀清單，旅遊照片，例如他去過南極一趟，還有些他寫的書，例如 Hacker's Diet、The Autodesk File 等。

然後，我在 fourmilab.ch 上看到了「Three Years Of Computing」這篇文章，標題就吸引了我進去仔細閱讀，這篇文章是在說迴文數（palindrome）挑戰，什麼是迴文數呢，「95277259」就是迴文數，不論是從頭開始還是反過來從尾開始都是相同的數字，那什麼是迴文數問題呢？首先你要拿到一個非迴文數的十進位數字，例如 362 好了，把他和自己的反轉相加：

>
   362
+  263
------
   625

結果不是迴文數，那繼續一樣的反轉相加運算：

>
   625
+  526
------
  1151
+ 1511
------
  1661

最後得到了一個迴文數 1661，迴文數問題就是，是否所有的正整數都可以透過這樣的運算，不管幾次，最終可以得到迴文數，如果有數字無法透過這個過程變成迴文數，那這數字也可以稱為 Lychrel Number，不過因為目前無法從理論證明一個十進位數是 Lychrel Number，就只能想辦法反證它（註：我有看到說二進位數有證明）。

文裡說到，所有小於一萬的數字都已經被測試過，大部分的數字都可以用很少的次數就得到迴文數，其中，最小的可能的 Lychrel Number: 196 ，到目前還無法讓它經由反轉相加的過程變為迴文數，John Walker 那個跑了三年的程式就是在驗證 196 到底能不能透過反轉相加的過程。他在 1987 年用他的 Sun 工作站開始跑，結果跑了三年後的 1990，達到他當初設的停止條件，100 萬位，總共反轉相加了 2415836 次，他還放上他的程式碼還有計算的結果，如果有人有興趣可以從這邊開始接手繼續算下去，事實上，當初他跑這程式的工作站性能和現在的電腦比起來差距實在很大，在其它人後來的挑戰當中，就有提到一些性能數字，例如 Ian J. Peter 的程式只需要 5 小時就可以計算到一百萬位，用的電腦大約是 500 MHz 的 CPU。

John Walker 在 1990 年跑到一百萬位，結果還沒得到迴文數，那麼現在最新的紀錄是多少呢？p196.org 這網站收集了很多相關的資訊，對這議題有興趣的人還可以去看看，而它站上的紀錄是 413,930,770，四億多位，總共反轉相加了十億次；至於我目前看到的最高紀錄，是在「The p196_mpi page」這裡，提供了平行版的程式，而據作者 Romain Dolbeau 所說，他在 2015 年 2 月已經計算到十億位了，不過他沒提供相關資料，有提供的只有 2012 年的六億位結果。

Temporal - 下個世代的 Date

這篇文章寫到快寫完的時候，決定到 Modern Web 2017 分享，所以就比較晚發佈 ，其實 Modern Web 演講內容比較多，文末有放相關參考資料。

JSConf EU 2017 前陣子放出演講影片，蠻多場次都不錯，這篇要主要是從其中的一場演講而來，演講是「 The Past, Present, and Future of JavaScript Date and Time APIs」，講者是 Matt Johnson，Moment.js 的作者，下面是這場演講的影片：

長度不長，推薦可以看一下，主要是在談 JavaScript 的 Datetime，提出這老東西的問題，我覺得可以稱為 WAT JavaScript 的 Datetime 篇，像是 0 起始的月份、不支援 Time Zone、難以運算、是 mutable 物件等等，接著介紹了目前檯面上比較多人用的幾個 library 和他們的特色，都是品質不錯的 library，有需求的可以從中選用，包括了：

最後則是提到他們目前在進行的，改進 JavaScript Datetime 的計畫，也就是新的 ECMAScript Datetime 的 proposal，叫 temporal，除了 Matt Johnson 之外，還有一位 Microsoft 的 Maggie Pint 也是目前草案的主力推手，他的 blog 上就有兩篇相關的文章，裡面有列出目前Date的主要問題：

  1. 不支援 timezone，只有 UTC 和 local
  2. Parser （轉譯日期字串轉成日期物件）的行為不可靠且難以使用
  3. Date object 是 mutable 物件
  4. 日光節約時間的行為無法預期
  5. 日期計算 API 很難用
  6. 不支援 Gregorian 以外的日曆（例如農曆）

事實上，目前的 Date 物件，當初 Brendan Eich 因為時間緊迫，所以 Datetime 的 API 是直接參考 Java 的，當時是 1995，參考的應該是 Beta 版 Java 的java.util.Date，後來 1996 年 1 月 Java 1.0 發佈，但是到了 1997 年 2 月的 Java 1.1 發佈時，java.util.Date大部分的設計都被捨棄了，然後 1997 年 6 月，ECMAScript 標準 1.0 發佈，結果這個在 Java 語言只活了 1 年多的設計，就活在 JavaScript 世界活了 20 年之久，相信有用過的人都能多少都知道使用起來的痛苦。

不過要改善 JavaScript 從來就不是一件容易的事情，最大的困難點就是你不能隨便改動任何已有的東西，像是已經存在 20 年的Date，即使它設計不好，隨便改動都可能造成大量的網站壞掉，不像是 Java 1.0 升級到 Java 1.1 那樣，各自用各自的，在改善 JavaScript 時基本上就是要當成有人從不升級，不能有 broken change，最簡單的方法就是增加新的東西，而不要去修改舊的，這也是目前 temporal 的方向（其實 ES 5.1 後，舊有的東西該修的東西大概都修完，之後就是一直加新的而已），在 draft 文件已經有一點基礎和預期的 code sample 了：

var ldt = new CivilDateTime(2017, 12, 31, 23, 59);

var addHours = new CivilDateTime(2017, 12, 31, 23, 00)
    .add(2, 'hours');

var zdt = ldt.withZone('America/New_York');

可以看到有方便的加減時間的 API、immutable 特性、還有時區支援等等。事實上這份草案還非常初步而已，還缺非常多細節，預期會有的物件目前已經有八種了，不過這八種物件的 API 也都還沒定義完，不過也正因為如此，想參與的人反而這時候比較有機會提供想法，推薦有興趣的人可以關注關注，給點意見。

最後列一些參考文件：

iPad Pro 10.5-inch

iPad Pro 10.5,

本來其實就一直想要為了四喇叭升級 iPad Pro 了，不過手上機器還可以用就沒下手，最近因緣際會終於要下手升級了，考慮了一陣子卻遲遲無法決定要買 12.9 吋還是剛發表的新款 10.5 吋，直到前天終於我買了 10.5 吋，兩個推手：

  1. 有 n 個人跟我說 12.9 吋太重，雖然我去店面拿起來感覺是還好；
  2. 我自己店面試用有覺得體積是有點過大。
閱讀「iPad Pro 10.5-inch」全文

日本橋人形町

日本橋,

前陣子去東京有些時間可以自己安排，後來因為也沒特別有什麼目標，就決定排個可以比較悠閒的行程，就是去人形町逛逛，其實很早之前就知道人形町了，後來真的比較有印像是看了新參者這部小說，這本小說的舞台就圍繞在人形町，後來阿部寬有主演日劇版，更是大大帶起該地區最近的知名度，除了新參者之外，我偶爾會看有吉君的正直散步，也是有一兩集散步到那附近，所以就把目標放在人形町了。

閱讀「日本橋人形町」全文
➡ 前一個月的文章