Apple Silicon MacでのHaskell/GHCの現状・2022年3月編 - Qiita
この記事は 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を使う
Haskell/GHCでの浮動小数点数の扱い - Qiita
Haskell/GHCでの浮動小数点数の扱いを見ていきます。 浮動小数点数特有の落とし穴や、Haskell/GHC特有の落とし穴（バグ）にも若干触れます。 型 Haskell標準で規定されている浮動小数点数型は Float Double CFloat CDouble の4つです。 大抵の環境では、 Float はIEEE binary32（単精度） Double はIEEE binary64（倍精度） CFloat は Float のnewtype CDouble は Double のnewtype と思って良いでしょう。というか、GHCがそうでない環境をサポートしているか疑問です。 リテラル Haskellにももちろん小数リテラルがあります。 Haskellの小数リテラルはオーバーロードされており、 Fractional a => a という型がつきます。つまり、0.1 :: Float
ArmにあるというJavaScript専用命令とは何か、あるいは浮動小数点数を整数に変換する方法について - Qiita
// 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
浮動小数点数の足し算と掛け算は可換か - Qiita
読むのが面倒な人向けの結論：可換です。 「可換です」以外の答えを知りたい人はこの記事を最後まで読んでください。 結合法則と交換法則 実数の足し算や掛け算については結合法則 $x+(y+z)=(x+y)+z$ が成り立ちます。これに対し、浮動小数点数の足し算・掛け算が結合的でないことはとても有名な話です。 例えば、倍精度で (1 + 0x1p-200) + (-1) を計算すると、結合法則が成り立てば答えは 0x1p-200 となるはずですが、実際には 0 が返ってきます。 浮動小数点演算が結合的でないことは有名な話なので、ここではこれ以上詳しくは取りあげません。 一方で、交換法則（可換性）はどうでしょうか？「浮動小数点演算はこういう法則を満たさない！クソ！」みたいな話題で槍玉に上がるのはほとんどの場合結合法則で、交換法則に言及するものはあまり見かけない気がします。 交換法則が成り立つとどう
Haskellのassertを文っぽく使う - Qiita
基本的な使い方 プログラムの潜在的なバグを発見したい時にassertは便利です。Haskell (GHC) にもControl.Exceptionモジュールにassert関数が用意されています。筆者が以前書いた記事 Haskell でのデバッグ手法あれこれ でもちょろっと紹介しました。 Control.Exceptionのassert関数は という型を持ち、第1引数にチェックしたい条件を指定します。最適化が有効な場合（または -fignore-asserts が指定された場合）にはこの関数は第1引数を評価せずに第2引数をそのまま返し、最適化が無効な場合は第1引数が True であることを確認した上で第2引数をそのまま返す、という挙動をします。 他のプログラミング言語ではassertは文として用意されていることが多いかと思いますが、このassertは式として使います。また、assertを含む
浮動小数点数の16進表記 - Qiita
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進表記は浮動小数点数
stylish-haskellをHexFloatLiteralsやNumericUnderscoresに対応させる - Qiita
Qiitaを漁っていたらちょうど似たようなトピックで記事を書いている方がいました： stylish-haskellをBlockArgumentsに対応させる - Qiita stylish-haskellとhaskell-src-extsとGHC拡張について stylish-haskellはhaskell-src-extsというライブラリを使ってHaskellのソースコードをパースしていますが、haskell-src-extsは最新のGHC拡張に対応していません。その結果、最新のGHC拡張を使ったコードにstylish-haskellを適用しようとすると失敗します。筆者が気になったのはHexFloatLiteralsとNumericUnderscoresです。 brittanyなどの、GHCを使ってHaskellコードをパースするフォーマッターに乗り換えるのも一つの手です。しかし、フォーマ
浮動小数点数オタクが AtCoder Beginner Contest 169 のC問題をガチで解説してみる - Qiita
どうも、浮動小数点数オタクの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 位まで与えられる 入力 入力は以下の形式で標準入力から与えられる。
浮動小数点数の min / max - Qiita
多くのプログラミング言語には、「2つ以上の数値が与えられた時、その最小値あるいは最大値」を返す関数 (min / max) が用意されている。入力が整数や有理数であれば難しい話はないのだが、対象が浮動小数点数の場合は厄介な問題が起こる。具体的には、「NaN の扱い」と「0 の符号の扱い」だ。 浮動小数点数の NaN は、皆さんご存知の通り、順序付けられない。NaN が絡む場合の min / max 演算については、「入力に NaN が含まれていたら結果も NaN とする」「NaN を入力の欠落として扱い、NaN でない入力があればそれを返す」などの立場が考えられる。 もっと細かいことを言うと、NaN を返す場合に入力で与えられた NaN を返すか、正規化された NaN を返すかという違いもありうるし、signaling NaN の扱いも議論の余地があるかもしれないが、この記事では細かいこと
リテラルにTypeApplicationsを使えない理由とその対策、あるいはTypeApplicationsの注意点 - Qiita
リテラルにTypeApplicationsを使えない理由とその対策、あるいはTypeApplicationsの注意点Haskellghcghc-extensions 最近のGHCにはTypeApplicationsという拡張があります。これを使うと show @Int 42 というふうに多相関数の型を明示的に指定できます（型適用）。 ところで、Haskellの数値リテラルや、OverloadedStrings拡張下での文字列リテラルはオーバーロードされた型を持ちます。オーバーロードは便利ですが、状況によっては型が曖昧となってしまいます。 曖昧さを解決するには、型を明示すれば良いですね。しかし、通常の型注釈で 42 :: Int とは書けても、型適用を使って 42 @Int とは書けません。 通常の型注釈 :: には、優先順位が低いという問題があります。そのため、例えば「xの3乗」を型の曖昧
Haskellの文字列型：分類と特徴 - Qiita
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の文字列リテラルはGHCでどのようにコンパイルされるか - Qiita
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 のリストです。 これらの
Raspberry PiでAArch64なGHCを動かす - Qiita
2023年の時点で、GHCupはAArch64 Linuxに対応しています。StackはGHCup経由で入ります。詳しくは以下の記事を参照してください： Haskellの環境構築2023 最近のRaspberry Pi（3以降）のCPUのアーキテクチャは64bitのARM (AArch64)である。開発中のHaskellパッケージをAArch64でもテストできると良いので、Raspberry Piを使ってAArch64のHaskell環境を整えてみた。 環境の概要は次の通り： Raspberry Pi 3 Model B Ubuntu Server 18.04.4 LTS aarch64 Stack 2.1.3 GHC 8.8.3 記事タイトルにラズパイを銘打っているが特にラズパイ依存な部分はない（IoTめいたこともしない）ので、Linuxが動く他のAArch64環境でも同様にできると思う
独断と偏見で語るGHCのderiving系拡張 - Qiita
先日の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拡張を有効にすることで、他のいくつかのクラスでも
ML系言語で型注釈が必要なケース - Qiita
ML系言語は型推論が得意なので基本的には型を書かなくてもコードを書けますが、状況によっては型注釈が必要になります。代表的なML系言語3つ（SML, OCaml, Haskell）について、それぞれ型注釈が必要になる（型注釈がないとコンパイルが通らない）ケースを挙げてみます。 なお、ここでは型システムのみに注目し、評価戦略はどうでもいいので、Haskellも「ML系言語」に含めています。 また、MLのモジュール／ファンクター周りは扱いません。コア言語のみを対象にします。 SML SMLで型注釈をなくすとコンパイルが通らなくなるのは、例えば以下の例です： 組み込み演算子やリテラルのアドホックなオーバーロード レコードを受け取る関数 リテラルの例： val x: IntInf.int = 12345678901234567890123; (* 型注釈を剥ぐとダメ： val x = 1234567
HaskellからWordPressのREST APIを叩くメモ - Qiita
この記事はメモ書きです。 どうも、自分のブログの脱WordPress化を画策しているmod_poppoです。 今日は、WordPressのREST APIを叩いてデータを取ってみたいと思います。APIのマニュアルはこの辺にあり、例えば とすると直近10件くらいの投稿が取得できます。 JSON WordPressのREST APIのレスポンスはJSONで帰ってきます。これをいい感じにHaskellのデータ型にマップしたいです。 最初は自分でデータ型を定義して Generic で FromJSON / ToJSON のインスタンスを定義しようとしたのですが、フィールド名のアレが面倒なのでやめました。代わりに extensible を使います。 extensible を使うと、投稿を表すデータ型が次のように定義できます。各フィールドにアクセスするには Lens と OverloadedLabel
unboxing-vectorの紹介：newtypeフレンドリーなunboxed vector - Qiita
要約 最近[いつ？]の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: Monadクラスのこれまでとこれから - Qiita
「return と pure って同じじゃないの？」「Monad クラスの fail って数学的なモナドにはなくない？」 Haskell初心者が引っかかるポイントの一つが、 Monad クラスと Applicative クラスの関係だろう。他にも、 Haskell 2010 の Monad クラスには数学的なモナドと照らし合わせると奇妙な点がいくつかある。 この記事では、近年行われている Monad クラスへの破壊的変更をまとめ、変化の途上にある Monad クラスの理解の一助としたい。 Haskell 2010 での Monad クラスとその問題点 Haskell 2010 Language Report では、 Monad クラスは次のように定義されている： class Monad m where (>>=) :: m a -> (a -> m b) -> m b (>>) :: m
HaskellでOrdインスタンスを書くときの小技3選 - Qiita
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する必要がある。 なぜこれでうまくいくのかについては、ググれば出てくる気がするのでそっちを参照。 半群やモノイドについて詳しく知りたい方は、筆者の書
【低レベルHaskell】Haskell (GHC) でもインラインアセンブリに肉薄したい！ - Qiita
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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
