C++用のGoogle Testのパッケージ読み込みに失敗する話[GoogleTestExtensionOptionsPage]

状況

C++でテストがやりたくなって良い感じのものを探したら以下のページが見つかりました。
Visual Studio で C++ 用の Google Test を使用する方法 | Microsoft Docs
実際に試したところ、Visual Studio Community 2017 15.6.2で Test Adapter for Google Test をインストールしても先ほどのページのようにはなりませんでした。
そこで、ツール/オプション/Test Adapter for Google Testを開くと以下のようになっていました。
f:id:nasatame:20180316090858p:plain
また、C:\Users\****\AppData\Roaming\Microsoft\VisualStudio\15.0_2319ee8b\ActivityLog.Setup.xmlを確認したところ、以下のようにエラーを吐いていました。
f:id:nasatame:20180316090903p:plain

原因

英語以外の環境では、このパッケージは上手く動作しないらしい。
出典:Google test adapter does not work when the UI of Visual Studio is non english · Issue #121 · Microsoft/TestAdapterForGoogleTest · GitHub

(エラーを吐いているのが、[GoogleTestExtensionOptionsPage]なのでこのオプションページが日本語化されてないのが原因のような、、、)

解決方法

一時的解決方法

1.Visual Studio インストーラーから、変更の中に言語パックが含まれているのでそこから英語をダウンロードします。
2.言語を英語に変更します。
(ツール/オプション/環境/国際対応の設定)
[国際対応の設定] ([オプション] ダイアログ ボックス - [環境])
3.インストーラーから Test Adapter for Google Testをアンインストールしてインストールしなおします。

永久的解決方法

公式が対応してくれるのを待ちます。
この記事を書いたのが2018年3月16日なのですが、19日前にissueがあがっていたのでさすがに次のバージョンアップでは改善されていると思います。
(願望)

Game Programming Patternsをよんで【Siv3D機能と対比しながら】

Game Programming Patterns 感想

 あくまで個人的な意見です。

総評

 ゲームプログラミング特にデザインパターンについて、著者の長年の経験から得た知識を元に使い時、使用方法、実装、ヒントなどについてとてもよくまとめられていたと思う。
 ゲームプログラミングによく使用するデザインパターンについて全体像を知りたいと思う人にはとてもお勧めだと思う。
 PC、専用ハード問わず使用できる知識についてかかれていたのが印象的だった。
 内部の実装については、C++で書かれていたがあくまで細かい部分にこだわることなく、クラス相互の関係などを分かりやすくまとめるためにコードを使用していたため、C++の知識がなくても読める内容になっていたと思う。
 4000円だして買う価値がある本。ただし、高いので図書館などにあるならそれでとりあえずはいい、積み本があるならまずそれをどうにかしたほうがいいかもしれません。(ちなみに私は、蟻本、チーター本、TLE(ヅ)本、応用情報技術者教本をつんでいます。)

注意

 ここに登場するコードは基本、C++&Siv3Dです。結構ポインタが出てきます。少し前の私のようにポインタは即危険という人間もいるはずですが、それならunique_ptr,optionalを使いましょう。しかし、この本をよんでからポインタは危険だけど便利だなとも思い始めました。

章ごとのまとめ(メモ)

 印象に残ったことをまとめます。
 かなり自分流に解釈しているため、実際の内容とは乖離していることが多々あります。

Part01

イントロダクション
良い設計とは、
1、部分的な変更が全体に影響を及ぼさないようになっている。(分離)
=>これにより同時に考えることをすくなくできる。
=>設計にかける労力は、必ず回収できる程度にしておく。(ライブラリ、エンジンにこだわりすぎて何を作りたかったのか忘れている開発者は多い)
2、コードの抽象化、実行速度、変更可能性
=>部分的に対立したこの3つのバランスが取れている。(抽象化しすぎると、実行速度が落ちて、実行速度を優先しすぎると変更しずらくなる)
3、完璧な正解はない=>数々の誤答があるだけ
4、迷ったら、吟味された単純なコードにしておけば良い。

