すでに数週間経っているが、去年の10月に始めた「週刊 代数的実数を作る」を、一通り書き終えた。

「週刊 代数的実数を作る」創刊

「週刊 代数的実数を作る」中間報告

連載では

• 代数的数の演算
• （整数、有理数、代数的実数、代数的数係数の）多項式の根（または実根）を数え上げる操作
• それに伴い、整数係数の多項式を因数分解する操作

などを実装した。

まだまだ高速化やリファクタリングなど、改良の余地はあるが、ある程度「使える」ものが出来上がったと思う。

今後の方向性としては、 #16 の最後にも書いたが、

• 作った実装を応用する（部分分数分解など）
• 実装の改良に取り組む
• 関連するトピックを扱う

という3つの方向性が考えられる。

もっとメタな方向性として、

• （電子）書籍化
• コードを整理して Hackage に公開

なども考えられる。ついでに、タイトルを「週刊 代数的数を作る」に変えたい気もする。

コードの整理について

もっと上手く型クラスを使えば、似たような関数が別名で存在する、という状況を避けられる。

たとえば、今は代数的実数 AlgReal の定義多項式を返す関数 definingPolynomial と代数的数 AlgNum の定義多項式を返す関数 definingPolynomialN が分かれているが、ここは「代数的数の部分集合」を表す型クラス IsAlgebraic でも作って

class IsAlgebraic a where
  definingPolynomial :: a -> UniPoly Integer
  algebraicDegree :: a -> Int
instance IsAlgebraic Integer
instance Integral a => IsAlgebraic (Ratio a)
instance IsAlgebraic AlgReal
instance IsAlgebraic AlgNum

とするべきだっただろう。

他に、「多項式に値を代入する」部分をもっと柔軟にできるようになりたい。係数の型と代入する型の組み合わせによって適切な計算方法が変わるので、型クラスを使うか、 rewrite rule を使うかが問題となる。型クラスを使う場合は MultiParamTypeClasses は避けられないだろうか。

また、現状では1変数多項式の型は全て UniPoly だが、「原始多項式」「無平方多項式」「既約多項式」など、特定の多項式が期待される文脈に対して適切な別名を与えてドキュメント性を高めるということも考えられる。

（電子）書籍化について

原稿のフォーマットについて

普通に紙の冊子を作り同人誌即売会などで配布することも考えられるが、まずは電子書籍を作るのが手軽だろう。一応、印刷前提の PDF と電子書籍としての EPUB の両方を用意することを目標にしたい。

Web 版の原稿は Markdown で書き、 Hakyll という Haskell 製の静的サイトジェネレーターで Web ページを生成している。実際に Markdown の原稿から HTML への変換を担うのはやはり Haskell 製の Pandoc である。

書籍版の原稿は色々直したいところもあるので、 Web 版の原稿から fork することになるだろう。

さて、 Markdown は、 LaTeX 等と比べて表現力が低い。例えば、相互参照がない。定理環境もない。ルビ記法もない。

まあ、ルビに関しては自前で Pandoc filter を作った（ただし、 Hakyll では Pandoc filter を直接使えない、というか Haskell で直接変換処理を記述できるので、厳密にはただの Haskell の関数）ので、それで良い。定理環境に関しては、クラス付きの <div> タグを使っているので、それをなんとか変換すれば良いだろう。相互参照も Pandoc filter (pandoc-crossref) でどうにかなりそうだ。

というわけで、書籍版の原稿は

• 諸々の Pandoc filter を前提にした Markdown で書き、 Pandoc で EPUB や（LaTeX 経由で） PDF に変換する
• 相互参照も定理環境もルビ記法も既にある LaTeX で書き、 PDF はそのまま処理、 EPUB へは頑張って（Pandoc で？）変換する

という2つの方向性が考えられる。どちらも茨の道に思えるが…。

数式について

EPUB では MathML が使えることになっている（ただし Kindle では使えない）ので、 LaTeX 記法で書かれた 数式を MathML へ変換したい。Pandoc でも LaTeX 数式から MathML への変換は一応できるが、正直言って生成される MathML の品質が低い。

例えば、 \mathrm{hoge} は

<mstyle mathvariant="normal">
  <mi>hoge</mi>
</mstyle>

ではなく

<mstyle mathvariant="normal">
  <mi>h</mi>
  <mi>o</mi>
  <mi>g</mi>
  <mi>e</mi>
</mstyle>

になるし、 \sin x は

<mi>sin</mi>
<mo>&#x2061;<!--FUNCTION APPLICATION--></mo>
<mi>x</mi>

ではなく

<mo>sin</mo>
<mi>x</mi>

になる。この他、 align* 環境では揃える位置に余計な空白が入る。

なので、 Pandoc の数式変換部分 (texmath) にパッチを当てまくるか、それとも数式変換を自分で書き直す（あるいは、出来のいい既存の変換プログラムに投げる）か、が必要になる。

ちなみに、 Web 版での数式表示には KaTeX を使っているが、 array 系環境で \hline が使えない、 \substack に対応していない、などの問題に遭遇した。

その他

「これの原稿を書かないといけない」という強迫観念が消えたので、やりたいことの優先順位をつけないと興味の方向が発散して何もできないということになりかねない。気をつけたい。