最近見ているYouTubeの話
UEC2 Advent Calendar2021 15日目の記事です。
直近は、13日のpizacさんの記事のはずです。
前提
この記事は、私の好きなYouTubeチャンネルを紹介するだけの記事で何の技術的な要素も、ためになる教訓も含まれません。ただし、YouTubeを見て笑っていると楽しい気持ちになります。
2021年現在の趣味です。割ところころと変化します。判定基準は私が直近１か月で再生した大体の時間です。
ランキング
各チャンネル紹介
1位 EGOIST Official YouTube Channel
EGOISTというアニメソングを中心に手掛けるJPOPグループのチャンネル。基本はryoとchellyのグループ。チャンネル開設自体は4年前だが、ほとんど動画がUPされることがなかった。1か月ほど前からライブ映像やMVが盛んに公開されている。個人的には、CDは持っているが、映像資料を持っていなかったためMVが特にうれしい。chellyのソロ活動が契機となったのか分からないが公式サイトも更新が頻繁になっている。再び活動が活発化してくれると、一ファンとしてとてもうれしい。作業用に流しているためこの順位にランクイン。
2位 趣味のプログラミング
文法と魔法の間（あいだ）をテーマとして、土曜日の午後に配信をしているプログラミング配信チャンネル。最近１周年を迎えたらしい。後述するようながちがちに専門的な内容でもなく、かといってレベルが低すぎるわけでもない自然に聞けるプログラミングのチャンネル。作業中に流していることが多い。最近は、ローグライクのダンジョン攻略ゲームを作ろうと企画してやっている。javascriptが基本で、コードがアップロードされていないため、１から追いかけて自分で書かなければいけないところが少し手間だが勉強になる。書き換えのコードがp5js editorを使用して公開されている。
p5.js Web Editor
3位 洗足学園音楽大学/SENZOKU GAKUEN college of Music
洗足学園音楽大学という日本の私立音楽大学のチャンネル。学生ながらにレベルが高く、様々な分野の音楽関係の資料が集積されている。たまにコンクールやコンサートのLIVE配信もやっており面白い。恥ずかしいことに、20代の中盤に差し掛かろうというのにオペラ、クラシック、バレエに対する教養が一切ないため観劇などに行っても楽しみ切れない自分がいた。時代は生涯教育、大人でも勉強はできるんだと思い立ち、少し時間があるときに作者、年代、背景も検索しながら聞くようにしている。現在は、オペラの笑いどころが理解できるぐらいの教養を身に着けたいと思っている。
4位 Kyoto-U OCW
京都大学のオープンコースウェアのチャンネル。
オープンコースウェアとは、大学や大学院などの高等教育機関で正規に提供された講義とその関連情報を、インターネットを通じて無償で公開する活動。2003年9月、アメリカの理工系大学マサチューセッツ工科大学が世界初のOCWサイトを立ち上げ、その後世界中の大学にその活動が広がっている[1]。
本当に無限の知識の宝庫、後述する世界最古のOCWチャンネルは英語だがこちらは完全日本語。私が子供の頃は親から「大人になり勉強の本当の価値が分かってからでは、勉強は遅いんだから今のうちに勉強しなければならない」と聞いていたが、そんな時代ではなくなっていくんだなと実感する。
京都大学OCW、こちらのサイトに講義資料があるため一緒に使うと良いかもしれない。私がおすすめするのは電気電子回路演習。LTSpiceの復習ができた。
5位 MIT OpenCourseWare
MITのオープンコースウェアのチャンネル。Sustain the vision of free access to knowledgeの文字が輝くチャンネル。世界最古のOCWサイトのYouTubeチャンネル。正直に言うと、英語で大学の講義は難しすぎた。頑張って聞き取ろうとしたが不可能だった。英語が得意な人におすすめ。動画数はとても多い。
MIT OpenCourseWare | Free Online Course Materials資料チャンネル。
おわりに
大学生活を楽しみましょう。
長く書くと未練たらしくなってしまうので、短く締めます。ここまで読んでくださってありがとうございました。次回は、12月19日のmarbleさんの記事です。
”リンク予定”
Stellaris 3.0.2 機械 ゲシュタルト意識 資源統合 AAR
Stellaris 3.0.2 機械 ゲシュタルト意識 資源統合 AAR
状況説明
2021年5月21日（金）～23日（日）、Paradox Interactive PUBLISHER WEEKENDが来てStellaris MODが安くなっていたため、Ancient Relics 、Synthetic Dawn、Leviathansを買ったため備忘録として初レポ。UtopiaとApocalypseも買ったが、いきなり入れすぎると訳が分からなくなるため、後日別AARにまとめる。
著者、プレイ時間80時間。他パラドゲー合計、600時間。
初回のみ15年だが、基本は、20年ごとに記録を残す。
設定
環境：本体 3.0.2、無料付属DLC、Ancient Relics 、Synthetic Dawn、Leviathans。
自作帝国、機械 ゲシュタルト意識 資源統合、帝国名 DAAR Forge。
他はデフォルトで難易度、少尉。鉄人モードであるためセーブデータの保存はできない。
暴走する同化機械や断固たる殺戮機械は、外交が難しくなるため今回は導入見送り。
初期立地
図はスクショを取り忘れたため開始から15年ほど経過したもの。
TODO:図を挿入
Ancient Relics 導入のため、近郊に2つ発掘拠点がある。思ったより数が多い。Ancient Relics のフレーバーテキストは、物悲しい結末だが雰囲気がでてよい。また、初期以外に惑星が２つあり、居住性＋200％により入植可能。
母星はいい感じに外縁部にある。
機械種族にありがちだが、合金が足りず、探索と基地建設は遅れがち。機械特性のPOP成長-50％により、POP成長速度は通常よりも遅め。序盤50年は探検による拡張方針を取ることにした。
15年時点
KarabとKelbridに接触、Karabは、啓蒙君主制のMolluscoid、警戒されていたが、関係改善により、開戦は避けられそう。
Kelbridは機械かつ敵対的、宿敵を宣言してきたたため、開戦の可能性あり。殺戮機械だと序盤戦力差が付きやすいためつらい。
この時点の方針としては拡張優先だが開戦されない程度に、軍拡することに。
右上にまだ伸びれそうだからそちらに入植をすすめる。
40年時点
新たに停滞した勢力であるZraconと接触、聖地系ではないと思うので近郊に入植してもよいが、とりあえずは刺激を避けたいため保留。
また、銀河中央部のLolehndraとも接触。こちらは宗教狂い、とても面倒だが、とりあえず国境は接していないためセーフ。
Twax'lhdarとも接触だが、こちらも国境は接していないため中立政策を維持。
25年頃に懸念通りに、Kelbridから屈辱の開戦理由で宣戦布告。不幸中の幸いで、殺戮機械ではなかったためか戦力は同程度、国境沿いの要塞に引きこもってにらみ合いになった。
30年頃ボタン操作のミスで、降伏を受け入れてしまったが、影響力減少は痛いが幸福度は機械にはあまり関係がないなんとか立て直せる程度。
その後、宿敵関係の30年ごろに宿敵が解除された。20年ごろにKarabからも宿敵に指定されてしまったが、そちらも30年ごろに解除。
影響力がなさすぎてつらい。入植メインだと序盤から影響力が足りなくなりやすいため、宿敵を増やす。無駄な条約を減らす等々、次の銀河では気を付けていきたい。
戦争騒動が終わった後、右上に拡張を続けて9惑星、POP、126、拡張速度は遅目ではあるが問題はない程度。
3種の中立機構とも接触。
- 学術中立機構 エネルギーが余っているなら、ほぼデメリットなしで研究速度＋１０％、要塞を立てれば各研究＋５は強い。
- 工芸中立機構 機械だと、あまり流入魅力が機能しなくないか？統合力は悪くないがコスパが微妙に感じた。
- 交易中立機構 自前で産出するならほぼ用なし。ウィキを見る限りトレーダー代理店は一応利用してみても良い。
この時の機械へのコメント
POPの成長は遅いが居住性+200％はどの惑星でも入植できるのは、立地が悪くても確実に入植できるという強みになると思われる。
また、影響力さえ何とかなれば屈辱で開戦されたときののデメリットをほぼ受けないのも悪くない。
60年時点
後日、記
Procon29参加記録 (競技部門ソースコード公開)
"第２９回 全国高等専門学校プログラミングコンテスト"お疲れさまでした。
以下しばらく私の日記です。興味がある方を除き大見出し、”競技部門ソースコード公開”まで飛ばしてください。
いつもお世話になっております。Nasatameです。
改めて、Procon29お疲れさまでした。
今年も仙台名取・競技部門チームの一員として参加させていただきました。
思い出してみると４年目です。石畳職人Z、人力パズコン、筋肉優先探索いろいろありました。
毎年思いますが、私は人に恵まれてますね。こればっかりは運があるなと思います。
去年と比べてみると少しだけいろいろできるようになったかなとも思いますが、いまだに至らないところだらけです。
早速ですが、
何と！！今年、仙台名取は競技部門優勝しました。
大躍進ですね。私もびっくりしてます。
感無量という感じです。立派な賞状も頂きました。
まあ欲を言えばですが。
ボランティアの収集方法というかを何とかしてほしい。（システムの改善などの方法で）
ルールはこれでもよかったから、前もってマップサイズとターン数を周知しておいてほしい。
当日にレギュレーション違反、遅延をやらかさないでほしい。
ぐらいですかね。
したことをつらつらと。
６～７月
テスト等忙しくて、ほとんど進まず何とか時間を絞り出して対戦用GUIのみを作成。
８月
私がインターンでいない間、後輩たちに対戦データを収集させる。
帰ってきてからはぼちぼち機械学習してた。
確か８月の後半から、本番用GUI制作開始。
でも結局ほとんどコピペで１，２週間ぐらいで完成。
なぜか、ビームサーチを制作。なんでだっけ？
９月
夏休み終了。
機械学習全然学習が進まず結局勝利予測６割程度。
全然進んでないやばいとか言いながらレポートに追われる。
ちょくちょくビームサーチを強化。
うちの最高傑作”千手観音高橋君完成”！！！圧倒的勝利。
確か鏡（上げた手の方向を確認するため）もこのころ作成。
抜群の安定感を生み出した。
１０月
１週目：
頑張ったけど結局データが足りないことが発覚。
データを急場で増やすためにアルファベータサーチを制作。
２週目：
データを増やしすぎて今度は、ディープラーニング用のPCにデータを移せなくなる。
絶望
SVMに走るがやっぱりうまくいかない。５２％。
３週目：
全てに絶望してアルファベータサーチ等の強化を始めるが結局うまくいかず、
ビームサーチ最強説が浮上。
４週目：
人力練習と部誌作成に追われる。
これ以降は、後輩と一緒だから省略。
後輩のブログのリンク張っておきます。（めんどくさくなったのは秘密だよ！）
yasaijuice-ryouta.hatenablog.com
何もないのもさみしいので、写真を貼っておきます。
うちのSourceTree（限界開発の跡が見られないのは限界過ぎてgit使ってなかったから。）
行きの飛行機内からの富士山
徳島ラーメン
優勝して先生におごってもらった阿波尾鶏。最高！！！！！！！（写真が鳥じゃないのはバグです。おいしすぎて撮り忘れた）
競技部門ソースコード公開
一番のお楽しみ競技部門ソースコード公開を行おうと思います。
部誌やレポートなどいろいろドタバタしてて２週間近く過ぎてしまいました。
大変お待たせ致しました。
以下のリンクがレポジトリです。
procon29_natori_open
実行するときの注意点として、
Procon29.hpp内の各種定数の設定を行ってください。
主要なものとして、NotLoadedQRをfalseにするとQRコードを読み取るモードになります。
trueにすると、前回読み込んだマップを開きます。（初回起動はエラー）
ランダムに生成されたマップで起動したいときは、
NotLoadedQR = true; IsRandom = true;
にしておいてください。
C++用のGoogle Testのパッケージ読み込みに失敗する話[GoogleTestExtensionOptionsPage]
状況
Ｃ＋＋でテストがやりたくなって良い感じのものを探したら以下のページが見つかりました。
Visual Studio で C++ 用の Google Test を使用する方法 | Microsoft Docs
実際に試したところ、Visual Studio Community 2017 15.6.2で Test Adapter for Google Test をインストールしても先ほどのページのようにはなりませんでした。
そこで、ツール/オプション/Test Adapter for Google Testを開くと以下のようになっていました。
また、C:\Users\****\AppData\Roaming\Microsoft\VisualStudio\15.0_2319ee8b\ActivityLog.Setup.xmlを確認したところ、以下のようにエラーを吐いていました。
原因
英語以外の環境では、このパッケージは上手く動作しないらしい。
出典：Google test adapter does not work when the UI of Visual Studio is non english · Issue #121 · Microsoft/TestAdapterForGoogleTest · GitHub
（エラーを吐いているのが、[GoogleTestExtensionOptionsPage]なのでこのオプションページが日本語化されてないのが原因のような、、、）
解決方法
一時的解決方法
１．Visual Studio インストーラーから、変更の中に言語パックが含まれているのでそこから英語をダウンロードします。
２．言語を英語に変更します。
(ツール/オプション/環境/国際対応の設定)
[国際対応の設定] ([オプション] ダイアログ ボックス - [環境])
３．インストーラーから Test Adapter for Google Testをアンインストールしてインストールしなおします。
永久的解決方法
公式が対応してくれるのを待ちます。
この記事を書いたのが２０１８年３月１６日なのですが、１９日前にissueがあがっていたのでさすがに次のバージョンアップでは改善されていると思います。
（願望）
Game Programming Patternsをよんで【Siv3D機能と対比しながら】
Game Programming Patterns 感想
あくまで個人的な意見です。
総評
ゲームプログラミング特にデザインパターンについて、著者の長年の経験から得た知識を元に使い時、使用方法、実装、ヒントなどについてとてもよくまとめられていたと思う。
ゲームプログラミングによく使用するデザインパターンについて全体像を知りたいと思う人にはとてもお勧めだと思う。
PC、専用ハード問わず使用できる知識についてかかれていたのが印象的だった。
内部の実装については、C++で書かれていたがあくまで細かい部分にこだわることなく、クラス相互の関係などを分かりやすくまとめるためにコードを使用していたため、C++の知識がなくても読める内容になっていたと思う。
4000円だして買う価値がある本。ただし、高いので図書館などにあるならそれでとりあえずはいい、積み本があるならまずそれをどうにかしたほうがいいかもしれません。（ちなみに私は、蟻本、チーター本、TLE（ヅ）本、応用情報技術者教本をつんでいます。）
注意
ここに登場するコードは基本、C++＆Siv3Dです。結構ポインタが出てきます。少し前の私のようにポインタは即危険という人間もいるはずですが、それならunique_ptr,optionalを使いましょう。しかし、この本をよんでからポインタは危険だけど便利だなとも思い始めました。
章ごとのまとめ（メモ）
印象に残ったことをまとめます。
かなり自分流に解釈しているため、実際の内容とは乖離していることが多々あります。
Part01
イントロダクション
良い設計とは、
１、部分的な変更が全体に影響を及ぼさないようになっている。（分離）
＝＞これにより同時に考えることをすくなくできる。
＝＞設計にかける労力は、必ず回収できる程度にしておく。（ライブラリ、エンジンにこだわりすぎて何を作りたかったのか忘れている開発者は多い）
２、コードの抽象化、実行速度、変更可能性
＝＞部分的に対立したこの３つのバランスが取れている。（抽象化しすぎると、実行速度が落ちて、実行速度を優先しすぎると変更しずらくなる）
３、完璧な正解はない＝＞数々の誤答があるだけ
４、迷ったら、吟味された単純なコードにしておけば良い。
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に積めば、
１、なにがいつ実行されたか分かる
２、わかるから打ち消しの動作（戻る）が実装できる。現在の実行状況を表すフラグを戻せば良い
３、その打ち消しを打ち消し（再実行）が実装出来る。同、進めれば良い
とかいろいろメリットを享受できる。
Part03
フライウェイト。Flyweight
まんま、Assetです。Ryoさんありがとうございます。
ゲーム内で、重くて（画像など）使いまわせるデータをクラスごとに持たせる必要はないよね。
ただ、Assetの問題は、いろいろなところからアクセスできるのでどこで書き換え（Register）られたかがわからないところ。
これは、どこからでも読めるようにした弊害。プログラマーが気をつけなければいけないから初心者使うなというのも納得。（特に並列プログラミングの際）
これは、FlyweightではなくSingletonの問題です。
Part04
オブザーバー。Observer
監視者。
業績の達成などに便利。コードのいろいろなところ、（肉を焼くところ）（魚をとるところ）（移動処理）などに業績達成チェックなんていちいち入れてられないとおもったら使いどころかも。
class Observer{
virtual void onNotify(Event event) = 0;
}
class Subject{
vector
}
class ItemBox : Subject {
void enterItem(){
//アイテムを入れたときそれをobserverに送信。
}
}
class Achievements : public Observer {
virtual void onNotify(Event event){
//アイテムボックスに何が入ったかを入手しはじめてのものなら実績を解法。
}
}
これも、使いどころには気をつけよう。C#にはデフォルトで似たような機能があるらしい。Siv3Dでは、UIまわりに使っていそう。
Part06
Singleton
まともにみえるグローバル変数。
グローバル変数を多用しちゃいけない理由はみんなご存知。
どうしても使いたいときはSingletonより。
static変数を使うのもありかも。（定義が簡単なため）
利点、インスタンスの生成を遅延できる。
Part07
ステート。State
有限状態機械、プッシュダウンオートマトン。
AIでつかう。上の二つでググレばOK.
Part08
ダブルバッファ。
みんな大好き。
MY豆知識。コンソールウインドウでやるとコンソールウインドウでテ○リス、イン○ーダーゲーム、パッ○マンぐらいは作れる。色も頑張ればつけれる。
丸ごと入れ替えるのと、ポインタ使う方法がある。
Part09
ゲームループ。GameLoop
System::Update()。Ryoさん本当にありがとうございました。
何が凄いって、６０FPSに自動でなること。（FPSは各自ググル）
ならないなら重い。（フレームごとに移動量を設定すると環境によってゲームが動作を変える地獄へ）
自作でゲームループを作るときに６０FPSならないときは、対処法が３パターンある。
１、あきらめる。（そういうもんだ仕様）
２、６０FPSにするために、遅延時間を調節する。
３、フレーム依存のコードから秒数依存にする。（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を返すようにしておけば単調な音楽を聴かされなくて済む。（音量０、イヤホンipodでいいのでは）
Part17
データ局所化。
いままではなんだったんだ、裏切られた。
ポインタは実行効率を悪くする。
ポインタの先をたどらなければいけないから。
0->1->2->3->4->5>6->7
とすると、メモリ中（主記憶領域はレジスタより100倍遅い）
を飛び回るのでよくない。
更にいうなら、継承や仮想関数もよくない。
更に言うなら、クラスも、クラス関数のポインタだからよくない。
、、、
本もいってる、”必要がなければ気にするな。時間の無駄”
配列は順々に並んでいるため、実行効率が高いらしい
Part18
ダーティフラグ。Dirty Flag
Dirty Byteは響きがよくないらしい？
計算結果のキャッシュ。
！！！！！みんな大好きDP（動的計画法）！！！！！！
を、フラグを持たせて管理しようという話らしい。
親フラグが立ってたら相対的に存在する場合子供も再計算される。
child |= parent。ハイ。
相対位置座標などに便利。
Part19
オブジェクトプール。ObjectPool
ガベージコレクタがない環境で。
自作、メモリ管理の方法。
メモリのフラグメンテーションを防げる。
データ局所化と似たような効果。
高専プロコン２０１７ 備忘録
高専プロコン２０１７
序文
競技部門７位、特別賞いただきました。
このたび、時間にやっと余裕が出来たので２ヶ月遅れとはなりますが、感想を書こうと思い立ち、こうしています。
今年で私は高専プロコン３年目となります。
思えば入学当初からいろいろありました。
１年生では、高専プロコン開発メンバーに入れていただいて、何したらいいのかさっぱりなので「うーん、先輩お願いしマース。」ってしてたら、いざ１ヶ月前になったら先輩がドタキャンしたり。しかも、新幹線取ってなかったり。
思えば１年生の夏前ごろでしたね、Ｋ先輩と出会ったのもあの時はここまで長い付き合いになるとは思ってもいませんでした。（実は当初同学年だと思ってたり、）
１年生の高専プロコンは、前日夜にバグが見つかってなきながらデバッグしてました。
そんなこんながありながらも、２年生でもまたやろうとおもったのは奇跡でしたね。
それもこれも、Ｋ先輩がいたとか、悔しかったとか、いろいろあったせいでしたね。
２年生では、夏休み朝から晩まで一緒に開発したり、Ｋ先輩と一緒にＰＣＫ本選行ったり、あの人のコミュ力爆発にはいつもおどろかされました。
けど、結局あまりいい終わり方が出来なかったのはあの人力パズコンが悪かったんでしょう。
（ちなみにこの年私はＪＯＩ無事落ち）
さて、前前置きも長くなりました。
３年生
今年は、去年の計画不足という反省を踏まえ
なんて物をつくったりしましたが、後輩にわざわざ、作業に煩雑さを増やすんじゃないとかおこられたりしちゃいました。
ほかにもメンバーとぶつかったりもしました。来年は後輩に多めに仕事（マネージャー）をふってみようかななんてね。
５月、設計
６月、設計、基本の実装。回転関数など、後テストだったのであまり活動できませんでした。
７月、個人的にコーディング、ビームサーチ、チョクダイサーチの勉強をしてました。またもやテスト。
８月、夏休み（２ヶ月間）です。これを生かして全力でコーディングしました。１日２００行ぐらい書いてましたね。それでも学校に集まらなくなって、連絡が疎になったせいかあまり、すすみませんでした。今年もＫ先輩と１週間ほど二人で６時間コーディング。クーラーがあったおかげで干からびずに済みました。来年も欲しいです。Ｋ先輩はその後インターン。
９月前半、ＰＣＫ予選で２週間ほど開発をお休みしました。結構でかかったですね。ただでさえ予定が遅れに遅れまくってたので。
ＰＣＫ終わった次の日からまたＫ先輩とコーディング、でも課題で忙しそう。なんとか一通りの機能は実装し終わって、高速化、省メモリ化に移れました。（８月中には移ってるはずだったのに）。
９月後半、学校も始まりまして、コーディングもあまり出来なくなりました。しかし、時間は待ってくれないわけで時間を見つけては書いてました。その結果、なんとか高速化、省メモリ化も一段落しました。（バグはある）
ソースリスト提出。まじめにやりましょう。入賞するのにとても重要です。
１０月前半、バグは再現性、頻度ともに低かったので無視して、評価関数と列挙関数を作りまくって後は練習してました。
本選前日、急に配置情報を使えたほうがいい気分になってきて、配置情報に関する機能を新幹線の中１日で実装。（いままでは使っても減点でまけるだろうから、使わない方針でした。）ハードコーディングでした。
深夜先輩の評価関数の調整中に神が舞い降りてきました。「列挙関数良いとこどりをしたらもっとよくなるんじゃない」と、そこで良いとこどりする関数を製作しましたところ、大成功。実質本番はこれだけでいけました。
本選１日目、運よくアンチパターンである灯台の問題を避けることが出来たので、決勝トーナメントに進出することができました。Ｋ先輩、Ｋ君パズルが上手い。
本選２日目、準決勝またもや当たりがよく３０秒で解き切り、並べるのに３分かかりました。思えばここら辺から予兆はあったのかもしれません。
決勝戦。ソルバーの調子がよくまたもや３０秒回答、並べ始めます、、、あれ、１，２，３，４，５みんな完成させていくぞ、、、完成には６分ほどを要しました。
人力ゲーとはいいません。人力部分の工夫が足りませんでした。
ときには”プログラム以外の部分も重要”、覚えておかなければいけないことです。
でもなんとか、審査員特別賞を頂きました。三年間の集大成なのかななんてね。ちょっとなきそうでした。（そして先生、なぜ写真撮影のタイミングでタバコを吸いに行ってますか。）
先生にステーキを振舞っていただきました。おいしかったです。Ｋ先輩よく食べるなあ。
ちなみに初日、ふにゃさんとその後輩と一緒にご飯食べたり、最終日も深夜一緒にお話したりいろいろありました。たのしかったです。
名刺、滅茶苦茶交換しました。けど、企業名刺ではないのでコンテストは不参加。
私は楽しんでました。一緒にいった二人も楽しんでくれていたらそれを超えることはありません。
本題に入ります。ソルバー公開します。
今回作ったソルバー公開することにしました。
２ヶ月もありましたが、やっつけで作った当時のままなのでまあそれっぽい雰囲気があっていい。ということにして置いてください。（一応コメントは付け足しました。）
正直参考になるかは怪しいところですが、この文章とあわせて何かを受け取ってくれたらうれしいです。
開始時
終了時
基本的には、人間の目で探索状況をＧＵＩにより把握しながら、探索手法、列挙関数、評価関数を付け替えて探索をすすめて解に近づいていくというのが基本方針でした。
参考までにそれぞれの主な手法
探索手法は、chokudaiサーチ、ビームサーチ
列挙関数は、辺、角度
評価関数は、ピースの接した辺の長さ、割合
動画
決勝１年生勧誘用.mp4 - Google ドライブ
正直、問題が簡単すぎてＧＵＩ、練習をつんだ人間を生かせませんでした。
ソースコードへのリンク
https://bitbucket.org/nasatame/procon2017ofnatori
ダウンロードのほうから一括でダウンロードできます。もし質問があればぜひtwitterのnasatameのほうまでどうぞなるべく対応させていただきます。
反省
探索中にGUIとまるの嫌だったからスレッドごとに分けたんですが、よく考えずに分けたせいで結合がいたるところに出来たりして気持ち悪くなってしまいました。
（特にポインタ周りがアンスレッドセーフなのにスレッドにぶち込んでる。）
実はバグがあります。バグが発生するのは100回に1回ぐらいで再現性も取れなかったので無視して大会に突っ込んだんですが。多分メモリ周りがやばいんだと思ってます。正直心当たりがありすぎてどうしようという感じです。
命名規則が乱れまくりました。日によって変わってた、ぽいのが怖いです。
いろいろと一人で独断専行しすぎました。結局６割一人で書いてます。やっぱりマネージャー業はむいてません。
反省から来年へ
- コミュニケーションを取ろう。＃最重要＃
- 設計をちゃんとやろう。（なるべくクラス図を描く勢いで）
- 予定、予想なんか立つか！！というのも分かるけど一応予定ここまでこの日までというのはきちんと決めて守る努力をする。
- ＧＵＩとSolverを一緒に製作するときは、並列化前提で設計する。
以下できれば
- みんなでコーディング規約を決めよう。守ろう。
- お互いにコードレビューしよう。
- ツールとしてのGitを使おう。（オンラインストレージ化しないようにしよう）
さて、この入賞を良い機会として、講習会＋アルゴリズム講習会でうちの部活の今の血脈が脈々と受け継がれていってくれればうれしいです。
（しかし、歴史はそう上手くいかないと語っています。だからこそ全力で努力をしなければ。）
PCK2017本選 参加記
ＰＣＫ本選お疲れ様でした。
結果は、６ＡＣ５ＷＡで上位入賞はできませんでした。
しかし、普段はtwitterでしか交流できない競技プログラマーの方と直接お話することができてとてもうれしかったです。
本選中にであった競技プログラマーの皆様。
https://twitter.com/kotatsugame_t/lists/pck2017/members
ＴＬのトップ画が美少女でも、現実が美少女とは限らない
という衝撃の事実に始まり。友利奈緒のかわいさ、るましのかばんは友利奈緒、実は例のカモノハシハが筆箱だった、こたつがめ氏がShell芸始めるらしい、大富豪は地方ルールがすごい、Platypus氏太鼓の達人がすごく上手い、会津大生滅茶苦茶やさしい（お客様扱いなのでそれはそう）、今年のテレビちゃんはＭサイズだった、テレビちゃんはWA投げで3/6でゲットだった、会津購買は３種の神器がそろってる、TLE購買で買ってしまった。などなどとても充実した２日間でした。
反省として大分はしゃいで自分を見失っていた感じがありました。
ずいぶん駆け足になってしまいましたが参加記の方を閉めさせていただきます。
ＰＣＫ本選で出会った全ての皆様本当にありがとうございました。あの２日間は忘れられないすばらしい時間でした。
しないわけにもいけないので駆け足で問題の解説をします。（実際の解説もかなり駆け足でした。）
１問目
やるだけ。for,ifがあればなんとかなる。
２問目
やるだけ。誤差が出ないように気をつける、分かりやすい変数名、double型を使わない。などがあれば特別賞を狙えたらしい。
３問目
二人の誕生年月日から。二人の年の差の最大を求める問題。うるう年についての解説があるが結局無視して大丈夫だった。if文
４問目
与えられた数の中から、最大の数を見つける。
その数の公約数を列挙して、lower_boundする。
結果を加算して解答。
５問目
１日３回ご飯を出せる。ご飯を出す時刻を好きに決められる。
N人のお客さんのそれぞれ朝ごはん、昼ごはん、夜ごはんを受け取れる時間が与えられる。
３食食べられる、お客さんを最大化しなさい。
お客さんのご飯を食べ始める時間にだけご飯を出すか試せばいいため、
N <= 50 から 50*3 = 150 これを３回ご飯を出すため。
(150 ^ 3) = 約3*10^7となる。
前処理で、ご飯ごとにそれぞれ24*60=1440でlong long intの配列を作っておき食べれる人のorをとっておけば、andを使うことでO(1)で何人が３食すべて受け取れるか判定できる。
この解法は、O(3*10^7*32)のため余裕で間に合う。
６問目
与えられた２次元配列の行と行、列と列を入れ替える処理を行い市松模様を作れるかこたえよ。
正直、テストケース作りまくって力技で通したため考察はしていない。
しかし、解説を聞いた限りだと存在する1の数が決まっている。２種類の列と行しか存在しない。などを使えば簡単に実装できるらしい。
７問目
正直６問目と同じく運だけで解いた感がある。
答えが８以下になる。
３桁以上に分割する場合場合同じ桁数で分割するしか答えが８以下になるパターンは存在しない。など使えばいいらしい。
２桁以下はDPでがんばる。
総評、なぜ６ACできたのか謎。気づきがあった。（その割に次の日のARCで２問目をとけずレートを19も溶かした）（行きの仙台売店でCCさくら買ったのが良かったのかもしれない）
