トップ «前10日分 最新 次10日分» 追記

はじめてのにき

ここの位置付け

2004|11|
2005|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|04|05|06|07|08|09|10|11|12|
2025|01|02|03|04|05|06|07|

ToDo:


2018-07-18

_ ホリエモン

https://r25.jp/article/560392031878166383

そうそう、やっぱホリエモンいい人ぽいよね、と思ったけど、よく考えると割と普通のことばっか書いてあった

映画のジャイアンみたいな…

(17:14)

_ SGEMM

適当に色々走らせてみる。

CPU-avx2-256 50.062899 GFLOPS t=150
CPU-avx2-512 36.600433 GFLOPS t=14
CPU-avx2-1024 41.914810 GFLOPS t=10
CPU-blas-256 245.587644 GFLOPS t=732
CPU-blas-512 359.621543 GFLOPS t=134
CPU-blas-1024 507.372811 GFLOPS t=24
GPU-mine-64 64.069479 GFLOPS t=12221
GPU-mine-256 246.106109 GFLOPS t=734
GPU-mine-1024 137.683075 GFLOPS t=10
GPU-cublas-64 68.099346 GFLOPS t=12989
GPU-cublas-256 1666.332399 GFLOPS t=4967
GPU-cublas-1024 3462.507099 GFLOPS t=162

CPU-avx2 は Haswell 向けになかむらさんの文章見て適当に書いたコード。当時は BLAS とここまで差が無かったと思うし、なんかヘンなので後で見る。

GPU-mine はもっとどうでもいい、本気で適当に書いたもの。おいおいこんな適当なコードで BLAS に勝つんかと思った

GPU 自体は GTX 1060 3GB というやつで、 Pascal 世代らしい。 1152 コアで最大 1.76GHz 。理論は 4TFLOPS らしい?

次は、最近買ったノートPCにて

CPU-avx2-256 37.796423 GFLOPS t=113
CPU-avx2-512 26.427590 GFLOPS t=10
CPU-avx2-1024 36.619350 GFLOPS t=10
CPU-blas-256 4.165613 GFLOPS t=13
CPU-blas-512 4.127086 GFLOPS t=10
CPU-blas-1024 3.944004 GFLOPS t=2
GPU-mine-64 29.070758 GFLOPS t=5545
GPU-mine-256 57.308421 GFLOPS t=172
GPU-mine-1024 20.952593 GFLOPS t=10
GPU-cublas-64 46.641611 GFLOPS t=8897
GPU-cublas-256 505.182081 GFLOPS t=1506
GPU-cublas-1024 1028.495491 GFLOPS t=48

CPU-blas の成績は明らかにおかしい。 GPU は MX150 というやつで、こいつも Pascal 世代らしい。 384 コアで最大 1.04Ghz 。理論(?) 1.127 TFLOPS、かな?

10 万強で 1kg 強の ノート PC で TFLOPS 出てるんだなあ

(22:58)


2018-07-16

_ ffrkメモ

  • 10メア: 75%。ユウナがチェイン、ワッカは2回いかる。オーバーデスが来るので急ぐ
  • 3メア: 66%。ルーネスが石化避け。アルクゥがチェイン
  • キマイラブレイン: ビビは回復せずにトランスさせる。チェイン切れた直後にメンブレ。その後2回目のエッジがヘイスガ解除受けて分身

(09:08)

_ 性犯罪者

https://gqjapan.jp/culture/column/20150730/welcome-to-pariah-ville/page/4

最初はキツいなあ、と思ったけど、バランス取れた感じの、いい記事だなあと思った。

(20:06)


2018-07-15

_ Q#

Codeforces & Microsoft の量子プロコンで触った。

http://codeforces.com/contest/1002/

最後の問題解けなかったのは、サイズ N の配列を返さないといけないところに、 N+1 個返してたからぽかった。残念すぎる。

