tech

一発屋サービス「東京極座標」をリリースしました

みなさんは東京の土地勘ありますか? 私は東京で生まれ育ちましたが、未だに赤坂がどこにあるのかいまいちピンと来ません。ただ都心であることは間違いないでしょう。

東京の中心は、言わずもがな、かつての江戸城、現在の皇居です。道路や鉄道は皇居を中心とした同心円状に整備されています。例えば、道路では、環状1~8号線、首都高都心・中央線環状線があります。東京メトロの主要な路線は、東京23区の端から、皇居を半周して、山手線の駅に繋がるような構成になっています。

逆に言えば、皇居は不可侵の場所です。皇居の上を越えていくことはできません。したがって、東京を攻略するには皇居をどっちまわりで抜けていくかを知ることが重要であり、そのためには目的地が皇居からみてどの方角にあるかを知る必要があります。

そこで私はかねてからアイデアがありました。東京はもう住所を廃止して極座標(皇居から見た方角と、皇居からの距離)で表すべきだと。

そしてついに、これを簡単に実現する Web サービスをつくりました!!!

東京極座標 https://tokyopc.azyobuzi.net/

赤坂駅は皇居から 2.08km, -142° の位置にある

このサービスのおかげで、赤坂が皇居の南西2kmにあることがわかりました! このことから、赤坂のお高いイメージは皇居に近いことが影響しており、また普段なぜ縁がない場所かといえば、私は総武線(皇居をの北側を通って東西へ抜ける)沿線の民なので南西方向に行かないからということがわかります。このように東京極座標は、東京攻略を有利にすることができるのです。

続きを読む

クラスタサイズを指定できるk-meansベースのクラスタリング手法を実装した話

あけましておめでとうございます。季節感もなにもないブログですが、修論締切間近の時期に研究で使った技術をまとめようという点は季節感かもしれません。

今回のネタは、クラスタサイズに制約を設けてクラスタリングをしようという話です。

クラスタリングといったら、もっとも代表的な手法は k-means です。 k-means はクラスタ数を事前に指定して、クラスタリングを行います。つまり、 k-means を使うときは、データを k 個に分けたら何か傾向が見えるかもな~という気持ちで使うことになります。このとき、1クラスタに属するデータ数(クラスタサイズ)は、クラスタごとに異なります。

では、クラスタサイズを事前に指定するような方法はないのでしょうか。データが大量にあるので、データを c 個に均等に分割して処理したいな~というときに、どうしたらいいのでしょうか。というわけで今日の論文紹介です。

上が日本語版、下が英語版で、書いてあることは同じです。この論文では、クラスタサイズの基準 K と、クラスタサイズの下限 K\underline{K} 、上限 K\overline{K} を指定すると、クラスタサイズがこの範囲内に収まるようにいい感じにクラスタリングする方法が示されています。英語版では、このアルゴリズムを COCBO と呼んでいるので、この記事でも COCBO と呼んでいこうと思います。

続きを読む

結局ブログをMarkdownで書くことにした話

blog.azyobuzi.net を開設して1年強、メンテナンスも AsciiDoc も面倒になってきて、はてなブログに戻るのもアリだなぁという気持ちが若干発生してきていました。そもそもブログ自体書いてないじゃん。はい。すいません。

AsciiDoc というか Asciidoctor を使うことに思うところがあり、 Gatsby + Asciidoctor.js という構成をやめ、 Markdown + お手製静的サイトジェネレータ という構成に変更したというお話です。

(AsciiDoc から Markdown への移行は9月の頭には完了していましたが、記事を書く余裕がなかったので、今書いています。)

続きを読む

バッファのない PropagatorBlock はつくれないという話

また TPL Dataflow の話です。突然ですが、バッファのない PropagatorBlock って欲しくないですか?

例えば、複数の SourceBlock があって、それをひとつの SourceBlock として返したいとき。

ISourceBlock<T> CreateSource()
{
    IEnumerable<ISourceBlock<T>> sources = /* ... */;

    var resultBlock = new BufferBlock<T>(new DataflowBlockOptions() { BoundedCapacity = 1 });
    foreach (var s in sources) s.LinkTo(resultBlock);

    return resultBlock;
}

どうでしょう? resultBlock は、1件はバッファに持ってしまうので、後段のブロックがどうであれ、ソースからは必ず1件多く取り出されてしまいます。

1件くらいいいじゃない? それは sources 次第でしょう。

というわけで、本題のバッファのない PropagatorBlock が欲しい、ということです。もし resultBlock にバッファがなければ、 CreateSource の戻り値を利用する(リンクする)とき、初めて sources からデータが取り出されます。やりたいですね。

続きを読む

画像可逆圧縮形式 FLIF についてのメモ

FLIF (Free Lossless Image Format) は、実用されている可逆圧縮形式としておそらく現在最強の圧縮手法です。実際、画像圧縮手法に関する最近の研究では、 FLIF が比較対象となることが多いように思われます。このブログ記事では、 FLIF がどのように圧縮を行っているのか、理解できた範囲で記録していきます。

