yumetodoの旅とプログラミングとかの記録

旅や登山の記録やプログラミング関連の話とかフリーソフト紹介とか

内容メモと感想:【第1回PFLabフォーラム】自動運転からスパコン×Deep Learning、メニーコア×OS、ゲームAI、Xamarinまで豪華な内容盛り沢山！

プログラミング(Other)

タイトルの通り、PFLabフォーラムに行ってきた。

atnd.org

私は新宿税務署でアルバイトをしていて13:00まで新宿に拘束されていたので、加藤真平准教授による自動運転とベンチャー起業のお話は聞けなかった。

盛り上がりに欠けるというだけで呼ばれるちょまどさんと三宅さんぇ・・・

高精度３次元マッピング

自動操縦に必要なもの
  1. 周辺地図の構築
  2. 自分の位置の推定(localization)
  3. 行動計画
  4. Act!
三次元地図

→点群

すでに持っている３次元点群と新たに得た点群を重ね合わせる

How?

  • ICP
    すべての点群について計算→重い
  • NDT
    ボクセル(点群の小規模な部分集合)同士の位置合わせ(平均(傾向)・分散共分散行列(ばらつき))

やったこと

NDTの研究

インクリメンタルな地図登録

全部のボクセルを再計算する必要はないよね

従来のNDT : O(n)：地図の点群数∝地図登録時間
インクリメンタルなNDT: O(1): 地図登録時間は一定

不均一なボクセルの更新

ボクセル内の点群がある程度貯まると、それ以上増えても平均・共分散に影響が少なくなる
→それ計算しなくてもいいよ！
→更新破棄

1msec程度の削減しかできなかった

メモリーキャッシュが壊れそうなアルゴリズムだからまああんま早くならないだろうなぁ。

展望
  • 地図構築をGPUで
  • ボクセルの大きさは不均一でもいい？　# なんかNext HEVCみたい
  • ドローンで地図作ろう

ボクセルの大きさは不均一でもいいというのは、
rigayaの日記兼メモ帳 技研公開 2016
NHK技研でHEVC(今もっともよく使われているh.264の次世代のh.265のこと)の次世代コーデック開発で、 http://blog-imgs-104.fc2.com/r/i/g/rigaya34589/Giken2016_09s.jpg

圧縮の際の分割ブロック制御で似た話があったなぁ。

自動運転データストリーム

うん、私も？？？ってなりながら聞いてた。最後の方になってなんとなくわかったけど。

LiDARデータ: 360度回転画像を1frame
自己位置推定に使われる

→点群に変換

  • 地図とマッチング
  • 地図生成
  • etc

LiDARからRGB画像から抽出した物体までの距離を算出

Bagデータとして(生データ)収集

ーDeep Larningに流し込みにくい

変換ツールが必要やろ！

  • 撮影画像
  • Depth可視化画像

動画+LiDARでブレーキ予測できるか実験

Deep Larning

並列化された畳み込みニューラルネットワークのスケーラビリティに関する研究
→ # とは

ニューラルネットワークの大規模化

  • ResNet: 152層

CNN: 畳み込みニューラルネットワーク

パターン認識に特化

ちょっとこの辺は知識不足なので


この辺をあとで読もうを思っている。

→並列化したらうまく動くの？ # GPUのほうが並列しているのは？

複数データの同時学習

  • Lowering Convlolution
  • 複数CPUでの学習

HTTとOpenMPとMPI

畳み込み層→重い
出力pixelごとに内積計算するから重い
→ Lowering Convlolution
→ 行列化→それは早い→行列生成がメモリーネック・浮動小数点演算→辛い

pipelined Lowering

細分化

特定の条件下でLowering < Pipelined

Lowering： 6倍
pipelined Lowering: +10% boost

マルチノード化で64並列で46倍

メニーコア

大体のCPUはせいぜい4Core

せいぜいみんなCoreは4つでしょ？Intel Xeon Phiなら>64 Core/ 256 threadやで