Part02

コマンド。Command
入力に関するパターン。
if(Input::KeyA.clicked);
if(Input::KeyB.clicked);
だれでも書いたことがあるはず。
これを、
Command* command = handler.input();
if(command){
command->execute(actor);
}
とすれば全てhandlerに隠蔽できる。
input(){
if(Input::KeyA.clicked)return buttonA;
if(Input::KeyB.clicked)return buttonB;
return NULL;
}
class buttonA : public Command{
virtual void execute(Actor actor) { actor.jamp() };
}
冗長だよね。そう冗長、きちんと抽象化(隠蔽)する価値があるのか考えないといけない。
ちなみにこれはすぐexecuteしているけど。queueに積めば、まとめて実行するとか。
stackに積めば、
1、なにがいつ実行されたか分かる
2、わかるから打ち消しの動作(戻る)が実装できる。現在の実行状況を表すフラグを戻せば良い
3、その打ち消しを打ち消し(再実行)が実装出来る。同、進めれば良い
とかいろいろメリットを享受できる。

Part03

フライウェイト。Flyweight
まんま、Assetです。Ryoさんありがとうございます。
ゲーム内で、重くて(画像など)使いまわせるデータをクラスごとに持たせる必要はないよね。
ただ、Assetの問題は、いろいろなところからアクセスできるのでどこで書き換え(Register)られたかがわからないところ。
これは、どこからでも読めるようにした弊害。プログラマーが気をつけなければいけないから初心者使うなというのも納得。(特に並列プログラミングの際)
これは、FlyweightではなくSingletonの問題です。

Part04

オブザーバー。Observer
監視者。
業績の達成などに便利。コードのいろいろなところ、(肉を焼くところ)(魚をとるところ)(移動処理)などに業績達成チェックなんていちいち入れてられないとおもったら使いどころかも。
class Observer{
virtual void onNotify(Event event) = 0;
}

class Subject{
vector observers;
}

class ItemBox : Subject {
void enterItem(){
//アイテムを入れたときそれをobserverに送信。
}
}

class Achievements : public Observer {
virtual void onNotify(Event event){
//アイテムボックスに何が入ったかを入手しはじめてのものなら実績を解法。
}
}

これも、使いどころには気をつけよう。C#にはデフォルトで似たような機能があるらしい。Siv3Dでは、UIまわりに使っていそう。

Part05

プロトタイプ。Prototype
たくさんの種類の敵を各種類大量に用意するとき使う。
RPGで使いそう。
jsonで定義した敵データを読み込んで、クラス化とかもできるっぽい。

Part06

Singleton
まともにみえるグローバル変数
グローバル変数を多用しちゃいけない理由はみんなご存知。
どうしても使いたいときはSingletonより。
static変数を使うのもありかも。(定義が簡単なため)
利点、インスタンスの生成を遅延できる。

Part07

ステート。State
有限状態機械、プッシュダウンオートマトン
AIでつかう。上の二つでググレばOK.

Part08

ダブルバッファ。
みんな大好き。
MY豆知識。コンソールウインドウでやるとコンソールウインドウでテ○リス、イン○ーダーゲーム、パッ○マンぐらいは作れる。色も頑張ればつけれる。
丸ごと入れ替えるのと、ポインタ使う方法がある。

Part09

ゲームループ。GameLoop
System::Update()。Ryoさん本当にありがとうございました。
何が凄いって、60FPSに自動でなること。(FPSは各自ググル)
ならないなら重い。(フレームごとに移動量を設定すると環境によってゲームが動作を変える地獄へ)


自作でゲームループを作るときに60FPSならないときは、対処法が3パターンある。
1、あきらめる。(そういうもんだ仕様)
2、60FPSにするために、遅延時間を調節する。
3、フレーム依存のコードから秒数依存にする。(windowsはタイマーが正確に取れないため、5msほど誤差がでる。オススメしない)

Part10

更新メソッド。UpdateMethod
HamFrameWorkのSceneManager。
updateとdrawがある。以上。

Part11