ファイル形式としての特徴は、アルファチャンネル対応、 HDR (サブピクセルが8ビットより大きい) 対応、アニメーション対応と、現代的な画像形式として一般的な構成となっています。

圧縮手法としての特徴は、次の2点が挙げられます。

  1. 色空間 (YCoCg) や画素値の範囲を変換することで、画素間の相関が大きくなり、効率よく符号化できるようにします。
  2. エントロピー符号化に使用する確率分布の使い分け(コンテキスト)を入力画像から決定木の形式で学習します。

FLIF は、すでに ImageMagick で実装されており、すぐに試すことができます。また、コーデックのリファレンス実装は GitHub にあります (FLIF-hub/FLIF)。

なお、現在 FLIF の開発はストップしており、 FLIF の成果は JPEG XL に取り込まれるようです。ただ JPEG XL の説明を読む限り、以上に挙げた特徴とは違っているので、手法としては別物になるのではないかと思っています。

続きを読む

Visual Studio と VSCode どちらでも使える Docker Compose 環境

開発環境を Docker でいい感じにしてくれるやつとして、 Visual Studio では「コンテナー開発ツール」が、 Visual Studio Code には Remote 拡張があります。これらは Dockerfile や docker-compose.yml を用意すると、その中でアプリを動かすことができるやつです。しかし、同じものではないので、挙動はまったく異なります。それぞれメリット、デメリットがあるので、両方使えるとうれしいわけです。そこで、うまいこと両方で使える docker-compose.yml を書いてみようという試みをやっていきます。

続きを読む

ProjectReference にバージョン範囲を指定したい

複数のプロジェクトをひとつのリポジトリで管理するとき、プロジェクト間の参照関係は csproj に <ProjectReference> を書くわけですが、ここで、このプロジェクトを NuGet パッケージ化するときのことを考えます。例えば、 A と B というプロジェクトがあり、 B が A に依存しているとします。このとき B を dotnet pack してできあがるパッケージの A への依存はどのようになるでしょうか? 実際にやってみると、現在の A のバージョン以上という依存関係になります。

ここで、 A の現在のバージョンを 1.0.0 とします。 Semantic Versioning に従っていると考えると、もし 2.0.0 がリリースされたら、破壊的な変更が入っているかもしれません。それでも B から A への依存は 1.0.0 以上で良いのでしょうか? と考えると、「以上」以外の柔軟な依存関係を指定したくなりませんか? というわけで、 <ProjectReference> を使ったプロジェクト間参照で、柔軟なバージョン範囲指定をしたいというのが今回のお話です。

続きを読む

プロトコルから比較する Reactive Streams と TPL Dataflow

以前、いまさら使う TPL Dataflowで紹介した TPL Dataflow は、入力されたデータを並列に処理するプログラムを、ブロックの組み合わせで簡単に記述できるライブラリです。 類似品との比較で述べたように、 TPL Dataflow は、プッシュ型とプル型の両方の性質を持っており、送信者(Producer)が、受信者(Consumer)が処理しきれないほど大量のデータをプッシュしようとするとき、受信者がそのデータの受信を遅延させることで、データフロー内を流れるデータ量を制御します。

一方で、このような、大量のデータや時系列データ(イベント列)を入力し、データフロー内を流れるデータ量を制御しながら、並列にデータを加工する仕組みは、一般的に、特に Java のコミュニティでは Reactive Streams と呼ばれています。 Reactive Streams に用いられるインターフェイスは Java 9 で java.util.concurrent.Flow として標準ライブラリ入りしており、 RxJava や Akka Streams がこのインターフェイスの実装を提供しています(実際には、互換性のため reactive-streams パッケージを通じて実装しています)。

C# においても Reactive Streams は他人事ではなく、 java.util.concurrent.Flow と同様のインターフェイスが Reactive.Streams パッケージとして NuGet で配布されており、標準的なインターフェイスの座を狙っています。また Akka.NET Streams がこのインターフェイスの実装を提供しています。

いずれの方法も、 Reactive Extensions (Rx) 的なプッシュ型に対して、流量制限(back pressure)を導入することで、データ量を制御しています。この記事では、 Reactive Streams と TPL Dataflow をプロトコル(インターフェイスとその実装方法)から比較します。

続きを読む

さよならはてなブログ、こんにちはGatsby

Qiita 騒動で脱 Qiita といって静的サイトジェネレータに向き合うみなさん、こんにちは。私はほとんど Qiita に書いていない、根っからのはてなブログユーザーだったのですが、以前からいくつかの理由で脱はてなブログしたいなぁ~と考えており、本日ついに、自前のブログ基盤ができたので、移行していきたいと思います!

一発目の記事ということで、ブログの要件と、それに合わせてどうツールを選んだのかについて、書き残しておきたいともいます。

追記

AsciiDoc をやめ Markdown に移行しました。

結局ブログをMarkdownで書くことにした話

続きを読む