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 DietThe 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」全文

日本橋人形町

日本橋,

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

閱讀「日本橋人形町」全文

更之前的文章