問題セットはwarmupも含めてすごく良い感じだったと思う。解けないほど難しい問題はなくて、基本的かつ教育的な、僕にとっては「そういえばそんな話があった気もするなあ……」くらいの問題が並んでいる感じ。そういう全部解かれる前提の問題設計だったのか、そもそも量子情報で「あまりよく知られていなくて、量子性を利用していて面白く、十分に難しく、古典でのシミュレーションで実行できる」みたいな条件がそろう問題ってあまりないのか、まあどっちかというと後者なんじゃないかなと思うけど、それにしても基礎的な問題が多かった印象

ただ D1 と E1 の方が量子の面白さを伝える感じなのに対して、 D2 と E2 はひっかけ問題チックなので、イマイチかなあ…と思った。 E2 が時間かけたのにも関わらず解けなかった問題なので、言い訳くさいけど。

Q# は、言語としてもシミュレータを含めた環境としても、なかなかよくできているなあと思った。古典情報と量子情報の往復の部分とかは、そのまんま自力で書く感じ。量子→古典の移動は、観測を伴ってしまうので、まぁ明示的に書かせるのが良いのではないかと思う。あまりトランスペアレントにしたくないかなと。

一方で古典→量子の移動、要するに Qubit の初期化の部分は、これはなんか適当な状態を自由に作る手段があっても良いのかなあ……と思った。アルゴリズム考えてる時とか、「仮にこういう状態が作れるとしたら、こういうアルゴリズムは作れるだろうか?」と考えてから、「実際その状態、作れるの?」と考えたいこともあるんじゃないかなあ、と。シミュレータならいきなりそういう状態で初期化してくれれば良いし、実機では適当に精度指定すると存在するオペレーションでやってみてくれて、合成できない(オペレーション数が多すぎる場合も含めて)場合はエラーにする、とかで良い気がする。

PrepareArbitraryState というライブラリ関数もあるのだけど、 W state 作る問題で使ってみたら遅すぎるようだった。

https://docs.microsoft.com/en-us/qsharp/api/canon/microsoft.quantum.canon.preparearbitrarystate?view=qsharp-preview

(00:50)

_ 就活 起業を嫌いになった理由.pdf

https://drive.google.com/file/d/1QlDRAyAN926YoBuBb9auo4WZdhCyh7fC/view

面白い…

(14:16)

_ 旅館大松

名古屋の宿の近くに、死ね金返せ系の落書きがたくさんある旅館があって怖かった

https://www.instagram.com/explore/tags/%E6%97%85%E9%A4%A8%E5%A4%A7%E6%9D%BE/

こういうの実在するんだな……バキの家みたいって思ったら、2chとかでも同じこと言ってて笑った

(14:20)

_ ノートPCの設定

仕事にも使う予定なので、 Debian は微妙かなあと Ubuntu にすることにして、 16.04 はちょっと微妙問題があったので、 Ubuntu 18.04 でいってみることに

何度もする作業をメモ

最初にすべきこと

scp "i@xxx:.*" .
sudo apt-get install ssh screen zsh
chsh
sudo apt-get install git subversion g++ make gauche ruby python3 python3-pip lv
scp -r i@xxx:bin .
scp -r i@xxx:lib .
zsh
git clone git@github.com:shinh/test.git
svn co $SVN wrk
cd ~/wrk/fake_isatty
sh build.sh

sevilwm

apt -i libxrandr-dev
cd ~/wrk/sevilwm
rsync -avr "i@xxx:wrk/sevilwm/dev" .
make
sudo cp sevilwm /usr/local/bin

w3m

apt -i libgc-dev libimlib2-dev libncurses-dev
scp -r i@xxx:.w3m .
cd ~/wrk
git clone git@github.com:shinh/w3m.git
cd w3m
./configure && m
sudo make install

apt-file

apt -i apt-file
sudo apt-file update

適当に色々。 sevilwm に切り替える準備

apt -i ghc ocaml rlwrap emacs wicd gkrellm xscreensaver feh
apt -i mlterm
scp -r i@xxx:.mlterm .
sudo vi /usr/share/xsessions/custom.desktop
[Desktop Entry]
Name=Custom
Exec=/etc/X11/Xsession

CUDA

