Map の代数的構造と差分によるプログラミング

どんどん話が面白くなっているので期待しかない。
5
pokarim @pokarim

dict とか map みたいなやつは、キーが無かったときのデフォルト値必須にしたほうが、きれいっちゃきれいだよね。

2017-07-29 12:09:16
pokarim @pokarim

適切なデフォルト値がなかったときは Option の None をデフォルト値にすればいいし、そしたらどんな値でも Option でくるんで返すメソッドは必要なくなるし、キーの削除もデフォルト値をセットすれば済む。

2017-07-29 12:12:42
pokarim @pokarim

値の更新も、Map 同士の和や差をとる操作があればそれで済む。Map[Hoge, Int] + Map[Hoge, Int] => Map[Hoge, int] みたいなやつが典型的だけど、大抵のデータ型に和や差は自然に定義できる。

2017-07-29 12:17:43
pokarim @pokarim

積みたいな演算を考えるのも面白くて、Set を Map[Hoge, Bool] としてみれば集合の積もとれるし、Map[Hoge, Int] 同士の積は使いみちがなさそうに見えて、多重度付きの二項関係の合成に使えたりする。

2017-07-29 12:37:21
pokarim @pokarim

こういうところに同じようなことが書いてあった、というような情報を教えてもらいたい気持ちで書いてる。わりといつもそうだけど。

2017-07-29 12:39:55
pokarim @pokarim

Map がネストしてるときとか特に便利。ネストした Map でキーの追加削除するの面倒だったりするし。

2017-07-29 23:40:08
pokarim @pokarim

差分の伝播とキャッシュの更新を自動化するというのが主な関心事だけど、差分だけ取り出しても割と面白かった。Map の diff みたいなものは今まであまり考えてなかった。

2017-07-29 23:44:02
pokarim @pokarim

差集合は diff ではないので、集合の diff を扱うには、{+1, 0, -1} みたいな3値型を用意して、Key => {+1, 0, -1} みたいな型の Map を用意すればいい。

2017-07-29 23:54:27
pokarim @pokarim

"FRPの問題点…利点でもあり落とし穴でもあるのは、状態を隠蔽できるというところだ。状態を完全に隠蔽することで組み合わせやすくなる場合もある一方で、一度FRPで構築したものは、状態が隠れているゆえに拡張性が乏しい。" fumieval.hatenablog.com/entry/2017/08/…

2017-08-10 18:55:51
pokarim @pokarim

以前は漠然とデータベースモデルとリアクティブプログラミングの統合みたいなことができないかと考えてたんだけど、データ指向であることと差分の伝播や更新の自動化を両立するというのが重要だということに最近はなりつつある。

2017-08-10 19:14:41
pokarim @pokarim

状態を隠蔽しても上手くいかなくて、可変な状態が悪いわけでもなくて、手続き的な更新のロジックを手書きすることが悪いのだという感じ。

2017-08-10 19:15:53
pokarim @pokarim

RDBMS のようにインデックスを完全に隠蔽したり、関係という単一のデータ構造に限定することは、宣言的であることの必要条件ではないという見解になりつつある。

2017-08-10 19:22:17
pokarim @pokarim

ハッシュマップのようなデータ構造を明に扱っても、RDBMS のようなクエリ最適化を行う余地をつくることはできるし、必要に応じてオプティマイザをオフにしてより具体的に戦略を指定することも同時に可能になる。

2017-08-10 19:27:36
pokarim @pokarim

"Data-Oriented Design (Or Why You Might Be Shooting Yourself in The Foot With OOP)" gamesfromwithin.com/data-oriented-…

2017-08-10 21:40:31
pokarim @pokarim

.empty() のほうが、.size == 0 より抽象度が高い。抽象度をあげれば読みやすくなるとはかぎらないし、覚えることが増えたりもする。でも有利な面も当然ある。

2017-09-14 11:05:51
pokarim @pokarim

値を返すのではなくて、複数回にわけて差分を返していくことでも計算はできる。

2017-10-01 14:55:45
pokarim @pokarim

シンプルな簡約の代わりにこのような評価戦略を使うと、遅延評価でも無限ループに陥ってしまうような再帰的な式からでも値を得られる場合がある。

2017-10-01 15:08:05
pokarim @pokarim

大雑把には、Datalog をゆるくしたようなものだとも見れる。Datalog と同等の記述からは同等の結果が得られて、停止しない式も書けてしまうけれども、論理や集合に限定されない、より普通の汎用プログラミング的な感覚で式が書ける。

2017-10-01 15:12:08
pokarim @pokarim

同等の記述というのは語弊があった。

2017-10-01 15:24:14
pokarim @pokarim

Map[A, Int] は環になる。 B が環ならMap[A, B] も環になるし、Bが群ならMap[A,B] も群になる。Map.withDefaultValue のようなかたちで Mapに任意のデフォルト値を持たせられれば。

2017-10-01 16:27:29
pokarim @pokarim

データ構造がもつ代数的性質を利用するというのは、ほとんど自明なやり方に思えるけども、その割にはあまり事例を見ない気がする。

2017-10-01 16:30:34
pokarim @pokarim

"Abstract algebra for Scala. This code is targeted at building aggregation systems" twitter/algebird github.com/twitter/algebi…

2017-10-01 16:32:07
pokarim @pokarim

二項関係を Map[A, Set[B]] という形で表現すると、二項関係の合成は、Map の積を中心とした演算子の組み合わせで記述できる。

2017-10-01 16:35:35
pokarim @pokarim

多重度付きの二項関係を、Map[A, Map[B, Int]] とすると、その合成が Map[A, Set[B]] の合成とまったく同じ形で記述できるのが面白い(というか便利)

2017-10-01 16:37:09
1 ・・ 4 次へ