この記事は Haskell Advent Calendar 2021 の21日目の記事です。 2020年に発表されたApple Silicon (Arm) Macは、2021年に新チップ “M1 Pro/Max” が、2022年には新チップ “M1 Ultra” が登場し、ますます勢いを増しています。Mac使いの皆さんはもう手にされましたか？ 新しいアーキテクチャーにはハードウェアだけではなくソフトウェアの対応も重要です。この記事では、2022年3月時点のApple Silicon MacへのHaskellエコシステムの対応状況をまとめます。 この記事では、なるべくRosetta 2を使わず、Armネイティブに動作する環境を構築することを目指します。 インストールにどれを使うか UnixでHaskell環境を構築する場合、 パッケージマネージャーを使う GHCupを使う Stackを使う

どうも、浮動小数点数オタクのmod_poppoです。 去年はMacのCPUがx86からArm (Apple Silicon)へ移行することが発表され、実際にApple M1搭載のハードウェアが発売されました。Apple Silicon MacにはRosetta 2というエミュレーターが搭載され、x86系のアプリケーションが（仮想化等の一部を除いて）そのまま動作します。 浮動小数点数オタクとして気になるのは、 Armv8で規定された浮動小数点数関連の命令セット拡張のうち、Apple M1がどれを実装しているのか Rosetta 2がx86_64とAArch64の浮動小数点数に関する違いをどのように吸収しているのか という点です。 Armv8のあれこれ long doubleについて long doubleは環境によって精度がまちまちなのは以前の記事に書いた通りです。 long doubleの

// gcc-10 -march=armv8.3-a arm-jcvt.c という風にコンパイル #include <stdio.h> #include <math.h> #include <inttypes.h> #include <arm_acle.h> // Prototype: // int32_t __jcvt(double); #if defined(__GNUC__) __attribute__((noinline)) #endif int32_t cast_double_to_i32(double x) { return (int32_t)x; } int main(void) { printf("(int32_t)(-2.8) = %" PRId32 "\n", cast_double_to_i32(-2.8)); printf("(int32_t)1.99 = %" P

それぞれの説明はこんな感じである： X: Infinity Control 無限大の符号の扱いを変える設定だったらしい。IEEE 754が標準化される前の痕跡で、387以降は意味を持たない。 RC: Rounding Control 丸め方法を指定する。 00B: Round to nearest (even) 01B: Round down (toward $-\infty$) 10B: Round up (toward $+\infty$) 11B: Round toward zero (Truncate) PC: Precision Control 演算結果の仮数部の精度を指定する。 00B: Signle Precision (24 bits) 01B: Reserved 10B: Double Precision (53 bits) 11B: Double Extended Pr

読むのが面倒な人向けの結論：可換です。 「可換です」以外の答えを知りたい人はこの記事を最後まで読んでください。 結合法則と交換法則 実数の足し算や掛け算については結合法則 $x+(y+z)=(x+y)+z$ が成り立ちます。これに対し、浮動小数点数の足し算・掛け算が結合的でないことはとても有名な話です。 例えば、倍精度で (1 + 0x1p-200) + (-1) を計算すると、結合法則が成り立てば答えは 0x1p-200 となるはずですが、実際には 0 が返ってきます。 浮動小数点演算が結合的でないことは有名な話なので、ここではこれ以上詳しくは取りあげません。 一方で、交換法則（可換性）はどうでしょうか？「浮動小数点演算はこういう法則を満たさない！クソ！」みたいな話題で槍玉に上がるのはほとんどの場合結合法則で、交換法則に言及するものはあまり見かけない気がします。 交換法則が成り立つとどう

この記事では融合積和 (fused multiply-add; 以下もっぱら FMA) について扱います。 この記事は元々「その辺で提供されている fma 関数の実装が正しいかチェックしてみた」記事だったのがだんだん守備範囲を広げていったものなので、FMAを単に使うだけではなく、実装する側の視点が多く含まれています。 筆者が実装したHaskell向けのFMA関数はこちらにあります： haskell-floating-point/FMA.hs at master · minoki/haskell-floating-point FMAとは、FMAを含む規格 融合積和（fused multiply-add; FMA）とは、積と和が合体した演算です。数式で書けば $xy+z$ です。この際、丸め（浮動小数点数で正確に表せない数をそれに近い浮動小数点数で代用すること）を1回しか行わないため、「積→和

2進浮動小数点数の10進表記には様々な問題があります。 10進で有限小数として表せる数であっても、2進小数では有限小数で表せない（したがって2進浮動小数点数に変換すると誤差が出る）ことは周知かと思います。例えば 0.1 という実数を2進で表すと という循環小数になり、有限桁で正確に表すことができません。 10進小数を正確に表したい場合は10進浮動小数点数（あるいは10進固定小数点数など、10進に基づいた小数型）を使うのが適切です。逆に、2進浮動小数点数を正確に表現したい場合はそれに適した記数法を使うのが適切です。 2進浮動小数点数に適した記数法として、1999年に制定されたC言語の規格（C99）では、16進法を使って浮動小数点数を記述する方法が導入されました。 16進の1桁は2進の4桁に対応し、2進法で有限小数で表せる数は16進でも有限小数で表せます。逆も然りです。16進表記は浮動小数点数