apt -i mesa-utils
# follow nvidia's instruction for CUDA...
sudo apt-get install -o Dpkg::Options::="--force-overwrite" cuda-9-0
sudo dpkg -i libcudnn*.deb

MLフレームワーク

pip3 install cupy
# gcc-7 でコンパイル通らんので編集
# sudo vi /usr/local/cuda/targets/x86_64-linux/include/crt/host_config.h
pip3 install cupy
pip3 install chainer
pip3 install tensorflow

UIM SKK

apt -i uim-skk ddskk
uim-pref-gtk3

忘れがちな開発ツールまわりの

apt -i autoconf automake libtool texinfo flex bison glibc-doc libc6-dev:i386 libgcc-7-dev:i386 libstdc++-7-dev:i386 lib32gcc-7-dev valgrind

(20:38)


2018-07-01

_ define-and-run vs define-by-run

  • 前者は TF や Caffe などとされている
  • 後者は Pytorch や Chainer や DyNet などとされている

https://twitter.com/taku910/status/1010082944629727234 などを見てもそうだけど、この用語法が良いかどうかは議論の余地があると思う。

define-by-run が研究時に有利なアプローチなのは間違いないという合意は形成されつつあるようにあると思う。プロダクショナイズ時の整合性の保証と、トレーニング速度の心配が define-by-run で気になることかと思う

プロダクショナイズ

define-and-run はデプロイ時に Python のランタイムが必須でなくなり、また、トレーニング時に使ったモデルが正しく使われている保証が取りやすい。ただし

  • define-by-run であっても、モデルを適切にエクポートする手段があれば、問題なく Python を分離できる。最も強いエクスポートの標準化は ONNX
  • define-and-run であっても、モバイルデバイスや、もっとエッジなところで動かしたい場合、例えば TF の C++ ランタイムですら邪魔なので、いずれにせよエクスポートしないといけない。 tf.Estimator の saved_model から TF lite の流れなど

トレーニング速度

原始的な define-by-run はホスト言語に処理が戻ってくるので、速度が出しにくい。ただ、最適化の余地があって

  • 遅延評価する。 DyNet がこれプラス auto-batching もしてくれるらしい。というか TF の non-XLA なアクセラレータ向けコードパスはそんな感じだと思う
  • モデルを一回走らせた結果を最適化して、何度も実行する。 Pytorch の jit.tracing がそれ
  • 実例無いと思うけど、投機的に次の計算やるって方法もありえるんじゃないかと思っている

model-as-data vs model-as-code

そもそも、速度が出ないのなら、 Python をコンパイルしちゃえばいいという発想もありえる。これは単に Python を C なりアセンブリに変換するという話ではなくて、 Python 内で記述されたハイレベルなオペレーション群をくっつけていって、アクセラレータ内で完結した実行をしてもらう、という話

「Python をコンパイルする」て語感と実体がだいぶ違うアプローチで、感覚としては CUDA に近いものだと説明している。 CUDA だと、 __global__ てついてる関数はデバイスで実行して、ホスト側に main があってそのデバイスの関数を呼んだりする。同じような感じで、 Python の一部の matmul+activation みたいなところを Python じゃないコードでまとめて実行すれば良い

実際やってるのが Pytorch の @script や、そもそも言語まで変えてしまったのが Swift for TensorFlow 。アクセラレータに投げる部分の抽出と、計算グラフの微分をしたいので、 AST なりなんなり、言語処理系にまあまあ手を入れる必要があると思う。

このへんのアプローチは、気持ちとしては define-by-run のまんまだけど、なんか明らかに事前コンパイルしてる以上、 define-and-run の方が適切な呼び名な気がしてしまうので…… Swift for TensorFlow などは model-as-code と言ってるのだと思う

個人的には model-as-code が正しい方向性に思える

機械学習向け言語

話がそれていく。 Swift for TensorFlow みたいな方向性が正しいとして、欲しい/必要と思う機能として

  • 計算グラフの分離
  • 自動微分
  • 静的型チェック(最低でもランク、できれば次元も含めて)
  • Jupytor 的なもの
  • Python の呼び出し