バイトコード。ByteCode
キャラクターや魔法、ゲーム要素の振る舞いをコードではなく外部に書き込みそれを読み込む。
ミニインタプリタ言語を自作して、それでゲーム要素の振る舞いを書く。
利点、(敵キャラクターを例にとって)
攻撃、魔法攻撃、回復。などと振る舞いを別ファイルに書いただけでゲーム内のキャラクターの振る舞いが変わるとコードをいちいちコンパイルしたりデバッグする手間がない。
欠点。
~~以下なら、以上ならとか複雑な振る舞いを表現しずらい。
かといって、表現しやすくするとセキュリティーホールになりかねない。(例えばメモリをいじれるようにしてしまったら。悪意のある誰かに振る舞いファイルを置き換えられたら恐怖)
凝ると一気に複雑化、よく考えよう。

Part12

サブクラスサンドボックス。Subclass Sandbox
データ書き換え、描画、ユーティリティ関数を全て用意したクラスを準備してprivateにして、そのクラスを継承して使えば外部のクラスからいろいろ機能を変な風に使われなくなる。(グローバール関数よりまし)
問題、全てそろえたそのクラスのとり回しが悪すぎる。分離もクソもない。

Part13

型オブジェクト。Type Object
継承機能の代替。
継承の変わりに、クラスをメンバとして持つ。
メンバのクラスは、関数の参照などを入れておけるクラス。
独自に継承などの機能に変わる機能を作ったりとかもできる。
継承を使わずに、関数の変更などを”動的”に出来る。動的に重要。
利点
継承は、コードの依存関係を強くするため。この方法の方がとり回しがいい事もある。つよい柔軟性がある。
欠点
使い道が分からない。(自身の力量不足)

Part14

コンポーネント。Component
これ重要。今ナウい。いろんなゲームエンジンで使ってるし、波がきてる。Unityね。
ぜひ、コンポーネント指向で調べてみて。
class GameObject{
private:
InputComponent* input;
PhysicsComponent* physics;
GraphicsComponent* graphics;
}
class Hero : public GameObject{
}
class Enemy : public GameObject{
}
ゲームのオブジェクトはただの箱。
そこに接続されたコンポーネントで無限の可能性と取り回し。
コンポーネント共有もOK。
端的に言って凄い。

Part15

イベントキュー。EventQueue
うっ、、WinAPI。悪夢が
ゲーム内のイベントを(敵が死んだ、何を入手など)queueにいれていって。
それを、だれが受け取って処理するかは関係ない。
敵が死んだのは、グラフィッククラスが受け取るかもしれないし。
入手は、アイテムボックスクラスが受け取るかもしれない。
どこに送るかは知らなくて入れていけばいいだけ。

Part16

サービスロケーター。ServiceLocator
リクエストを送ると(サウンドクラス頂戴など)、サービスを行うクラスのポインタを返してくれる。
利点、
実装の分離。(面倒なだけではと思うあなた)
デバッグ時などには、NULLを渡しておけば簡単にそのサービスが動かなかったときのテストが出来たり。
デバッグ時サウンドクラスを呼ばれたときにNULLを返すようにしておけば単調な音楽を聴かされなくて済む。(音量0、イヤホンipodでいいのでは)

Part17

データ局所化。
いままではなんだったんだ、裏切られた。
ポインタは実行効率を悪くする。
ポインタの先をたどらなければいけないから。
0->1->2->3->4->5>6->7
とすると、メモリ中(主記憶領域はレジスタより100倍遅い)
を飛び回るのでよくない。
更にいうなら、継承や仮想関数もよくない。
更に言うなら、クラスも、クラス関数のポインタだからよくない。
、、、
本もいってる、”必要がなければ気にするな。時間の無駄”
配列は順々に並んでいるため、実行効率が高いらしい

Part18

ダーティフラグ。Dirty Flag
Dirty Byteは響きがよくないらしい?
計算結果のキャッシュ。
!!!!!みんな大好きDP(動的計画法)!!!!!!
を、フラグを持たせて管理しようという話らしい。
親フラグが立ってたら相対的に存在する場合子供も再計算される。
child |= parent。ハイ。
相対位置座標などに便利。

