2016年12月10日

この記事は、Kawaz Advent Calendar 2016の12/7ぶんです。Kawazのサイト内で公開されている記事と同じものです。

担当の日を勘違いして2日遅刻した。

概要

今年に入って、sapporo.cppの企画においてopenFrameworksという、ゲーム向きなマルチプラットフォームフレームワークを使い始めたのですが、そんなこともあって最近は個人的な制作物にも使い始めるようになった。
ということで、openFrameworksを使っての感想とか気づいたことを紹介するとともに、最近作ったもの「スクロールバー」を紹介する。

経緯をもう少し詳しく

昨年のKawaz Advent CalendarにてオセロAIを作ったという話を書いたのだが、こういったものをGUIで動くようにすればもっと目を引くのでは?ということで作ったのであった。

こちらで、作成した「4目並べ」を公開しています(sapporo.cppとしての制作物です)。sapporocpp/4moku: 4目並べ

使ってみての感想

  • 基本的には、よくありそうなゲーム向けフレームワークという雰囲気。
  • 割と便利だと思ったもの
    • 最小限のフォントが組み込まれている。デバッグ表示したいときとかに便利。
    • 画面表示に限らず、ファイル読み込みとかスレッドといったものに対しても、プラットフォームに依存せずコードを書くためのラッパーが提供されている。ファイルを開くとかのダイアログも提供されていたのだが、非ASCII文字が正常に扱えない(もしかしたらWindowsの場合のみ?)という問題があって利用を断念した。
  • WindowsとAndroidのマルチプラットフォームを対応したかったのですが、そもそもAndroid向けサンプルプログラムのビルドを通すことすらできず断念しました…。なお開発環境としてWindowsのほかUbuntuで試してもだめでした。
    • 結局現在は、Windows向けアプリ制作のために使っています。Visual Studioから使うのがすごく楽なので。(公式サイト内に掲載の手順に従えば簡単に動く)
  • この手のフレームワークではよくあることではありますが、グローバルな状態管理(例:描画色を指定する関数ofSetColorはグローバルに機能する)が多い。
    • 最近罠にはまったのは、ofSetColorが読み込んだ画像の描画にも適用されるということ(例えば、ofSetColorで赤を指定したら、読み込んだ画像を描画する際に赤みがかかる。元の色で表示したければofSetColor(255)を事前に呼んでおかないとならない)。

作ったもの:スクロールバー

openFrameworks向けスクロールバー

openFrameworksにスクロールバーが欲しくなって作った、というもの。
まあWindows APIを呼んで生成してもよかったのだが、他に何かに使えるかもということで自分で作ってみた。作って公開している人が他に見当たらなさそうだったし(いるのかもしれないけど)。

ソースコード/サンプルプログラムはこちら。GitHub - maraigue/ScrollBar4OF

なぜこれを作ったのか

もともとは某音楽ゲームの譜面シミュレータを作りたかったのだが、その過程でスクロールバーがないと操作しにくい、ということで作成することにした。

じゃあ何で某音楽ゲームの譜面シミュレータを作りたかったかというと、「音楽ゲームの難易度表示が妥当か機械学習的に判断したい」という構想があって、それをするためには譜面が入力できないとどうしようもない、という事情があったのである。また、(自分が作ろうとしている件の音楽ゲームについて)そういうツールを作っている人もいなさそうなのでじゃあ作ろうかな、という気持ちもあった。
これはこれで、出来上がったらどこかで記事にします。

実装のポイント
  • 座標計算は工夫した。スクロールバーは縦と横の両方を出せるようにしたかったのだが、その両者でなるべくソースコードを共通化したかったのである。そのため、
    • 縦横のスクロールバーで共通のコードについては、座標計算に縦横という概念を用いず、「スクロールバーの長さ方向の座標」「スクロールバーの幅方向の座標」というものを導入した。
    • 上記の座標と、普通の(画面表示における)縦横の座標を変換するクラスを作り、それをテンプレートの引数に与えることで、縦スクロールバー・横スクロールバーを出せるようにした。
  • 境界条件(取りうる値の最大値/最小値を超過しないか、など)は結構気を使った。
  • スクロールバー内部の状態管理を行う変数が増えてしまうのは、仕方ないとはいえ面倒だった。例えば「現在ツマミをドラッグしている途中である」とか「マウスをクリックしてから押しっぱなしにしている」とか。