あたりを考えてると、 mypy と tangent で(どちらもよく知らないが)、一応 Python をコンパイルして使う、てのは要件を満たしそうな気もする

「TPU のようなもの」

もっとそれていくけど、なんか雑談してると、 XX が作ってる深層学習向けプロセッサー、みたいなことを言うと、「TPUみたいなやつ?」と聞いてくる人がいたりする。深層学習向けに独自に作る価値がある計算装置として

  • 学習時に使うやつ。 TPUv2 のようなもの。たぶん、メモリが多く必要、レイテンシよりスループット重視、除算などの命令が必要、 GPU がライバル、などの特徴があると思う
  • 推論時にクラウド内で使うやつ。 TPUv1 のようなもの。量子化とかして良いかもしれない。レイテンシ重視。 GPU がライバルになる場合もあるかもしれないけど、むしろ CPU で十分じゃない?的な話が多そう
  • 推論時にモバイルデバイスだのもっと小さいもので使うやつ。 distilation pruning quantization あたりでメモリサイズを限界まで落としたいと思う。これは千差万別だと思うけど、行列のかけ算だけをアクセラレートします、みたいな DSP みたいなやつと、特定用途専用の FPGA/ASIC の回路にしちゃう、って話の2つがおおまかに言うとありそうかなあ

XLA あるいは NNVM

トレーニング中は数日とかかけて、何回も同じ計算をするわけで、その計算は、例えば10分とかじっくり時間をかけて最適化しても割にあう。本質的に Python のオーバヘッドからは既にほぼ無縁な TF のグラフだけど、ターゲット向けにゆっくりコンパイルしてさらに速くする方がより良いでしょ、というのが XLA 。 ONNX を入力としてわいわいやってるのが NNVM

いろいろ話はあるけど、トレーニング向けは益がそんなに大きくないのかなあ、という気はしている。けどある程度の命令数を GPU でないアクセラレータでやるのであれば、なんかしらこういうレイヤのものは必要になるだろうしな

(20:55)


2018-06-27

_ パナマ

https://www3.nhk.or.jp/news/web_tokushu/2018_0627.html

面白い連載だったけど尻すぼみぽい終わりかたをしていた

(15:39)


2018-06-26

_ 六本木の東で絶対に行くべきクールなお店3選

http://shinh.skr.jp/m/?date=20100915#p01

の続き。六本木を出る前に書いておこうかと思った

  • ふるめん(ラーメン): 謎のオリジナリティが強くてすごい。担々麺に柴漬けが入ってる。おいしい
  • オーセンティック(ハンバーガー): 今まで日本で食べたいわゆるグルメバーガーで最強だと思う。材料が全部おいしい。ソースがおいしい。おいしい
  • バンコク(タイ料理): 普通のタイ料理な気がするんだけど、なんだかおいしい。タイカレーとガパオがおいしい。たぶん甘さがおいしい

あと阿部っていう寿司屋が、なんか立派ぽい寿司(偽)が安いので、ランチがお得感がある

(17:32)

_ pythonrc

そういえば、 numpy とか tensorflow とか毎度 import するのめんどくさいなあ、でも repl 起動した時に自動的に import されてしまうのも遅くて不便だなぁ、と思ったので、参照されたら遅延ロードする、ってものを書いてみた

https://github.com/shinh/test/blob/master/pythonrc

便利

PYTHONSTARTUP=$HOME/test/pythonrc exec python3

などとして使う

(18:13)


2018-06-25

_ はてな村殺人事件

http://b.hatena.ne.jp/entry/s/anond.hatelabo.jp/20180624222908

こわすぎる話

もちろん殺人はダメに決まってるけど、はてぶのコメント見てる印象では、趣味で荒らしてるうざい人、て感じじゃなくて、真摯に荒らしてる、たぶん病院に行った方が良かった人、なんだろうかなあ……