Part19

オブジェクトプール。ObjectPool
ガベージコレクタがない環境で。
自作、メモリ管理の方法。
メモリのフラグメンテーションを防げる。
データ局所化と似たような効果。

Part20

空間分割。Spatial Partition
格子=>1次元ではバケットソート
四分木(八分木)=>1次元ではトライ木
以下、1次元では2分探索木らしい。
BSP(バイナリ空間分割)
k-d木
バウンディング・ボリューム・ハイアラーキー
でググレ。正直読み飛ばした。(分からん)

総合的には、理解度30%ですかね。
まあ、メモとして残しておきます。

高専プロコン2017 備忘録

高専プロコン2017

序文

競技部門7位、特別賞いただきました。

 このたび、時間にやっと余裕が出来たので2ヶ月遅れとはなりますが、感想を書こうと思い立ち、こうしています。

 今年で私は高専プロコン3年目となります。
 思えば入学当初からいろいろありました。
 1年生では、高専プロコン開発メンバーに入れていただいて、何したらいいのかさっぱりなので「うーん、先輩お願いしマース。」ってしてたら、いざ1ヶ月前になったら先輩がドタキャンしたり。しかも、新幹線取ってなかったり。
 思えば1年生の夏前ごろでしたね、K先輩と出会ったのもあの時はここまで長い付き合いになるとは思ってもいませんでした。(実は当初同学年だと思ってたり、)
 1年生の高専プロコンは、前日夜にバグが見つかってなきながらデバッグしてました。
 そんなこんながありながらも、2年生でもまたやろうとおもったのは奇跡でしたね。
 それもこれも、K先輩がいたとか、悔しかったとか、いろいろあったせいでしたね。

 2年生では、夏休み朝から晩まで一緒に開発したり、K先輩と一緒にPCK本選行ったり、あの人のコミュ力爆発にはいつもおどろかされました。
 けど、結局あまりいい終わり方が出来なかったのはあの人力パズコンが悪かったんでしょう。
 (ちなみにこの年私はJOI無事落ち)

 さて、前前置きも長くなりました。

3年生

 今年は、去年の計画不足という反省を踏まえ

f:id:nasatame:20171203003836p:plain

 なんて物をつくったりしましたが、後輩にわざわざ、作業に煩雑さを増やすんじゃないとかおこられたりしちゃいました。
 ほかにもメンバーとぶつかったりもしました。来年は後輩に多めに仕事(マネージャー)をふってみようかななんてね。

 5月、設計

 6月、設計、基本の実装。回転関数など、後テストだったのであまり活動できませんでした。

 7月、個人的にコーディング、ビームサーチ、チョクダイサーチの勉強をしてました。またもやテスト。

 8月、夏休み(2ヶ月間)です。これを生かして全力でコーディングしました。1日200行ぐらい書いてましたね。それでも学校に集まらなくなって、連絡が疎になったせいかあまり、すすみませんでした。今年もK先輩と1週間ほど二人で6時間コーディング。クーラーがあったおかげで干からびずに済みました。来年も欲しいです。K先輩はその後インターン

 9月前半、PCK予選で2週間ほど開発をお休みしました。結構でかかったですね。ただでさえ予定が遅れに遅れまくってたので。