2g: 2次元メッシュアーキテクチャ

タイル→正方形状にネットワークにつながっている
タイル同士が通信

でも既存のOSじゃだめやろ！
→よろしいならばフルスクラッチだ

まあメモリー管理はOSがやるべき仕事だからわかる。

github.com github.com

スピンロック

並列化するとどんどん遅くなる
→改善アルゴリズム(TTC, HCLH, etc…)多数→検証中

具体的には？
タイル内のロックは低コスト→どんどん使う

展望

高速計算以外でも使わないとアーキテクチャが死ぬ

  • 広帯域IO
  • 低消費電力

人工知能が拓くゲームの未来 - FINAL FANTASY XV が見せる人工知能の世界 -

ゲームAI
→人工知能学会誌読もう

FINAL FANTASY XV

仲間、自然、モンスターがAIで動く

  • ルールベースのAI
  • プレイーやーの意思を読むAI
  • 自分の体の認識

現代は知能革命の時代に入りつつある

かつてはAIはゲームシステム内にあった

現代：

  • メタAI(予定調和)
  • キャラクターAI
  • ナビゲーションAI

が協調

AI量産のために

Luminous AI アーキテクチャを作った→アカデミックと違う

  • Luminous AI Graph
  • Luminous Navigation

単一の意思決定は十分でない
複数の意思決定を組み合わせる

→ロボットに適用

メタAI

体がない

映画監督

仲間同士で強調して動作したい

プレイヤーが寂しくないように

ex.) - プレイヤーや仲間のピンチを助けよ

キャラクターAI
  • 知能(AI graph)
  • 身体(ボディ・レイヤー)
  • アニメーション(AnimGraph)

の3つ

AnimGraphというツールでnode(それぞれモーション)を繋いでモーションのブレンド

環境世界　–{センサー・体}–> 知能世界(思考(認識の形成、意思決定、運動の構成)と記憶)　–{エフェクト・体}–>　環境世界

  • 有限ステートマシン

  • 階層型ステートマシン

  • ステートマシーン

  • behavior tree

→いいとこ取りしたい

ハイブリッド型ノードフォーマット

www.slideshare.net

ステートマシーンのnodeがbehavior tree
逆も然り
Nodeの共有

→組合せ爆発を防ぐ

ナビゲーションAI
  • 地形を解析
  • 目的におおじた点を見つけ出す

目的地までのパスをを計算する

  • ダイクストラ法(同心円探索)
  • A*(スター)法(指向性探索)　→　99%こっち

ナビゲーションメッシュ 地形の情報に合わせて歩ける部分のみ表示

スマートウェイポイント

３次元パス検索

立方体メッシュ(ボクセル化)→焼きなまし法で結合→A*アルゴリズム動かす→立方体のどこを動くか→さらに検索

戦略位置検出システム

自分の能力に合わせてポジショニングするシステム Point Query System

ステアリング
衝突回避
行きたい方向の空間の空きを見る
相互回避

移動モーション解析

  • 止まるときに現在の速度で停止までにかかる時間
  • 旋回性能

よなよなモンスターが頑張ってる

アンビエントAI

街にいる群衆を作る

オブジェクト側に知能を持たせる

キャラクターが近くに行くとキャラクターが操られる

オブジェクト: 情報発信

【会誌発行】人工知能学会誌 Vol. 32 No. 2 (2017/03) – 人工知能学会 (The Japanese Society for Artificial Intelligence) 表紙解説「ファイナルファンタジーXV」

XamarinとMicrosoft Azure