ネット上の(自分にとって)間違った言論を全て消すことはできないから、そう努力しても徒労に終わるだけだし、相手がどういう人かあまりわからないし、そもそも間違った言論を全て消すてのもディストピアだし、で、どんな相手だろうとネットで攻撃的な応対する意味とかないなあ、と思う。古い言いつたえだけど「荒らしは放置」て原則は正しいな

(11:03)


2018-06-21

_ VMware, Valgrind, NaCl

昔の VMware はバイナリ書き換えでシステムコール命令をフックしていたという話

Valgrind はメモリの読み書きのフックを全命令エミュレーション+JITで実現

NaCl は SFI では一番成功しかけた例

ではないかと思う。それぞれ、 CPU レベルでの hypervisor サポート、 clang/LLVM レベルでの変更、 hardware isolation で意味ない技術になった

思うにこういう、一レイヤ掘ったところでサポートすればもっと正しい解になるけど、上位レイヤの筋悪技術でも割といけるぜ、てのが好きなんだなぁ…と思う

他でいうと、 C++ TMP の一番論外な部分は D の CTFE なり C++ constexpr で実現された、とか C99 の数学関数は __builtin_classify_type がなくても __typeof__ と const 計算と三項演算子でなんとか実装できるぜ……とかも似たようなものだと思う

教訓としてはちゃんと適切なレイヤ掘れって話だと思うけど、まぁこの手の近視眼的なハックはひどく楽しいんだよな

(04:18)


2018-06-20

_ pytorch jit

https://pytorch.org/2018/05/02/road-to-1.0.html

なにやら trace のやつと @script のやつもう ready になる寸前なんだな。

(01:08)

_ stick xor

tailsさんの解を理解したかったので読んだ。他の人はたぶん山登ったり焼いたりしてる中、貪欲だけで長期間トップに立ってて、最後まで良い成績で異様だったので。最終版はややこしいので、頭角を示しはじめた頃の

https://yukicoder.me/submissions/261010

を。ちゃんと読んでみるとシンプルで、

  • 最初に y 方向に連続した点がなるべく同じ色になるように各列に横向きの棒を置いていって(この時 y 方向上から下に見ていってるので、後で変更の余地がある下向きの色不一致は若干ゆるいペナルティになってる)
  • 次に y,x 順ループであらゆる点から縦方向に棒を置いていくんだけど、この時も、なるべく次置く方向の色を一致するように、かつどちらかというとビットをオフにするように、って置いていく
  • あと余ったの捨てる

とかだけ。言われてみればなるほどなんだけど、これで高得点なのはすごいなあ。最終版では余ったのを捨てない、ループの向きを回転反転の8パターンでやる、2つ目の貪欲のパラメータを適当に変えて時間を使い切る、くらいの差分を見てとった。

うーんすごいな

(17:19)


2018-06-19

_ 転職話

  • グーグルを悪く書かない
  • 他に受けた他社を良く書く

のふたつはゴールだったんだけど

http://shinh.hatenablog.com/entry/2018/06/17/203604

へのブクマとかtwitterとか眺めてると、グーグル < PFN みたいなのが結構あるし、他社については語られないし、なかなか難しい。他社も本当にすごい良さそうだったんだけど、具体的には書かないべきだろうしなぁ。あ、逆に僕が面接受けに行った会社の人はそのへんの情報は自由に共有してもらっていいです。

グーグルへのもう一つのどうしようもない不満というと、どうしても大企業なので one of them になっちゃう、というのがあったけど書いてなかった。あの会社で one of them にならない方法は Jeff Dean になるしかなく、無理ゲー。まあ完全に大企業の安定感とのトレードオフだし、僕は安定指向なのでそっちの方がいいや、て思ってたけど、逆の方もやってみたいな……と隣の芝に行ってみたというような。

その例をとってもそうだけど、当たり前だけど会社間に全順序つかないなぁ、というようなことは何度も思った。