PCK終わった次の日からまたK先輩とコーディング、でも課題で忙しそう。なんとか一通りの機能は実装し終わって、高速化、省メモリ化に移れました。(8月中には移ってるはずだったのに)。

 9月後半、学校も始まりまして、コーディングもあまり出来なくなりました。しかし、時間は待ってくれないわけで時間を見つけては書いてました。その結果、なんとか高速化、省メモリ化も一段落しました。(バグはある)
 ソースリスト提出。まじめにやりましょう。入賞するのにとても重要です。

 10月前半、バグは再現性、頻度ともに低かったので無視して、評価関数と列挙関数を作りまくって後は練習してました。

 本選前日、急に配置情報を使えたほうがいい気分になってきて、配置情報に関する機能を新幹線の中1日で実装。(いままでは使っても減点でまけるだろうから、使わない方針でした。)ハードコーディングでした。

 深夜先輩の評価関数の調整中に神が舞い降りてきました。「列挙関数良いとこどりをしたらもっとよくなるんじゃない」と、そこで良いとこどりする関数を製作しましたところ、大成功。実質本番はこれだけでいけました。

 本選1日目、運よくアンチパターンである灯台の問題を避けることが出来たので、決勝トーナメントに進出することができました。K先輩、K君パズルが上手い。

 本選2日目、準決勝またもや当たりがよく30秒で解き切り、並べるのに3分かかりました。思えばここら辺から予兆はあったのかもしれません。

 勝戦。ソルバーの調子がよくまたもや30秒回答、並べ始めます、、、あれ、1,2,3,4,5みんな完成させていくぞ、、、完成には6分ほどを要しました。
 人力ゲーとはいいません。人力部分の工夫が足りませんでした。
 ときには”プログラム以外の部分も重要”、覚えておかなければいけないことです。

 でもなんとか、審査員特別賞を頂きました。三年間の集大成なのかななんてね。ちょっとなきそうでした。(そして先生、なぜ写真撮影のタイミングでタバコを吸いに行ってますか。)
 
 先生にステーキを振舞っていただきました。おいしかったです。K先輩よく食べるなあ。

 ちなみに初日、ふにゃさんとその後輩と一緒にご飯食べたり、最終日も深夜一緒にお話したりいろいろありました。たのしかったです。

 名刺、滅茶苦茶交換しました。けど、企業名刺ではないのでコンテストは不参加。

 私は楽しんでました。一緒にいった二人も楽しんでくれていたらそれを超えることはありません。

本題に入ります。ソルバー公開します。

 
 今回作ったソルバー公開することにしました。
 2ヶ月もありましたが、やっつけで作った当時のままなのでまあそれっぽい雰囲気があっていい。ということにして置いてください。(一応コメントは付け足しました。)
 正直参考になるかは怪しいところですが、この文章とあわせて何かを受け取ってくれたらうれしいです。

開始時
f:id:nasatame:20171203010554p:plain

終了時
f:id:nasatame:20171203010546p:plain

 基本的には、人間の目で探索状況をGUIにより把握しながら、探索手法、列挙関数、評価関数を付け替えて探索をすすめて解に近づいていくというのが基本方針でした。

 参考までにそれぞれの主な手法
 探索手法は、chokudaiサーチ、ビームサーチ
 列挙関数は、辺、角度
 評価関数は、ピースの接した辺の長さ、割合
 
動画
決勝1年生勧誘用.mp4 - Google ドライブ

 正直、問題が簡単すぎてGUI、練習をつんだ人間を生かせませんでした。

ソースコードへのリンク
https://bitbucket.org/nasatame/procon2017ofnatori

 ダウンロードのほうから一括でダウンロードできます。もし質問があればぜひtwitterのnasatameのほうまでどうぞなるべく対応させていただきます。

反省

探索中にGUIとまるの嫌だったからスレッドごとに分けたんですが、よく考えずに分けたせいで結合がいたるところに出来たりして気持ち悪くなってしまいました。

(特にポインタ周りがアンスレッドセーフなのにスレッドにぶち込んでる。)

実はバグがあります。バグが発生するのは100回に1回ぐらいで再現性も取れなかったので無視して大会に突っ込んだんですが。多分メモリ周りがやばいんだと思ってます。正直心当たりがありすぎてどうしようという感じです。

命名規則が乱れまくりました。日によって変わってた、ぽいのが怖いです。

いろいろと一人で独断専行しすぎました。結局6割一人で書いてます。やっぱりマネージャー業はむいてません。

反省から来年へ

  1. コミュニケーションを取ろう。#最重要#
  2. 設計をちゃんとやろう。(なるべくクラス図を描く勢いで)
  3. 予定、予想なんか立つか!!というのも分かるけど一応予定ここまでこの日までというのはきちんと決めて守る努力をする。
  4. GUIとSolverを一緒に製作するときは、並列化前提で設計する。