Microsoft社の松屋宣伝担当・・・じゃなかった、テクニカルエバンジェリスト兼マンガ家の千代田まどか（ちょまど）さんの発表です。
特にメモ取る内容ではなかったというかツイート実況してたので以下ツイートまとめ。
ちょまどさんに実際に会うのはこれが初めてでしたが、某友人から「こいつはだめだ」みたいな話を聞いていたのでぶっちゃけそこまで期待してなんていなかったんだからねっ！(ツンデレ

内容的には blogs.msdn.microsoft.com に近い感じ。

な、なるほど？(わかっていない顔

セッションの説明 登壇者紹介

今日話すこと4つ

C#とは

暗黒の進化笑う。しかもその説明があながち間違っていないからあれだ。

私はF#知らない勢なのでfmfmという感じ

おまえらdynamicあるやん、という思い

ここでコンソールアプリケーションの説明で「コマンドプロンプト」という名前をど忘れしたちょまど氏。

C#をどんな言語かを見せるためにライブコーディングが始まりました。

REST API叩けばAsync/Awaitとかも見せられるから題材としては適当だよね。

www.infoq.com

本の虫: C++標準化委員会の文書のレビュー: P0022R1-P0092R1

[PDF] P0057R1: Wording for Coroutines

コルーチンの文面案。変更点は、とうとうキーワードが決定されたこと。co_await, co_yield, co_returnになった。なんだか泥臭い名前だ。しかし、await, yieldなど使えるわけがない。

future<void> g()
{
   std::cout << "processing f" << std::endl ;
   co_await f() ;
   std::cout << "resumed" << std::endl ;
}

うーむ。バイク小屋バイク小屋。

ちょっとここまでの講演に圧倒されて危機感を覚えたちょまどさんが慌てて追加した内容っぽい。

MRのほうがVRより古いって本当か？

Virtual reality - Wikipedia Mixed reality - Wikipedia

見ている感じそういう印象は受けないが・・・。

Xamarinのお話

ここで私の友人がXamarinのバグと戦った話を紹介しておきましょう。

Xamarin.Forms または私は如何にして心配するのをやめてバグを愛するようになったか — 173210's Blog

Xamarinとは

  1. 海
  2. 神奈川県座間市のマスコットキャラクター
  3. 開発環境

ちょまど「名前空間の汚染が激しい」

ざまりん

Visual Studio 2017

Azure

内容的には

blogs.msdn.microsoft.com

のお話。

MBaaS

ここでプロジェクターが唐突に死亡する事件発生

終了

@meitel1014 (阪大勢) @blessingyukiとお話しつつ、ケンタッキーのチキンとミスドのなんかを食べつつして、その後3人で御茶ノ水まで歩いて各々帰りました。

感想

ちょまどさんのいいようではないけど、思ってたよりアカデミックな感じでびっくりした。

Deep Learningの話は予備知識がたりなさすぎて？？？ってなってたけど、3Dマッピングのあたりはなんとなく理解できた。

ゲームAIの話は、AIを考えるのはデザイナーの仕事なんだな、というのに驚いた。まあ結果AIを書くためのツールを作ったという話があったけど、そのツールそのものがかなりの価値があるんじゃないか、という思いだった。

ちょまどさんの発表は・・・、まあせっかくAzureの試用ライセンスもらったので使ってみようかなと思っています。

拡張子とファイルのフォーマット

プログラミング(Other)

strimuer213p.hatenablog.com

先日Twitterでどうにも りーま氏(@strimuer213p)に拡張子とファイルのフォーマットは関係ないということが伝えられなかったので、ちょっと記事にしてみる。

ファイルの種類

まずいろんなファイルを片っ端からバイナリエディタで開いてみて欲しい。 Windowsをお使いならFavBinEdit、Linuxをお使いならGHexなどがいいのではないか。もちろんそんなところで宗教戦争をするつもりはないので、好きなものを使えばいい。
おれはコマンドがいいというなら、odコマンドがUnixにはあるし、GNU拡張のodコマンドはasciiの表示もしてくれる。

hex dump

さて、開いてみてわかる通り、つまるところファイルとはただ単にbyte列の羅列だ。
多くのバイナリエディタは16進数でbyte列を表示してくれるが、別に8進数で表示するもののあるし、単に見た目の問題だ。
つまりすべてのファイルは(厳密には)バイナリファイルだと言える。

これをとりあえず大きく2つに分類する。

テキストファイル

コンピュータで文字を扱うときにどうするかというと、特定のbyte列で文字を表す。文字をその特定のbyte列に直すことを、文字エンコード、と言ったりする。
この変換の規則が(広義での)文字コードである。

広義での、とぼかして書くのには理由があって、実際にはかなりややこしいことになっているのだが、

equj65.net blog.shibayu36.org

それはこの辺のサイトに説明を譲る。本題ではないからだ。

話を戻す。

とにかく、ある一つの文字コードによってエンコードされたbyte列のみで構成させるファイルをテキストファイルと呼ぶ。

(一般的な意味での)バイナリファイル

先ほど、

つまりすべてのファイルは(厳密には)バイナリファイルだと言える。

と書いたが、一般にバイナリファイルと言われて指すものはそうではなく、すべてのファイルからテキストファイルを除いたものである。

テキストファイルの種類

テキストファイルといってもさまざまな種類がある。 どういうことかというと、何らかのルールにしたがって羅列されたテキストファイル、というのがある。

例えばHTMLは、W3Cが定めたHTML規格に則って文字列を記述することで、例えばブラウザでいわゆるWebページを作れる。
Markdownは一応CommonMarkが標準規格としてあって、それにしたがって記述すれば、適当なツールでHTMLに変換できる(GFMはなんなんだという話はさておき)。
xmlは特定のデータ集合をソフトウェア間でやり取りするときに用いられ、xml上でのデータ構造そのものに意味がある。

(一般的な意味での)バイナリファイルの種類

バイナリファイルの形式は千差万別である。 C言語の構造体をそのまま書きだしたものと思ってよく、したがってバイナリファイルを扱うには処理系依存との戦いが開催される(C言語規格書の処理系依存部分との戦いの他に、エンディアン(バイトオーダー)との戦いがある)。多くのバイナリファイルフォーマットはバイトオーダーについて規定している(していないフォーマットはバグっている)。 このポータビリティ(可搬性)の低さと、多くのプログラミング言語で扱いが難しいことから、敬遠されやすい[要出典]。

今日では、データが膨大になりやすい画像・音声・映像、それを格納するコンテナのフォーマットとして利用される傾向にある。

bmpは画像フォーマットの一つで、0x42 0x4dから始まる。

doc/xls/pptはMicrosoft Officeで最もよく利用されていた利用されるファイルフォーマットである。

mp4は一般に映像や音声を格納するコンテナである。mp4そのものは映像フォーマットでも音声フォーマットでもないが、映像圧縮にh.264、音声圧縮にaacを使った(mp4(h.264/aac)と表記することが多い)mp4ファイルが広く流通しすぎた結果、mp4を映像フォーマットと勘違いしている人が多い。

zipはディレクトリ構造をファイルに変換すると同時に圧縮を行うことを想定しているファイルフォーマットである。もっとも圧縮は義務ではなく、複数の圧縮アルゴリズムから選択できる。一般的にはRFC 1951で規格化されたDEFLATEが圧縮アルゴリズムに採用されている。

また忘れてはいけないものとして、実行ファイルもある。Windowsなら.exeという拡張子がついている。

テキストファイルを特定のディレクトリ構造に配置したものをzip圧縮したファイルの種類

上記のようなバイナリファイルは扱いが難しいことから、複数のテキストファイルなどをzipで固めたものを独自のフォーマットとすることも多い。またこうすることで可搬性とデータサイズの小ささを両立しやすい。

こうしたファイルは特定の形式のファイルを特定のディレクトリ構造に配置したものをzipで圧縮していることを要求する。つまりzipファイルの特殊例(部分集合)である。

odt/ods/odp/odb/odg/odfはLibre Officeやその前身のOpenOfficeなどで最もよく利用されているファイルフォーマットである。実はMicrosoft Officeでも取り扱える。OpenDocument Formatと呼ばれ、ISO/IEC 26300などで標準化されている。

docx/xlsx/pptxはOpenDocument Formatに対抗してMicrosoftが開発したファイルフォーマットでMicrosoft Officeで現在もっともよく利用されている。Office Open XMLと呼ばれECMA-376、ISO/IEC 29500:2008で標準化されている。

ただしここで大急ぎで補足しよう。

こう書くとバイナリファイルが2種類あると勘違いする人がいるかもしれないが断じて違う。
そもそも特定のディレクトリ構造をファイルに固めることができるファイルフォーマットはなにもzipだけではない(tarとかとか)。
zipファイルだって(一般的な意味での)バイナリファイルに含まれる。
あえて数式で書けば、zip∈バイナリファイルだ。

ファイルはOSからどのように管理されるか

すこし話が変わる。FAT32とかNTFSとかext4とかという単語を聞いたことがあるだろうか？

私たちは普段ファイルを管理するのにディレクトリ(フォルダー)という概念を使っている。
これを実現しているのがさっき述べたようなディスクファイルシステムだ。

ファイル名や作成日時、更新日時、アクセス権限や、ディスクのどのセクターに書き込まれているかなどといった(例外はある)ことを管理している。

よく聞く拡張子とは、じつは単にファイル名の末尾から最初に現れた.までの文字列を(ただしファイル名の最初の文字が.の場合を除く)そう呼んでいるに過ぎない。

拡張子の役割

じつは何もない。むしろいらない。(大げさ)

しかし、人間がファイルを見てそれがどういう種類のファイルなのか判別するのにどうすればいいのかという問題がある。

バイナリファイルだけだったら、ファイルを解析して各フォーマットに固有なマジックナンバーを探すことで適切に処理ができる。それをパースして見せるソフトウェアがあれば人間はファイルの種類を判別できる。

しかしテキストファイルはそうはいかない。
xmlやhtmlのように冒頭で種類を宣言している場合はともかく、そうでない場合のほうが圧倒的多数である。

またファイルを解析するという作業は一度ファイルを開く必要があり、ディスクファイルシステムを見ればいいだけである拡張子をみる作業よりコストが高い。

そこで拡張子の出番だ。予めファイルの種類に対応する拡張子(かつてはアルファベット3文字程度が多かったが、しょっちゅう被るので最近は.vcxprojのように長いものが多い気がする)を利用者の間で決めておく。例えばWindowsでは実行ファイルはexecuteを省略して.exeを拡張子にするというコンセンサス(合意)がある。

C言語プリプロセッサとテキストファイルと拡張子

C言語を学習している人のために、もう一つ例を見てみよう。

御存知の通り、C言語のソースコードは.c、C言語のヘッダーファイルは.hという拡張子を主に使う。ここで

#include "a.h"

のようなソースコードはC言語を学んだ人なら誰でも書いたことがあるだろうが、

#include "b.c"
#include "table.csv"

とかいうコードを見るととたんに頭がこんがらがる人いる。

これはC言語の入門書や入門サイト、はたまた学校での講義などが悪い。[要出典]

#includeはヘッダーファイルを読み込むときに使う構文ですよ。
ほら、#include <stdio.h>とかくとprintf関数が使えるでしょ？

などという嘘八百を平気で教えている。ひどいことにプリプロセッサが何かという説明すらしていないことも多い。
ハローワールドを教えた直後ならともかく、一通り教えたあとでもそんなことではお話にならないが、学校での講義や入門サイトはおおよそ例外なくそうなってしまう現状にあり[要出典]、入門書でも記述していなかったりする。
(なお独習Cは筆者にとっては残念なことに正しく解説がなされていたように思う)

C/C++にはプリプロセス時、コンパイル時、実行時の3つの世界が存在するが、

#includeとはこの内プリプロセス時にプリプロセッサによって解釈される構文だ。

機能としては、#include文を対象ファイルから消し去り、代わりに#include文で指定されたテキストファイルをその場所にコピペする、と言うものだ。

cpplover.blogspot.jp

[PDF] N4214: A Module System for C++ (Revision 2)

40年前のコピペ技術である#inludeにかわるモジュール機能の提案。

現在、C++が使っているコンパイルとリンクモデルは、C言語から受け継いだものである。各翻訳単位は、他の翻訳単位のことを一切知らずに処理される。翻訳単位を超えるには、名前リンケージ（シンボル名）を使う。名前に対応する定義はひとつだけでなければならない（ODR）。

翻訳単位の外に見える名前である外部名を、手動によるコピペで管理することを防ぐために、我々は40年前の技術である自動コピペ技術、プリプロセッサーによるヘッダーファイルを未だに使っている。これは、コンパイラーからみれば、コピペである。

ヘッダーファイルの中身はマクロによって書き換わってしまうおそれがあり、誤りの元である。

変数や関数の宣言ぐらいしか書かれていなかった昔のC言語ならば、まだ十分に耐えられたのだが、モダンなC++では、ヘッダーファイルには実行されるコードが記述されている。コンパイラーは翻訳単位ごとに重複した内容を処理しなければならず、現代のC++のコンパイル時間の増大の原因になっている。

ただの自動コピペ機能なのだからテキストファイルならなんでも読み込める。まあそのあとコンパイルエラーになるかどうかは別問題であるが、それはコンパイル時のお話だ。

csvのプリプロセス時読み込みはcsvに多少細工をしておくことで

qiita.com

に書いたように意味のあることに使える。

拡張子とソフトウェアの関連付け

Windows

Windowsの場合、拡張子とソフトウェアの関連付けはOSレベルで提供されている。

www.atmarkit.co.jp

もっというとレジストリに関連付け情報が記録されている。

レジストリの直接編集によるファイルの拡張子と関連づけ - Glamenv-Septzen.net

Mac

知らず

Linux

ない。なぜならばユーザーはどうせ適切なコマンドにファイルを渡すのだから。

ただ、GUI操作においては、ダブルクリックしたら適切なソフトが立ち上がらないと不便なので、ファイラーが関連付け機能を提供している。

まとめ

すべてのファイルは厳密にはバイナリファイルと言える。
すべてのファイルはテキストファイルであるかそうでないか(一般的な意味でのバイナリファイル)で分類される。
つまり、一般的な意味でのバイナリファイルとテキストファイルは全てのファイルの部分集合である。
またバイナリファイルと言っても、特にzipファイルは特定のファイルが特定のディレクトリ構造をとる場合の特殊例に名前がついていることがある(ex. xlsx)
zipファイルは一般的な意味でのバイナリファイルの部分集合であり、xlsxファイルはzipファイルの部分集合と言える。

さまざまな角度から拡張子とファイルのフォーマットについて見てきた。それぞれが全く異なるものであることがご理解いただけただろうか？そうであれば幸いだし、そうでなくても調べるきっかけくらいにはなっただろう。

をるふちゃんが懲りずにコミュニティを作ったらしいので参加した

プログラミング(Other)

http://wolf-cpp.hateblo.jp/entry/2017/02/15/004607wolf-cpp.hateblo.jp

ということで、自称Twitterよりきもち情報濃いめのゆるふわコミュニティに参加しました。

https://twitter.com/katainaka0503/status/831796716487733251

C++の会のSlackよりもだいぶゆるふわしている感じです。C++以外にもC#,lisp,ruby,Scala,php,go,python,Haskellなんかのチャンネルが

一応TOPページは

hackmd.io

から。

早速Wiki編集してきた

hackmd.io

追記

SlackとDiscord両方立ち上げるのが面倒なので、Franzというアプリを入れた。
Franz – a free messaging app for Slack, Facebook Messenger, WhatsApp, Telegram and more

唯一の欠点はDiscordの〜〜をプレイ中という機能が使えないことだろうか。
電卓をプレイ中は草。