人によってあうあわない、タイミングによってあうあわないあるわけで、グーグルでプロジェクト変える程度に気楽に、小さい会社も含めてジョブホップできるといいなぁ、と思う。そうなるとグーグルジャパンも焦って給料増やすかもしれないし。今までは基本的にグーグルが取っちゃうから他が給料上げてた構図があったと思う。シリコンバレーとかなんかそういう感じで回ってるよね。

11年も一つの会社に行っておいてなんだけど、まあみんなもっと動(く|ける)と良さそうだよね

(15:35)

_ cQASM

https://arxiv.org/abs/1805.09607v1

を斜め読みした。学生の時に鉄板教科書と言われてた Nielsen & Chuang が QASM の導入者、とか見て、おおーと思った。ていうかこれ系のアセンブリ言語みたいなのは、当時も見た気がするから、その当時見たのが Nielsen & Chuang のやつなのかもしれない。

ぱっと見の感想としては、こういうのは時期尚早、各人が適当に「俺のを標準にしようぜ」ってなるんじゃないかなぁ……という感じ。実際、 IBM Q の人たちぽい

https://arxiv.org/abs/1707.03429

の OpenQASM を斜め読みした感じだと、それ以前から cQASM ぽいところ考えてるぽいし、 cQASM の論文で OpenQASM が引用されてるしで、はてさて。

あとコンパイラも乱立しててすごいね。

(15:50)

_ zapcc

https://github.com/yrnkrn/zapcc

goma のライバルだ。この分野(バカパラレルじゃない並列/インクリメンタルビルド)は昔調べた時は死屍累々で

https://gcc.gnu.org/wiki/IncrementalCompiler

ftp://gcc.gnu.org/pub/gcc/summit/2003/GCC%20Compile%20Server.pdf

など

(16:00)

_ おもしろ

https://twitter.com/chinshonatsuyo/status/1008057976911876097

ブームが終わって、採算があって常識的に便利なものは残りつつも、単にブームで湧いただけのものが消えていってる、て話か。そりゃ当然そういうことは起きるよなあ。逆に言うと今後も今くらいの順当な強さをキープするのかね。

あとリプライがそれ以上に(悪い意味で)面白かった

(16:17)

_ ScaffCC

https://github.com/epiqc/ScaffCC

フロントエンド最初から書くんじゃなくて、 clang 魔改造、 lib/Target は完全に無視、ってのに笑った。最適化と IR が欲しいから LLVM やってるのかな?という推測はたぶんあってそう。

いやー荒々しくて良いなあ。コードもいいかんじに雑い(まあLLVMもあれだけど、それ以上に)。僕が LLVM IR => befunge トランスレータ書いた時の感覚に近い。いやこっちの方がちゃんとたくさんコード書いてる(そしてそれが逆に驚き)なのだけれども。

上記の推測の根拠は、当然バックエンドはほぼ使いまわし不能だろうし、既存の言語で量子コンピュータを抽象化しきってしまうと単なる古典コンピュータ用言語になってしまうので、当然かなりの量の魔改造が必要、ということから、 LLVM の使いまわせる部分てどこだ?と思ったことから。 C ライクな文法にして clang を使いまわしてるのは、まぁなるほどではある。 #include とか #define とか普通にやっててわらう。 "Quantum C" みたいな話だな… C 的に見ると大幅にサブセットぽいが

あと面白いなあ、と思ったことは、入力より出力の方がはるかに短いこと。これ高級言語で書く意味あるん??

(20:38)

_ もう少し

  • 量子ぽいゲートはどうなってんの?と思う。大文字ではじまってる H とか CNOT とかがそれで、ビルトイン関数として処理され続けて、最終的に *QASM のオペレーションに落ちる
  • ループは全部展開してるぽい。可変長なループを作ると SEGV した

これ高級言語というよりマクロアセンブラじゃないか

(20:58)

_ On The Turing Completeness of PowerPoint

https://www.youtube.com/watch?v=uNjxe8ShM-8

SIGBOVIK てのがあるのかー。前似たようなの見たけどそれより楽しそう

http://sigbovik.org/

(22:48)


2025年
7月
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31

search / home / index

全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。

shinichiro.hamaji _at_ gmail.com / shinichiro.h