以下できれば

  1. みんなでコーディング規約を決めよう。守ろう。
  2. お互いにコードレビューしよう。
  3. ツールとしてのGitを使おう。(オンラインストレージ化しないようにしよう)

さて、この入賞を良い機会として、講習会+アルゴリズム講習会でうちの部活の今の血脈が脈々と受け継がれていってくれればうれしいです。
(しかし、歴史はそう上手くいかないと語っています。だからこそ全力で努力をしなければ。)

一、仙台高専ソフ研部員として、この駄文を全ての後輩にささげます。

(感想くれたらないて喜びます。質問があったら聞いてね。twitter,nasatame)


来年もK先輩と一緒に高専プロコンに出れたらいいなあ。

PCK2017本選 参加記

PCK本選お疲れ様でした。

結果は、6AC5WAで上位入賞はできませんでした。
しかし、普段はtwitterでしか交流できない競技プログラマーの方と直接お話することができてとてもうれしかったです。

本選中にであった競技プログラマーの皆様。
https://twitter.com/kotatsugame_t/lists/pck2017/members

TLのトップ画が美少女でも、現実が美少女とは限らない

 という衝撃の事実に始まり。友利奈緒のかわいさ、るましのかばんは友利奈緒、実は例のカモノハシハが筆箱だった、こたつがめ氏がShell芸始めるらしい、大富豪は地方ルールがすごい、Platypus氏太鼓の達人がすごく上手い、会津大生滅茶苦茶やさしい(お客様扱いなのでそれはそう)、今年のテレビちゃんはMサイズだった、テレビちゃんはWA投げで3/6でゲットだった、会津購買は3種の神器がそろってる、TLE購買で買ってしまった。などなどとても充実した2日間でした。


 反省として大分はしゃいで自分を見失っていた感じがありました。
 

f:id:nasatame:20171107220849j:plain
ウクーニャさんとツーショットちなみに写真撮影者はbeetさんです。

ずいぶん駆け足になってしまいましたが参加記の方を閉めさせていただきます。
PCK本選で出会った全ての皆様本当にありがとうございました。あの2日間は忘れられないすばらしい時間でした。

しないわけにもいけないので駆け足で問題の解説をします。(実際の解説もかなり駆け足でした。)

1問目

 やるだけ。for,ifがあればなんとかなる。

2問目

 やるだけ。誤差が出ないように気をつける、分かりやすい変数名、double型を使わない。などがあれば特別賞を狙えたらしい。

3問目

 二人の誕生年月日から。二人の年の差の最大を求める問題。うるう年についての解説があるが結局無視して大丈夫だった。if文

4問目

 与えられた数の中から、最大の数を見つける。
 その数の公約数を列挙して、lower_boundする。
 結果を加算して解答。

5問目

 1日3回ご飯を出せる。ご飯を出す時刻を好きに決められる。
 N人のお客さんのそれぞれ朝ごはん、昼ごはん、夜ごはんを受け取れる時間が与えられる。
 3食食べられる、お客さんを最大化しなさい。
 お客さんのご飯を食べ始める時間にだけご飯を出すか試せばいいため、
 N <= 50 から 50*3 = 150 これを3回ご飯を出すため。
 (150 ^ 3) = 約3*10^7となる。
 前処理で、ご飯ごとにそれぞれ24*60=1440でlong long intの配列を作っておき食べれる人のorをとっておけば、andを使うことでO(1)で何人が3食すべて受け取れるか判定できる。
 この解法は、O(3*10^7*32)のため余裕で間に合う。

6問目

 与えられた2次元配列の行と行、列と列を入れ替える処理を行い市松模様を作れるかこたえよ。 
 正直、テストケース作りまくって力技で通したため考察はしていない。
 しかし、解説を聞いた限りだと存在する1の数が決まっている。2種類の列と行しか存在しない。などを使えば簡単に実装できるらしい。