どうも、浮動小数点数オタクのmod_poppoです。 昨日開催された ABC169 の C 問題が浮動小数点数の罠な問題だったらしいので、どこが罠なのか、そしてどうすれば罠を回避できるのかを解説してみます。 また、典型的な誤答に対しては、それを落とすためのテストケースも用意しました。 問題文（引用） まず最初に問題文を引用しておきます。 AtCoder Beginner Contest 169 | C - Multiplication 3 問題文 $A\times B$ の小数点以下を切り捨て、結果を整数として出力してください。 制約 $0\le A\le 10^{15}$ $0\le B<10$ $A$ は整数 $B$ は小数第 2 位まで与えられる 入力 入力は以下の形式で標準入力から与えられる。

多くのプログラミング言語には、「2つ以上の数値が与えられた時、その最小値あるいは最大値」を返す関数 (min / max) が用意されている。入力が整数や有理数であれば難しい話はないのだが、対象が浮動小数点数の場合は厄介な問題が起こる。具体的には、「NaN の扱い」と「0 の符号の扱い」だ。 浮動小数点数の NaN は、皆さんご存知の通り、順序付けられない。NaN が絡む場合の min / max 演算については、「入力に NaN が含まれていたら結果も NaN とする」「NaN を入力の欠落として扱い、NaN でない入力があればそれを返す」などの立場が考えられる。 もっと細かいことを言うと、NaN を返す場合に入力で与えられた NaN を返すか、正規化された NaN を返すかという違いもありうるし、signaling NaN の扱いも議論の余地があるかもしれないが、この記事では細かいこと