(割と)汎用的に作ったつもりなので、openFrameworksで必要な方はもちろん、他のプラットフォームに対する移植もしやすいほうじゃないか…と思っています。



maraigue at 01:58コメント(0)トラックバック(0) 

2016年11月10日

Boost.勉強会 #21 札幌

開催しました。
前回が2014年5月だったので、2年半ぶりです。
今回もまた、北海道外からも多数の参加者がありました。
そして地元の方にとっても、これによってC++に対する意識、意欲が高まってくれていれば幸いです。

まとめとか

発表資料(すでに公開されているもののみ) Boost.勉強会 #21 札幌 - 資料一覧 - connpass

睦月さんがTwitter投稿をまとめてくださってました。Boost.勉強会 #21 札幌 - Togetterまとめ

私の発表

C++1zで標準化が濃厚となったライブラリ「string_view」について話しました。

2012年11月の勉強会で、私が作成したライブラリ「fundoshi.hpp」を紹介したのですが、その後になって同様のライブラリがBoostに入っていたBoost.string_ref)ことを知り、さらに2016年になって次期のC++標準規格「C++1z」(「C++17」とも)で標準化されることが有力となったため、今回紹介することにしたものです。

他の発表を簡単に紹介

ignisさん「Boost.GILではじめる画像修復 & Pythonから利用してみる」
画像修復(例:ところどころが塗りつぶされたような画像について、その部分を検出して本来あったと思われる内容を補完する)の考え方とC++による実装の話。
画像修復の基本的な考え方は、(1)画像がどのように変形させられるかを定式化し、(2)その変形を関数とみたとき、逆関数を求めて適用し画像を復元する、というものになる。ただ逆関数といっても単純に計算できなかったり、一意に値が定まらない場合もあるので、そこはもちろん何らかの対策を考えないとならない。という話がなされた。
Boost.GILでの実装についての話としては、テンプレートを活用することで画像の特性(モノクロなのかカラーなのか、など)を問わない処理が容易に書けること、また私の発表でも示した「ビュー」(文字列なら文字列、画像なら画像の一部を参照するためのクラス)がBoost.GILでも多用されていることなどが説明された。
最後に、C++で書いたコードをPythonから利用するための方法についての話。これまでにもBoost.Pythonというものはあったが、それよりも使いやすい「PyBind11」というものがあり、こちらがいいよ!ということを力説。なお名前の通り、C++11に対応したコンパイラを利用する必要がある。
redboltzさん「CppCon2016 参加報告」「急速に進化するBoost.SML」
前半は、C++の国際会議「CppCon」の参加報告。氏はこれまでにも「C++Now」という別の会議に出たことはあったものの、CppConには今回初めて参加したとのこと。CppConはC++Nowと違って、運営がプロの手によるものであり(C++Nowはコミュニティ的)、仕事の早さなどを感じたとのこと。また今回のCppConでは「ゼロオーバーヘッド抽象化」がちょくちょく扱われていたとのこと。
後半は、Boost.SMLという、コンパイル時に行える状態遷移の表現を記述する(状態遷移の表現を実行時に構築する必要がなく、バイナリに組み込まれるようにできる)ライブラリの紹介。すでにBoost.MSMというものもあったものの、こちらのほうがかなり高速とのこと。ただしC++14に対応したコンパイラが必要である。
なお、この発表に向けてredboltzさんは、Wandbox(ブラウザ上でコードを書いて実行できる)の中の人・めるぽんさんに、Boost.SMLに対応するよう依頼していたとのこと。結果、Wandboxでサンプルコードが動いていた。
Flastさん「Boost.Fusion/Phoenixのメンテナになったのでその記念的ななにか in 札幌」
メインで話されたのは、スレッドやプロセスを抽象化するライブラリについての紹介(なお、Boost.FusionやBoost.Phoenixはそういうライブラリというわけではない)。Boost.Fiber(途中で動きを止めることで複数のFiberにある処理を代わる代わる進めることができる。完全に並列で動かせるわけではない)の紹介、Boost.Process(プロセスの新規起動など)が入るかもしれないという話をされていた。また氏は「(Boost.Hanaが登場したことで)Boost.Fusion終わるのですか?」という質問を受けたとのことで、それに対し「まだサポートは続くよ」ということを話していた。
【LT】hiyohiyoさん「C++でNVMeと(*´Д`)ハァハァ 戯れていたら一年経ってた。」
NVMe(NVM express、ハードドライブを接続する際の物理インターフェイスでSSDにも適した高速規格)について。CrystalDiskMark(ストレージのデータ転送速度測定ソフト)をWindows 10 Appとして公開した話や、他者からもらったコードがDelphiで書かれていて移植に苦戦したため「ステップ実行して挙動を確かめた」という話が。
【LT】egtraさん「Visual C++コンパイラのコードの注釈機能について」
引数に _In_, _Out_ などを付けることで、意図しない挙動が発生する場合に警告を出す機能の紹介。自分で書けないこともないがなかなか大変とのこと。今回は未初期化変数の警告、nullptrの可能性がある値に対する警告、配列の添字に対する警告を出すことについて紹介されていた。


maraigue at 22:57コメント(0)トラックバック(0)イベントプログラミング 

2016年10月26日

札幌に帰省したときに、いくらかガラナ飲料(キリンガラナ)を買って名古屋に戻ったのだが、それが切れて。

たまにコーラを買ったりもしてみたが、どうも満たされない。

で先日、それまでごく数度しか飲んだことがなかったドクターペッパーを店で見かけ買ってみると、これいいな、と感じたのであった。
いい具合の味の複雑さと刺激。今後もたまに買おうかな。
あ、でもまずは11月に帰省するからそのときにガラナ買ってだな。

ということで。

11月5日、札幌行きます。

Boost.勉強会 #21 札幌を開催します。C++を使っている方、ぜひお越しを。

maraigue at 22:40コメント(0)トラックバック(0)随想 

2016年08月11日

今までは30リットル弱のリュックを使っていた。
普段はこれで全然問題ないのだが、最近1泊の旅行というのが増えて、その際にそのリュックでは「パソコンを入れると着替えを入れる余裕がなくなる」という問題があった。そのため別途ショルダーバッグを利用していた。

ということで、パソコン+1〜2泊の着替えが入れられる新しいリュックを購入することに。
いくつか店を回って、よさそうと思って買ったのはここの。
CabinZero
タグには「The suitcase on your back (TM)」(背中にスーツケースを)というコピーが書かれており、公式サイトを見ても旅行利用を想定した大きさ、特に航空機内持ち込みが可能な44リットルのリュックを主力としているとのこと。

このくらいのサイズのリュックはもちろん他にもあるのだが、自分にとっては以下の二つが必須要件だった。
  1. 背中の側に仕切りがある(パソコンを安定して入れられるように)
  2. メインの収納スペースとは別に後ろ側に個別のスペースがあり、それの使い勝手がよい(ポケットティッシュやスマホ充電器等の小物を取り出しやすいように)
店を数店回っていて、そもそもこのくらいのサイズのリュックは登山用などを除くとあまり多くないという印象を受けた。で、上記の要件を満たしているもののうち、機能性とデザインを考慮してこれに決定したのであった。

先日、これを使って8月6日〜7日に東京に行きましたが、リュック一つで済むのは非常に楽でした。
IMAG0003

maraigue at 16:24コメント(0)トラックバック(0)随想 

2016年07月21日

何があったのか

レンタカーでホイールを破損すると本当に面倒なことになります。もともと装着していたホイールと別のものに交換すると、回転が偏るため、長距離運転には困ります。かといって、全部のホイールを交換するにはさらに費用がかさみます。
私はこのトラブルを奈良で起こしてしまい、やむなく旅行を打ち切って名古屋に引き返すことにしました。

経緯

7月16日〜18日の3連休で、レンタカーでの中国地方旅行をすることにし名古屋を出発したのだが、奈良の天理市内で道を間違えてUターンする際、道路の溝にタイヤが脱輪、その拍子でタイヤがパンク。
レンタカー付属のロードサービスに助けにきてもらえはして、そのときにスペアタイヤへの交換はしたのだが、スペアタイヤは長距離運転向けではなく、このままでは名古屋に帰るのも厳しそうという判断に。しかもその際、ホイールが大きく曲がっていることも判明。最悪、名古屋までのレッカーを依頼する可能性も考えた。
とりあえず、ホイールの取り扱いのある店がある近隣の都市ということで大和郡山市まで移動。しかしレンタカーのホイールは純正スチールホイールであり、基本的には取り寄せになるということが判明。さらに困る。しかし2軒目に行った店で、近い仕様でわずかにサイズの違うホイールがあったので、それを付けてもらえることに。とはいえ少しサイズが違うということで、旅行の続行は断念し名古屋に帰ることにした。
レンタカーでこういう事態のため、タイヤ・ホイール代の出費のほか休業補償も支払うことに。日帰りで帰ってきて交通費4万円程度(特にトラブルがなければ1万円程度になるところ)という非常につらい一日になりました。

反省と対応

このときは気持ちの浮つきがあったと思ってます。普段だったら「ここ一度でUターンしきれないかも」とか考えるところで何故かそういう考えにならなかった。今回は単独事故で人身の事故もなかったからよかったけど、もし人身事故や、他の車との接触その他他者の物品の損壊などがあればもっと大変だったわけで。

3月に北海道で運転した際、「このガソリンの量なら何とか次のガソリンスタンドまで行けるかな」という甘い判断でガソリンがなくなりロードサービスを呼んだというのがあり、自分に甘い判断をしてはいけないという反省があったのだが、それが全く生きなかった。

ということで、以下の条件が満たせない限り、自動車の運転は無期限休止します。

  • 明確にタスクが決められないような場合は、交通手段としてレンタカーは選択しない。距離によって公共交通機関ないし自転車で検討する。
  • 当日焦りを生まない程度には気持ちが準備できている。それができなければ直前であってもレンタカーでの旅行は取りやめる。具体的には、
    • 事前に旅行計画の大枠が立っている。長距離運転の場合であれば、少なくとも、どの都市を訪問する予定なのか、おおよその所要時間、もし予定が狂って訪問できない都市がある場合はどうするか、は決めておく。
    • 出発前日も仕事をかなりしないとならないことが見込まれる場合はレンタカーでの旅行は取りやめる。

補足1

上記と重なるのですが、今回気持ちが整理できていなかったのは、仕事が忙しくて準備を整えるのが難しく、にも関わらず旅行しようという計画を実行することを優先してしまったのが原因と考えています。今後は極力、旅行計画が立ってから日取りを決めるようにしたいところです。

補足2

今回行こうとして行けなかった中国地方は、別途列車で訪問することを考えています。また今回途中まで移動した地域(三重県内・奈良県内)についても大した観光ができなかったため、こちらについては上記の条件を満たす状況にてレンタカーで再訪問することを考えています(場所が場所なのでレンタカーでないと観光しにくい)。



maraigue at 23:50コメント(0)トラックバック(0)旅行 

2016年06月30日

※2016.7.22追記:ImageMagickについて追記(使い物にならなかった)

私はこれまで、Windows環境において、MinGW(Windows環境で、Unix系OS向けに書かれたソースコードをコンパイルできるようにする)やMSYS(MinGWによる、Unix系OSでよく用いられるコマンドラインツールをWindowsでも利用可能にしたもの)にお世話になってきた。具体的には、

  • WindowsでRubyを利用するにあたって、C言語で書かれたソースコードをコンパイルする必要のあるライブラリ(gem)を利用する場合、Visual Studioでもできないことはないが、対応していないライブラリが多数あったり、何かと面倒なこともあったりするため、MinGWが使えると便利であった。RubyInstaller for Windowsという、MinGWとの連携が容易なRubyインストーラが公開されていたので、それを利用していた。
  • Windowsでgitを利用するにあたって、MinGWを用いずに作られたものもあったのだが、Linuxなどと操作感が近いほうがよかったため、MSYSgit(現:Git for Windows)を導入していた。

ただ、そのたびに別個にMSYS環境が導入されるというのが面倒になってきて、PATH環境変数もごちゃごちゃしてきた。そこで以前教えてもらった、MSYS2を導入することに。

MSYS2は、単にMinGW(ビルドツール)やMSYS(コマンドラインツール)として使ってもよいのだが、一つの強みはPacmanというパッケージ管理システムが利用可能なこと。これで必要なツールをインストールしてしまえば、ツールごとに個別にMSYS環境を導入するなどの手間は当然不要。
これでひとまず、Rubyとgitをインストールしたほか、ffmpeg(動画変換)とImageMagick(画像変換)もWindows版を個別にインストールしていたものを消してMSYS2(Pacman)でインストールした。

【2016.7.22追記】ImageMagickを使ってみたのですが、まったく機能していないことが判明。例えばJPEG画像に対してidentify(画像情報を取得)を打つと、「no decode delegate for this image format `JPEG'」というエラーメッセージが出てしまう。これはImageMagickがライブラリの所在地を見つけられない場合に出るエラーらしいのだが、MSYS2やpacmanでこれといった対策は見つからなかった。結局、Windows版をインストールし直した。

MSYS2の環境構築はこのあたりが参考になります。

余談

MSYS2には標準でBashが使えるようになっており、またPacmanでインストールすればzshなども利用できる(参考:MSYS2でWindowsにzsh環境を導入する - Qiita)。ただ私は普段は、不都合がない限りコマンドプロンプトで作業をしている。シェルのキーに対する反応がこっちのほうが速いし。
で、なのだが、コマンドプロンプトでもMSYS2で導入したツールはそのまま利用可能なのである。単に環境変数PATHに追加しておけばよい。私の環境だと、C:\msys64\usr\bin, C:\msys64\mingw32\bin, C:\msys64\mingw64\binの三か所を追加している。

20160630-cmd
↑こんな具合に普通に使える



maraigue at 00:19コメント(0)トラックバック(0)コンピュータ全般 

2016年04月26日

一人暮らしをし始めてから1年。
最初、生活における消耗品を「これくらい買って使い切れるだろうか…」とか考えながら買ったり、最小の量のものを買ってもなかなか使い切らなかったりと、状況をまとめてみました。

生活の状況

  • だいたい1日2食を自炊する(平日昼は食堂が主)
  • 1年のうち家で寝た日数:320日くらい(帰省や長期出張などのぶんが減っている)

消費状況

有料の可燃ゴミのゴミ袋(10リットル):3週間くらいに1枚
がさばるゴミはプラスチックゴミとして出せるものが多いため、食品くずやティッシュなどが主なゴミなわけだが、それだけだとそんなに増えない。なお食品くずは、臭いが出ないよう、ゴミ捨て場に出すまでは冷凍庫保管している。
キッチンペーパー:9か月くらいに1ロール
電子レンジで、冷凍の肉やスーパーで買った揚げ物を温める際に敷いている。あってほしいものであるのだが、そこまで頻繁には使わない。
ラップ(22cm×50m):4か月くらいに1本
作り置きしたものを冷蔵庫に入れるのが主。
食器洗剤:6か月に1本
案外減らないと感じたもの1。自炊するので食器だけでなく調理器具を洗うぶんの消費もあるのだが、それでもなかなか減らない。
ボディーソープ、シャンプー(リンスイン):5か月くらいに詰め替え用1袋
案外減らないと感じたもの2。
洗顔フォーム(180ml):1年1か月くらいに1本
案外減らないと感じたもの3。引っ越してすぐに買ったものがもうすぐ使い切りそうというところ。
衣料洗剤(液体):3か月くらいに詰め替え用1袋
これは結構減っていったこともあり、安売りのときにまとめて買うようにした。


maraigue at 23:58コメント(0)トラックバック(0)随想 

2016年04月03日

去る3月19日(土)に、札幌C++勉強会 #11 - connpassを開催しました。

現在、主に運営をしているメンバーが札幌にいない状況ではありますが(私と@ignis_fatuusさん)、二人が時折札幌に戻るときに実施しています。その前の第10回(2015年12月26日)も、二人が帰省するタイミングを狙って計画したものでした。
※なお、「札幌やその周辺に住んでいて、C++勉強会を計画したい!」という方がいましたら歓迎ですのでご一報ください。

私の発表

名古屋に移って研究の内容が大きく変わったわけなのですが、そこで行うようになったことをテーマに話しました。

「関数の最小化」は、中学や高校を含め、数学ではよく出る問題です。これはより一般には「最適化」と呼ばれる問題にあたり、機械学習の分野でもこれは非常に重要な考え方であるという話です。

最近「ビッグデータ」などと呼ばれるように、データがたくさん手に入るようになったことから、それを分析する手段の開発も重要となっています。人間は「事例を見て、行うべき判断などを知る」という「学習」を行いますが、コンピュータ上で手段は違えど「事例を見て、行うべき判断などを知る」ということを行わせる、というのが「機械学習」です。例えば迷惑メールフィルタを作ることを例に取ると、迷惑メールになる条件を人手で記述するのではなく、ユーザの迷惑メール報告をもとに構築するのが機械学習の考え方ということになります。

機械学習の実際の計算においては、手法によって違いはありますが、簡略化して書くと以下のような手順を踏むことになります。

  • 結果(上記の例でいえば「迷惑メールであるか否か」)を表現する関数やデータ構造の形(例えば、「データを x, y としたとき、 p(x, y) = ax + by + c の形で書ける関数」)を決める。
  • 関数 p(x, y) が、すでに持ち合わせているデータ(訓練データという。上記の例でいえば「すでに報告されている迷惑メール」)からどれだけ離れているかを表す関数 f(a, b, c) を作る。
  • f(a, b, c) を最小化するような a, b, c を求め、p(x, y) に適用する。これが「訓練データをもっともよく反映した、結果を表現する関数」となる。

特に機械学習を行うという観点では、その関数 f(a, b, c) の最小化が実際に計算できないのでは、学習結果も得られないことになってしまうため、どんな関数であれば計算が容易なのか判断することは非常に大事です。詳細は資料中で解説していますが、この問題を考えるにあたって重要なキーワードとして、「極小値」や「凸関数」というものがあります。

C++のソースコードも用意しています(github: maraigue/sapporocpp-20160319)。簡単な実装ではありますが、機械学習の簡単な例である線形分類(「男性と女性」など2種類に分けられるデータ点を、2次元なら直線、3次元なら平面…で分ける最良のものを出力する)のサンプルも用意しています。



maraigue at 01:52コメント(0)トラックバック(0)イベントプログラミング 

2016年03月29日

学生時代の研究室所属当時を含めてずっと、職場/研究室にペットボトルのお茶を常備している私。
お茶は普通の緑茶が中心だったのだが、昨年12月ごろから試験的に、ノンカフェインのお茶(具体的な商品名で言えば爽健美茶や十六茶)を飲んでみることにした。

理由は、「最近、お手洗いに行く頻度が多くなったかな?」と感じたため。それだったらノンカフェインのほうがいいのかな?と思い。

結果としては、
  • お手洗いに行く頻度は実際減った。
  • ただ、お茶を飲む量自体が増えた。(カフェインが入っていない→薬理的に気分に影響しにくいから?)
    • 「人工甘味料の入った食べ物を、物足りなくて過剰に食べてしまう」という話を聞いたことがあるが、それに似ているのかも。
  • しかもそのおかげで、胃に空気がたまりやすくなった。
ということで、結局2月下旬ごろから普通の緑茶に戻しました。

いい経験ではあったかなと思います。自分は結構カフェインに依存してるのかも…ってこともわかりましたし。

maraigue at 01:36コメント(0)トラックバック(0)一般随想 

2016年01月16日

DSCN3566x

昨年4月に引っ越してから今までは、譲り受けた冷蔵庫(90リットル)を使っていたのだが、もう少し大きいものがほしくなり、中古家具の店で146リットルの冷蔵庫を購入。

秋から仕事の進みが速くなってきて忙しい時期も増え、
● 買い物に行くのが面倒なので、まとめて買っておきたい
● 何度も調理をするのが面倒なので、何食分か作り置きしたい
ということも多くなってきた。
しかしそれまでの冷蔵庫では、食材を入れておける量についても、作り置きした食事を入れておける量についても、制約が大きいと感じるようになってきた。

これで食事についての手間を和らげて、仕事だったり趣味だったりにもっと力を注げるようにしたい。

maraigue at 21:49コメント(0)トラックバック(0)随想 
livedoor プロフィール
  • ライブドアブログ