7問目

 正直6問目と同じく運だけで解いた感がある。
 答えが8以下になる。
 3桁以上に分割する場合場合同じ桁数で分割するしか答えが8以下になるパターンは存在しない。など使えばいいらしい。
 2桁以下はDPでがんばる。


 総評、なぜ6ACできたのか謎。気づきがあった。(その割に次の日のARCで2問目をとけずレートを19も溶かした)(行きの仙台売店でCCさくら買ったのが良かったのかもしれない)

pck2017予選個人的感想

PCKお疲れ様でした。

まず結果から、7完3WA。
多分、地域1位なので本選はいけそうとか甘えた考えを持っています。
3つぐらい反省しなきゃいけないところはあったんですが、自分なりの全力は出せたと思います。

反省

紙ライブラリの製作に手間取り学校到着が予選開始15分前になってしまったのが全ての始まりでした。

学校到着時だれもパスワードを把握しておらず、急遽事務局に問い合わせをしました。
すぐさま、担当の先生に対応していただき無事に予選をほぼ時間通り開始できました。


開始後すぐ後輩に投げて1から3問目を埋めてもらいました。
これは、後々考えると凄いいい選択でした。

開始、30分ほどで埋めてくれたのですが私はその間に6問目までの考察を終わらせることが出来ました。

そこから、4問目始点と終点でバグらせて手元でWA。
4、5問目をとき終えたころには開始から1時間たっていました。

そこから、6問目解いたのですがパンケーキの悪夢再び。

実装ミスで2WA。
1WA目は、ぴったり飛ばなきゃいけないものだと思い込んでいた。
2WAは、「現在飛べる距離+現在の位置のトランポリンの飛距離」にしていたのを「現在の位置+現在の位置のトランポリンの飛距離」にしなきゃいけないという凡ミスをやらかしました。

なんとか、30分かけてバグ取り。これにこんなに時間かけたのは一つ目の反省点。

7問目、見てすぐに2列分だけ状態を持ったDPだと分かり解けそうだと飛びつく。これが二つ目の反省点です。

まあ、かなりバグらせながら1時間かけてAC。途中集中力を失いメモ化するのを忘れて提出それによりいらない1WA。
これが3つ目の反省点。

そこから、残り20分になり8問目ぱっとみ解けそうにないのであきらめ。
順意表をながめおやつをたべながら雑談。
7AC3WAに甘んじました。

予選終了後

8いけたじゃんと気づき死にそうな気分に。
https://paiza.io/projects/WI9kkifTHiJPqzvPhZkY5Q

今後の改善点

1・ちゃんと問題文読め。きちんと例外ケースを考えろ。今回気づけたのは奇跡。次はないと思え。
2・解けそうな問題に飛びつくな。ちゃんと問題文一通り見ろ。
3・これ結果にかかわる、でかい!!集中力を失った結果いらない1WA。
番外・パスワード誰も知らないのは笑った。すぐさま対応してくれた事務局ありがとう。

おわりに

 休日出勤して監督くれた先生ありがとうございます。もう、3年目になりますね。私と先輩で始めた試みですが、芽は順調に育ち今後も後輩が続けてくれると思います。ぜひ、非情報系学校が、どこまでいけるか見届けてください。
 パスワードを忘れるという大ポカに対して、すぐさま対応してくれた事務局ありがとうございます。無事遅れることなく参加できました。
 一緒にでてくれた後輩、君がいなかったらそもそも出場できませんでした。しかも、今日のために1日1ACするとか言う苦行までして準備してくれてありがとう。いつも謙遜しているけど、確実に力になっていることは私が保障するのでこのまま頑張ればなんでも出来る。頑張れ。
 最後に、去年、一昨年一緒に出場してくれた先輩ありがとう。今でもいつでもお世話になってます。少しは、迷惑かけないようになろうと頑張ってますからもう少し待ってください。

 本当に最後に私にtwitterでかまってくださる皆さん本当にありがとうございます。私がここまでプログラミングできるようになったのは皆さんのおかげです。もし、本選で結果を残せたらあいつは俺が育てたとか言ってください。まだ、本選いけるかも分かりませんが本選でも全力を尽くします。