Haskellの多相型システムでは、型をパラメーターとして取る型を定義することができる。この拡張として、GHC拡張の型レベル自然数を使うと、自然数をパラメーターとしてとる型を定義することができる。 型レベル自然数を使うには、GHC拡張の DataKinds を有効にして、 GHC.TypeLits モジュール（もしくは GHC.TypeNats モジュール）をimportする。 この記事で説明するのは基本的に、GHC組み込みの Nat カインドを持つ型レベル自然数である。データ型として帰納的に定義される自然数については、比較のために紹介する程度にとどめる。 初級編 まずは、型レベル自然数の基本的な使い方を紹介する。 雰囲気を掴む 小難しい話に入る前に、GHCの型レベル自然数の雰囲気を見ておこう。 {-# LANGUAGE DataKinds #-} {-# LANGUAGE ScopedT

先の記事では、Haskellエコシステムに色々ある文字列型を分類しました。この記事では、色々ある文字列型を変換する方法を説明します。 パッケージの依存関係：変換関数を探すにはどこを見れば良いか 各種文字列型や変換関数を提供するパッケージ間の依存関係は次のようになっています（依存元パッケージから依存先パッケージに矢印を伸ばしています）： 当たり前ですが、変換関数が用意されているとしたら変換元の型と変換先の型の両方を参照できるパッケージです。つまり、 Text と ByteString の変換関数を探したかったら bytestring パッケージではなく text パッケージを探すべきです。なぜなら、 bytestring パッケージの関数は Text 型には言及できないからです。 同様の理由で、 ByteString と CStringLen の変換関数を探したかったら bytestring

Haskellの文字列型について Haskellの文字列型には色々あります。標準の String のほかに Text や ByteString があり、Text と ByteString はそれぞれstrictとlazyの2種類ずつあります。 Haskellを学びたての方はこれを知ると「なんでこんなに色々あるんだ？Haskellはクソなのか？」と思われるかもしれません。 ですが、それぞれの文字列型にはちゃんと存在意義があります （まあ String は標準であること以外取り柄のないクソですが……）。この記事ではそれぞれの型の特徴と使いどころを解説します。 ここで説明する対象は、主に以下の型です。 String Text 系 strict Text (textパッケージ) lazy Text (同上) ShortText （text-shortパッケージ） ByteString 系（byte

Haskellの文字列とは まず、Haskell標準の文字型・文字列型が何であるかを確認しておきます。 Haskell 2010では Char 型はUnicode characterを表す、とされています。 Haskell 2010 Language Report -- 6.1.2 Characters and Strings 「文字」というのが非自明な概念であることを知っている方であればUnicode characterって具体的にはなんやねん！と言いたくなるかと思いますが、GHCにおいては Char 型はUnicodeコードポイントを表します。つまり、 0 以上 0x10FFFF 以下の整数 です。特に、サロゲートコードポイント（0xD800 以上 0xDFFF 以下）も有効な Char 型の値です。 GHC の Char 型の説明 String は Char のリストです。 これらの

先日のHaskell Dayでderivingに関する発表があった Haskell Day 2019を開催しました！ aiya000, 「しんさんきぼう」のDerivingストラテジー ので、触発されて私もderivingについて思うところを書いてみます。主にderiving系拡張の落とし穴・注意点に重点を置きます。 標準でderiveできるやつ、またはGHCに組み込まれているやつ (stock deriving) 標準で Eq, Ord, Enum, Bounded, Show, Read, Data.Ix.Ix がderiveできます。この手の話題で Ix はよく見落とされます。ちゅうか Haskell 2010 Language Report, Chapter 11 のderive可能なクラスの一覧からもオミットされている……。 GHC拡張を有効にすることで、他のいくつかのクラスでも

この記事では、Haskellの型クラスの互換性にまつわる問題と、それに対する緩和策を考える。 ネタとしては11月に行われた Haskell Day 2019 のLTで筆者が話したものである。その時使ったスライドは https://drive.google.com/file/d/1YGKjl8S-LlfuB8yrHnKSK5G5MGsP9xd3/view?usp=sharing で読める。 問題 Haskell標準の型クラス階層には時折、破壊的変更が加えられてきた。代表的なものをいくつか挙げる： Applicative-Monad Proposal: ApplicativeクラスをMonadのスーパークラスにする Semigroup-Monoid Proposal: SemigroupクラスをMonoidクラスのスーパークラスにする MonadFail Proposal: Monadクラスの

ML系言語は型推論が得意なので基本的には型を書かなくてもコードを書けますが、状況によっては型注釈が必要になります。代表的なML系言語3つ（SML, OCaml, Haskell）について、それぞれ型注釈が必要になる（型注釈がないとコンパイルが通らない）ケースを挙げてみます。 なお、ここでは型システムのみに注目し、評価戦略はどうでもいいので、Haskellも「ML系言語」に含めています。 また、MLのモジュール／ファンクター周りは扱いません。コア言語のみを対象にします。 SML SMLで型注釈をなくすとコンパイルが通らなくなるのは、例えば以下の例です： 組み込み演算子やリテラルのアドホックなオーバーロード レコードを受け取る関数 リテラルの例： val x: IntInf.int = 12345678901234567890123; (* 型注釈を剥ぐとダメ： val x = 1234567

この記事はメモ書きです。 どうも、自分のブログの脱WordPress化を画策しているmod_poppoです。 今日は、WordPressのREST APIを叩いてデータを取ってみたいと思います。APIのマニュアルはこの辺にあり、例えば とすると直近10件くらいの投稿が取得できます。 JSON WordPressのREST APIのレスポンスはJSONで帰ってきます。これをいい感じにHaskellのデータ型にマップしたいです。 最初は自分でデータ型を定義して Generic で FromJSON / ToJSON のインスタンスを定義しようとしたのですが、フィールド名のアレが面倒なのでやめました。代わりに extensible を使います。 extensible を使うと、投稿を表すデータ型が次のように定義できます。各フィールドにアクセスするには Lens と OverloadedLabel

要約 最近[いつ？]のHaskellはSafe CoercionやDerivingVia等が登場し、newtype活用の機運が高まっている。 ところで、高性能なHaskellコードを書くには Data.Vector.Unboxed や Data.Array.Unboxed にあるようなunboxed vector / unboxed arrayの活用が不可欠だが、これらはnewtypeとの相性が悪いという問題を抱えている。 そこで、newtypeフレンドリーなunboxed vectorのライブラリーを作成した。 https://github.com/minoki/unboxing-vector https://hackage.haskell.org/package/unboxing-vector 実態としてはunboxed vectorなのだが、ライブラリーの名前を unboxed-ve

HaskellでOrdインスタンスを手書きする場合の小技を紹介する。 辞書式順序と Ordering 複数のフィールドに対して辞書式比較したい時は、 <> を使うと良い。 例： data Foo = A Int Double Int instance Ord Foo where compare (A x y z) (A x' y' z') = compare x x' <> compare y y' <> compare z z' <> は半群やモノイドの「くっつける」演算子である。最近のGHCでは <> はPreludeからエクスポートされているが、それ以前のGHCでは Data.Semigroup か Data.Monoid をimportする必要がある。 なぜこれでうまくいくのかについては、ググれば出てくる気がするのでそっちを参照。 半群やモノイドについて詳しく知りたい方は、筆者の書

C言語やC++にはインラインアセンブリやintrinsics（組み込み関数）があり、最近のCPUで追加された命令を活用したコードを簡単に書くことができます。 一方、Haskell (GHC) にはそのような仕組みはありません1。しかしそれで諦めるのは早い。なんとかしてHaskellからインラインアセンブリっぽいことをしてみましょう。 筆者の環境はx86_64なMacで動かしているGHC 8.6.5です。他の環境では状況が異なる可能性があります。C言語の処理系はClangを使いますが、GCCでも多分同じです。 題材：64ビット整数の積の上位と下位 2つの64ビット整数の積を計算し、上位64ビットと下位64ビット（合わせて128ビット）をそれぞれ計算することを考えます。 C言語やHaskellにあるような通常の乗算 (*) :: Word64 -> Word64 -> Word64 では下位6