次は、高専プロコンです。
高専プロコンまで残り1ヶ月。

進捗やばいですが、

人力GUI誠心誠意製作中です。
人力勢、人力PC勢の本気を見せてやる。今年は、パズコンにはさせないからな!!!待ってろ。

AGC011個人的な反省

遅刻

理由は、これ


f:id:nasatame:20170313144309j:plain


これのせいで20分ほど遅刻して参加しました。

2問解けました。
今回のセットはレート1600位までは、2問早解きででそうだったのでとても残念です。

解説?

A問題

時間Tiに N 人の乗客が到着します.
乗客を待たせる時間をK以下にして、バスの定員がCのとき。
何台バスを出発させる必要がありますか?

という問題でした。

考察としては、バスの出発時間を最大限遅らせるためにはT[i] + Kにバスが出ることにすればいい、ということだけでした。
よって貪欲で解けました。

到着時間をソートした後。(入力はソートされていない)

  • バスには現在何人乗っている。
  • バスは何時に出る。
  • バスは何台出た。

という三つをもって貪欲しました。
新しいバスが必要になる条件は、定員オーバーと前のバスが出たという二つになります。
境界条件が分かりづらいので注意。
Submission #1157617 - AtCoder Grand Contest 011 | AtCoder

B問題

N匹生き物がいて、自分の体の2倍以下まで食べられます(食べた分だけ大きくなる)。最後まで残ることができるのはどのサイズの生き物まででしょうか?

という問題でした。

考察は、自分より小さい生き物は全員食べられる。
自分より小さい生き物を全員食べた上で食べられない生き物がいればそいつ以下の生き物は生き残ることができない。

つまり、生き物の大きさをすべて足していってその2倍よりも大きい生き物がいたらそこを記録するということをするだけです。

これも入力をソートする必要があります。

例3
40 1 30 2 7 20
ソート
1 2 7 20 30 40
足していくと
1 3 10 30 60 100
大きさ3の生き物は7の生き物をたべられないので、そこを記録します。
よってこれは、それよりも大きな4匹の生き物が残れるので答えは4になります。

Submission #1157909 - AtCoder Grand Contest 011 | AtCoder

プログラミング言語Kemonoをより書きやすく。

最近Twitterで、プログラミング言語フレンズ Kemonoという言語があるのを知った。
しかし、Brain f*ckよりタイプ数が多いため自然書きづらくなっている、どうしようか。
ということで書いてみた。

//Form Brain f*ck to Kemono
#include <iostream>
#include <string>
#include <map>
using namespace std;


int main(void){
    
    map<char,string> m;
    
    m['>'] = "たのしー!";
    m['+'] = "たーのしー!";
    m['<'] = "すごーい!";
    m['-'] = "すっごーい!";
    m['['] = "うわー!";
    m[']'] = "わーい! ";
    m['.'] = "なにこれなにこれ!";
    m[','] = "おもしろーい!";
    
    string s;
    cin >> s;
    
    for(int i = 0; i < s.size(); i++) cout << m[s[i]];
    cout << endl;
}

言うまでもないですが、BrainfuckからKemonoに変換するためのプログラムです。

作業時間3分。これを使うと、、、

+++++++++[>+++++++++++<-]>--.+.+.
たーのしー!たーのしー!たーのしー!たーのしー!たーのしー!たーのしー!たーのしー!たーのしー!たーのしー!うわー!たのしー!たーのしー!たーのしー!たーのしー!たーのしー!たーのしー!たーのしー!たーのしー!たーのしー!たーのしー!たーのしー!たーのしー!すごーい!すっごーい!わーい! たのしー!すっごーい!すっごーい!なにこれなにこれ!たーのしー!なにこれなにこれ!たーのしー!なにこれなにこれ!

こうなります。
KemonoはBrain f*ckと同じく、チューリング完全な言語ですから愛があればきっと無限の可能性があるはずです。
最後までありがとうございました。
(アニメ見ないとな。)