2019-04-17

競プロを始めて1年が経って思うところをまとめた

競プロ

こんにちは、すぎやんです。
去年の4/14にAtCoderのコンテストに初めて参加してから1年が経ちました。ちょうどいい節目のような気がしたのでこれまでの競プロ生活を少し振り返ってみようと思います。

なぜ競プロをはじめたか

去年の4月に競プロのコンテストに参加したと先ほど言いましたが、厳密にいうと競プロに出会ったのはこのタイミングではありません。多分同様の経験をした人も一定数いるのではないかと思うのですが、初めに競プロを布教されたタイミングではそこまでやりこむことはしませんでした。
f:id:yuji9511yuji:20190415184839p:plain
これは僕の精進グラフです。これを見れば一目瞭然なんですが、AtCoderの問題を初めて解いたタイミングとコンテストに参加してレートがつき始めたタイミングには1年くらいの差があります。別に実力不足を気にして隠れて精進していたわけではなく、ここまでは競プロに対する熱が特にありませんでした。
最初に競プロに出会ったのは学部2年の時に僕が属していたeeic (工学部電子情報工学科)でふと開催された「競プロをやってみよう」という企画でした。
企画してくれたのは学科の同期ですでに競プロをある程度やっていた人たちで、ABCの適当な回からA~Dの4問を持ってきて情報教育棟あたりでみんなでやってみましょうみたいなものです。
当時学科ではC言語を習い始めたばかりで僕自身も学科に入って初めてプログラミングというものに出会ったので、まだ右も左もわからない状態でした。それでもC問題くらいまでは考えれば解けるんだなぁみたいに思った記憶があります（当時は考察よりも実装が全くできなかった気がします）。
そんな感じで競プロと出会ったわけですが、この時はそこまで魅力を感じるようなことはありませんでした。なぜでしょうかね。
今となってはこんなに楽しいのになぜすぐ始めなかったんだという感じですが、おそらく学科の課題などで余裕がなかったのではないでしょうか。
あと、プログラムを書くことに慣れていないので自明な問題の解答を書き起こせないもどかしさみたいのもあったのかもしれません。

こんな感じで1年間は温めておいた競プロですが、ちょうど去年の4月ごろに突然ブームが訪れます。
このブームの着火剤はなんだったのでしょうか。最近しばらく思い出そうとしているのですが思い出せません。
きっと誰かが競プロの話をしていたとか何かあったんだと思うのですが特に記憶に残っていないんですよね。でも今ほど周りの人がみんなやっていて触発されたという状況ではないと思うので謎は深まるばかりです。
まぁもともと受験っぽい数学とかを考察して解き進めるみたいな作業は好きだったのでもともと相性はいいんだと思ってます。
こうしてコンテストに参加し始めました。

開始当初の目標とか

誰しも初めはこの辺を目指したいみたいな目標を持つと思います。僕もそうしたものは最初からあって、簡潔にいうと「やっていれば青色にはなるだろう」という所感でした（まだなってませんがw）。水色までは慣れさえすればすぐに到達し、そこからアルゴリズムや競プロ特有のテクニックを少し習得すれば青にはなるんじゃないかなーと思っていました。黄色に関してはセンスによっては到達できないかもくらいに考えていました。頭の構造的に橙以上は到達できないだろうという感じです。
この感覚は現在もそんなに変わってないです。黄色が開始当初よりは雲の上ではなくなったかなーという感じです。今年の中頃には青になっていると信じたいのでそこからどの辺まで上がるかというところです。

緑になった時

6回くらい参加したら緑になったのでここまでは順調という感じでした。1回だけBで手こずりCが解けないという激ヤバ回がありましたがそれ以外は特に問題なく徐々に競プロに慣れていきました。

水色になった時

水色になった時は前にブログにまとめました。
ysugiyama.hatenablog.com

10回程度で水色手前になったのですが、そこから何回か連続で失敗したので思っていたより水色になるのに時間がかかりました。
この頃にABC-C,Dの過去問をやるべきだと思い、上から埋め始めました。水色になるくらいには難しいものを除きだいたいこなしていた気がします。
また、水色になった瞬間に連続で2回冷えて緑に包まれた時は自分のポテンシャルを少し疑いました。そこから連続でうまくいったので挽回することはできました。

水色になってから

水色になってからはコンテストごとではなく企業コンも含め点数順に埋めていきました。
400点の解ける割合が増えてきたので500点や600点の簡単な問題に少しずつ慣れていきました。次第に考察重視の問題が増えてきたので、早く実装することはもちろん、じっくり考える習慣をつけるようにしました。
よく「◯◯になるために習得したテクニック」みたいなのを列挙している記事を見ますが、あのような形式で実力を把握するのはあんまり意味がないかなーと思ってます。「このようなタイプの問題でこれらの解法の選択肢が思い浮かぶ」みたいな部分に実力の指標がありそうです。

オンサイトのコンテストとかイベントとか

オンサイトで対面して議論したり同時に競プロをすることはモチベアップにめちゃくちゃ効果的です。今まで参加したものおよびこれから参加しようと思っているものを簡単にまとめました。

CODE THANKS FESTIVAL

去年の11月に開催されたオンサイトコンテストです。当時まだ水色と緑のはざまでしたが、500点の早解きに運よく成功し参加できました。
確かコンテスト直前のratedで緑落ちして当日どっちの色で自己紹介しようか唸っていた覚えがありますw

DISCO presents ディスカバリーチャンネル　コードコンテスト

THANKSより奇跡的な通過だったのですが、就職をする年度ではない一般の枠での滑り込みでした。THANKSの時よりは界隈の知り合いが増えていたので、自分が普段twitterや順位表で見ている人たちが目の前にたくさんいてとても楽しかったです。コンテスト結果も自分のレートにしては悪くない成績だったので大満足でした。

ゆるふわコン

2月ごろに開催されたフォルシア株式会社さん主催のコンテストです。誰でも参加できるゆるっとふわっとしたコンテストでした。
知り合いもちょくちょく来てたので僕もゆるっとしたテンションで参加することができました。
フォルシアさん優良企業そうだなって思いました。笑

競プロキャンプ

今年の5月にあるので参加しようと思ってます。とにかく同じ競プロerの方々と少しでも交流を持ちたいと思っているので楽しみにしてます！

プラサミ

こちらもこれから参加しようと思っています。やることは具体的に決まっておらず各自やりたいことを持ちいるみたいな話を聞いたので、何をやるか考えておこうと思います！

あと、競プロとは直接関係していないのですが、AtCoder Jobsで応募したフィックスターズさんのインターンに申し込んでありがたいことに採用していただいたので5月半ばに開始する予定です。
今まで経験してこなかったソフトウェア高速化などをやらせてもらえる予定なので楽しみにしています。

これからどうする

順調にいけば夏までには青になれると思うのですが、現在のパフォのhighestが黄色に届いたことがないため、このままいくと確実に青で停滞します。
つまり今と同じような精進をしていてはダメということになります。
今までの精進は500点程度までの比較的考察時間が少なく実装にかける時間の割合が多い問題の数をこなしてきました。
しかし、今後取り組むことになる600-700点の問題になると考察が重くなるので問題を解くペースも落ちることが想定され、思うように精進が進まなくなる気がします。
どのタイミングでeditorialを見るか、という永遠の課題がありますが、初期はある程度高得点になれるためにも早めに見るべきなのかなーと今は考えています。
この辺の問題が時間をかけてでも解けるようになれば青の上位に推移することができると思うので努力していきたいと思います。
ただ、授業とか色々あって春休みほど精進ができないのがネックなので時間の創出は考えないといけないですね。

おわりに

最後まで読んでくださってありがとうございました。最近文字に起こすことをしていなかったのでその練習も含めて書いてみました。
TLにいる同朋の方々にはいつもいい刺激を受けているのでこれからも共に精進していきましょう！

2018-12-20

Macbook Proのキーボードのチャタリングが直らなくてキレたのでソフトウェア的に直した話

タイトルの通りです。
つい3ヶ月ほど前に購入したMacbook Pro 2018ですが、キーボードの特定のキーが一定確率で2回押されてしまうという不具合を踏みました。
調べてみると何件か同様の症状を訴えている記事を見かけたので、よくあるハードウェアの不具合なんだなと思い無償の修理に出しました。
修理までの対応は電話を通じてとても丁寧にやっていただき、商品も配送修理に出してからわずか2日で帰ってきたのでその対応の速さにはとても感謝しています。
修理から戻ってきた時のMacはキーボードの交換をはじめ他の場所もピカピカになっていて、問題のチャタリングも無くなっていました。
やっとあの症状から解放されたとこの時は安心していました。

しかし...
修理から戻ってきて１ヶ月ほどたち、作業をしているとまた例の症状が現れたではありませんか。
もちろんまた修理に出せば無償でやってくれてすぐ返ってくるでしょう。でもなんかまた手続きをするのが面倒臭かったので、ソフトウェア的な解決手段が何かないかなと考えてみました。

調べてみると、まずKarabinerというMacにインストールできるキーボード操作ツールが引っかかってきました。これの設定ファイルにある「連続して反応する時間の最小値」みたいのを設定すればチャタリングは回避できるようでした。早速インストールしてその設定を探してみたのですがそんなものはどこにもない。
他の更新時期の新しいサイトをみたらわかったのですが、その機能は少し前のアップデートで削除されたようでした。やれやれ。

そのあとに見つけたサイトがチャタリングを抑制するプログラムを裏で走らせておくというものです。参考にしたのは以下のサイトです。

macOSのチャタリングをソフトウェアで対応する：株式会社サブスレッド

基本的にこのサイトに書かれている通り、レポジトリをgit cloneしてmakeしたファイルを実行すれば指定した間隔以下の入力を無視することができます。
半信半疑でやってみましたが、思ったよりうまくいったので驚きました。
僕はしきい値の変更を行いました。デフォルトの値(100ms)だとたまにチャタリングがすり抜けてしまうことがあったため、値を120msに変更しました。
やり方ですが、レポジトリ内のdebounce.mを開き、15行目にあった以下の部分を書き換え、再びmakeを行います。

...
#import <Foundation/Foundation.h>
#import <AppKit/NSEvent.h>

#define DEBOUNCE_DELAY 100 // ここの数値を変える
#define SYNTHETIC_KB_ID 666
..

こうしてチャタリングが解消することを確認し、これをdaemonを用いて起動時に毎回自動で立ち上がるように設定したのですが、先ほどのページ通りに行なってもうまく動きませんでした。
おそらく実行権限などの問題と思われますが、とりあえず実行ファイルのパスを/usr/local/binではなく自分でcloneしたディレクトリに設定することで無事動くようになりました。例えば、.plistファイルの中身を下のような感じに書き換えます。

    <array>
        <string>/Users/username/debounce-mac/debounce</string>
    </array>

これでとりあえずチャタリングは回避できました。あまりに高速に同じキーを押さない限り、正しいものが入力されないということはないと思います。
このまましばらく使ってみて、やっぱり使いづらさが出てくるようならもう一度無償修理にでも出そうと思います。

この記事が同一の症状が出てる人の参考になればなーと思ってます。バタフライキーボード、色々問題点が多いらしいのでこういう不具合が減ってくれるといいのですが...

2018-12-18

AtCoder Grand Contest 029

久しぶりのAGCでDまで時間をかけて考察したので残しておこうと思う。
本番は比較的速い時間にBを通すことができたので青パフォを得ることができた。
欲を言えばDは通せたなーと思ったが、まぁいいでしょう。

A - Irreversible operation

WとBを何回入れ替えることができるかという問題。
できるだけWを左に寄せればいいんだなーというのはすぐ気づき、ゆったりと実装してAC。
みんなの解くスピードが速すぎて順位表みてびびった。A問題のWA恐怖症なので結構念入りに確認してたのもあるかもしれない。

B - Powers of two

和が2のべき乗となるようにペアを組んだ時のペアの最大数を求める問題。
とりあえずN = 200000だからdpとかは無理そうだからソートしようってなってソートする。下から見ていったが貪欲に決めていったら決まらないことに気づく。例えば {1, 3, 15, 17}と{1, 3, 5, 15}の組み合わせだと{1,3}で組んでいい時とダメな時がある。

しばらく考えて上から貪欲に見ていくとうまくいくことに気づく。上の2つの例でもうまくいく。

それでは大きい数から見ていって、ペア候補となる数はどのようなものがあるかを考えてみる。注目する数をKとすると、ペアとなるべき数Xは
$K+X=2^t, X\leq K$
この条件を考えると、 $2^t$ の表す値はKより大きな最小の2のべき乗のみを考えればよいことがわかる。
たとえば、 $K=14$ であったら、 $14+X=2^4=16$ のみを考えればよく、 $14+X=2^5=32$ を考える必要はない。なぜなら後者を考えるとXは必ずKより大きな数になってしまうからである。
したがって、大きい順に見ていき、まだ使われていないペア候補が見つかればそれを使ってペア数をインクリメントすればよい。まだ使っていない数を見つけるために二部探索などを使っている人もいたが、mapを用いて使える残りの回数を持っておけばいいと思う。
atcoder.jp

C - Lexicographic constraints

いくつの文字数を使えば辞書順に並ぶような文字列を構成できるかという問題。コンテスト終了後に解いたが、かなり実装に手こずってしまった。

当然使える文字数が多いほど構築できる可能性は高くなるので、最小何文字を使えば可能かという二部探索の問題と捉えることができる。ここは経験があれば割と気づきやすい部分だと思うが、難しいのはこの判定を実装する部分である。　　
文字列長を左から順にみていく。もし前の文字列より後の文字列の方が大きければ末尾に'a'をその差分だけ足すのが最小とわかる。この場合は問題ない。
逆に前の文字列長が後の文字列長以上である場合には整数の繰り上がりのように最小の位のアルファベットを移動させていくことになる。この最小の位の位置は小さい方の値によって決定する。したがって文字列が'aaaa'の状態で文字列長が4から2へと遷移すれば上から２文字目のaがインクリメントされ結果として生じる文字列は'ab'となる。
この実装が思ったより難しく、文字列を圧縮したりstack使ったりする方法が色々紹介されていたが僕はmapのみを使うことにした。
具体的には、文字a,b,c...を0,1,2...とし、i桁目の文字をmp[i]というキーバリューの形で保持する。
K種類の文字列を使うとき、値を更新する桁を下から見ていき、値がK-1を超えたら次の桁へ繰り上がるということを繰り返す。
そうして繰り上がりがK文字以内でできなくなればそのKでは不可能と判定できる。
ここの判定はAtCoder公式の解説動画がわかりやすいと思う。

コードはこちら。
atcoder.jp
このコードでひたすらバグに悩んだのは45行目で特定の桁から下の数値をリセットする部分。これをしていなかったので桁の繰り上がりが正しく行われていなかったようだ。数ケースだけ落ちると原因がホントわかりづらい...

D - Grid game

800点問題。なのだがさすがに800点にしては簡単だと思う。800点問題初AC。
先攻はできるだけ下に行き続け、後攻はたどり着くのが可能な範囲で最も近い行き止まりをめがけて進むのが最適だとわかるので、まずはたどり着くことのできるマスの範囲を絞る。
高橋くんが先攻で下に移動した後、後攻の青木くんが右に進むことができるかできないかで経路が変わります。青木くんは必ずしも右に行かなくてもいいのだが、まずは行ける限り右に行くとして経路を決定する。
すると以下のようになる。
f:id:yuji9511yuji:20181218221531p:plain
青木くんが最も右に移動した場合に図のような経路になるので、青線で囲った部分および経路上に関しては青木くんが自分の意志で移動できることになる(高橋くんは進む以外に選択肢がないため)。
したがって、この範囲の中から最も早くぶつかる(=最もX座標が小さい)点に行くのが青木くんにとって最善になる。
XとYが直感と逆なのでそこだけ気をつけよう。
atcoder.jp

2018-11-26

Code Thanks Festival 2018に参加してきました

最近あまり競プロできていなかったので久しぶりの更新です．

さて，人生初のオンサイトコンテストであるCode Thanks Festivalに参加してきました！
f:id:yuji9511yuji:20181126231633j:plain
おそらくレベル的にはThanksもまだ厳しいくらいだったのですが，たまたま予選Bで相性のいい問題が早解きできたので運よく参加させていただくことができました．
参加者のレート一覧みたら下に10人もいなかったですね，最頻値が青なので順位表みただけでも少しひよってました．

会場はとても広く綺麗な場所で，お菓子とか飲み物も充実していたのでとても好印象でした．

あと，chokudaiさんが会場内をぶらぶらしていたので声をかけたら噂のAtCoderステッカーをくれました．ステッカーが徐々に増えてくると強者になった気がしますね（気のせい）．会場で生ファボ爆を披露してるのも面白かったです． f:id:yuji9511yuji:20181126232503j:plain

昼にでた弁当にリクルートさんの財力を感じました．叙々苑と何かと何かの三種類があったのですがぼうっとしていたら叙々苑が一瞬で無くなっていました．みなさんこういう時は素早い．代わりに食べた牛すき弁当もめちゃくちゃ美味しかったです．多分どれも2000円近くしそう...

12時からコンテストが開始しました．
制限時間が3時間というのをみて，おそらく今の実力だと300くらいまで早解きしてあとはずっと唸ってたら終わりそうだなーと思ってたらその通りになりました．
BのWA量産の焦りは若干ありましたが，A~Dは特に問題なかったです．順位表見てほぼ全員がDまですぐ解いているあたりやっぱり選ばれた人たちしかいないんだなーと思いました．

ほとんどの時間はEを考えていましたね．制約的にN^3程度のDPだろうというところまではたどり着くものの，そこからindexをどう設定してどう遷移していくみたいな部分の考察がまだできませんでした．解説見ても簡単じゃんとはならなかったのでまだ精進が足りないですね．

パーカーは上位50人で，Eまでをある程度早く解いた人がボーダーだったのでちょっと厳しかったですね．まぁ青コーダー中位に勝てるわけもなく．

コンテストが終わったあとは懇親会でした．みんなのビンゴカード見てるとそれぞれ独自のこだわり（特に好きな言語，好きなアルゴリズムあたり）を持っていて面白かったです．

服装に個性を見出してる人も結構いましたね．kyopuro_friendsさんはどこからどう見てもサーバルちゃんでしたし，C++完全に理解している人とかいろんな人がいました．何か自分を特徴付けるもの身につけていって特定してもらうみたいなことするのも賢いですね．

もう少し界隈で知り合いが多いとオフ会みたいな感じで盛り上がったのかもしれないですけど，まだ始めたばっかりでオンサイトの経験もなかったのでこれからその辺のコネクションは作っていきたいですね．

懇親会でもchokudaiさんのAtCoder株式会社に関するいろんな裏話を聞けたので面白かったです．クソマイナー言語に対応するのにリソース割く必要性とか攻撃に対する対応のめんどくささとか，あと今後のARCの開催候補日(まだ非公表)とか教えてくれました．

いろんな人と話して美味しいものも食べ，とても満足のいく初オンサイトでした．あとは自分の競プロの腕を磨くだけですね．来年は少なくとも青色になった状態で迎えたいと思います．
最後に今回の戦利品です．交通費も支給されているしこれだけいただけるなんてオンサイト素晴らしいですね！
f:id:yuji9511yuji:20181126234101j:plain

多分１月にあるDDCCにも出場できそうなので次のオンサイトも楽しみにしています！

2018-11-05

AtCoder Beginner Contest 113

競プロ

さっさと3完したけどDの解法が生えずに終了。
だいたい解法がDPの時はいつもこんな感じなので現状では良しとしよう。

A - Discount Fare

X + Y/2をする。

B - Palace

一個ずつ比較していって平均との差が最も小さいindexおよびその差を記録しておく。
本番では誤差の影響出ないだろうとdouble型使ったけど1000倍してintで解いた方が賢いね。

C - ID

特に考えることはなく実装あるのみ。 vector< pair< int, int > >を用いてP[i]とY[i]を格納した後、県の番号の昇順、県の番号が同じなら年代の若い順に並び替える。ソートする関数はこんな感じかな。

typedef pair<ll, ll> lpair;

bool comp(lpair p1, lpair p2){
    if(p1.first == p2.first){
        return (p1.second < p2.second);
    }
    return (p1.first < p2.first);
}

vector<lpair> lp;
sort(lp.begin(), lp.end(), comp);

最後の出力のために、もともと何番目にあったかを保持しておく必要がある。方法としてはmap使う or pairの中に何番目だったかの変数をもう一個追加するのが良さそう。圧倒的にmapの方がラク。

D - Number of Amidakuji

解説みたらすんなり理解できたのはよかった。ただ本番中には思いつかないと思った。

「今上から何段目、左から何列目にいて、そこまでにあり得る場合の数」を考えるとそのさきの経路はその値を元に計算できる、つまり部分問題として捉えることができる。

この場合の数がdp[i][j](上からi段目, 左からj列目)で、これを上から下に進めていくことで求める値 dp[H][K]が出てくる。dpの計算は前準備さえすればループ回してやるだけなので省略。

この問題の肝となるのが「i段目からi+1段目に移動するときのその段の線の書き方は何通りあるか」ということである。

このパターンは段によらず一定なので「各段において、列jから列kに移ることができる線の書き方は何通りあるか」というものを求めてあげれば良い。

二次元配列で持つとすればi => jの移動の総数はnum[i][j]となる。

W-1本の線が存在するかどうかはW-1ビットの数値で持ってあげるとよい。隣り合うビットが1になるものを排除するにはどうしたらいいかなーと考えていたところ、TLで「i & (i <<1)がtrueなら排除すればいい」というものを見つけた。頭良すぎでは。

あとはダメなものを排除した全パターンにおいてi => jの移動が可能なnum[i][j]をインクリメントしていけば良い。
もう少し詳しく言えば、それぞれのパターンにおいて縦線につく横線が0本ならnum[i][i] += 1をし、横線があれば、その横線によって移動する先をjとしたときnum[i][j]+=1, num[j][i] += 1をしてあげれば良い。
一番端の縦線のみ少し条件が違うので注意する。

W = 8の時(i,j)要素がこんな感じになれば正しく計算できてると思われる。

21 13 0 0 0 0 0 0
13 13 8 0 0 0 0 0
0 8 16 10 0 0 0 0
0 0 10 15 9 0 0 0
0 0 0 9 15 10 0 0
0 0 0 0 10 16 8 0
0 0 0 0 0 8 13 13
0 0 0 0 0 0 13 21

当然、2個以上離れた要素では0になっていることがわかる。

そろそろDPに慣れていかないとなぁ(毎回言ってる気がする)

2018-10-31

C++でnCkやnPkを全列挙する関数

競プロ

n!通りの順列を全列挙する関数はnext_permutationという備え付けの関数を使えばできたが、next_combinationなるものはどうやら存在しないようだった。
例えば「N個の要素からK個選んだ時の和」などを考えるとき、combinationのパターンを全列挙したくなる時が出てくる。
きっかけになったのが以下の問題。この問題だとNとKが固定されているのでこんな大げさに考えなくてもいいのだが、知っておいて損はないだろうと思った。
beta.atcoder.jp

関数の実装方法について考察している記事がいくつかあったので自分で一から作ろうかとも思ったが、実装がわかりやすく直接貼り付けていい感じに動くものが見つかったので今回はそれを使うことにした。時間があったらじっくり考えます。
参考にしたのはこのページ。
stackoverflow.com

以下がサンプルコード。NとKの値を入力するとN個からK個選ぶ組み合わせを全列挙する。

#include <bits/stdc++.h>
#define rep(i, m, n) for(int i = m; i < (n); i++)
#define print(x) cout << (x) << endl;
#define printa(x,n) for(int i = 0; i < n; i++){ cout << (x[i]) << " ";} cout << endl;
#define printa2(x,m,n) for(int i = 0; i < m; i++){ for(int j = 0; j < n; j++){ cout << x[i][j] << " ";} cout << endl;}
#define printp(x,n) for(int i = 0; i < n; i++){ cout << "(" << x[i].first << ", " << x[i].second << ") "; } cout << endl;
#define INF (1e18)
using namespace std;
typedef long long ll;
const ll MOD = 1e9 + 7;
typedef struct{
    int x;
    int y;
} P;
typedef struct{
    ll to;
    ll cost;
} edge;
typedef pair<ll, ll> lpair;
template <typename Iterator>
inline bool next_combination(const Iterator first, Iterator k, const Iterator last)
{
   /* Credits: Thomas Draper */
   if ((first == last) || (first == k) || (last == k))
      return false;
   Iterator itr1 = first;
   Iterator itr2 = last;
   ++itr1;
   if (last == itr1)
      return false;
   itr1 = last;
   --itr1;
   itr1 = k;
   --itr2;
   while (first != itr1)
   {
      if (*--itr1 < *itr2)
      {
         Iterator j = k;
         while (!(*itr1 < *j)) ++j;
         iter_swap(itr1,j);
         ++itr1;
         ++j;
         itr2 = k;
         rotate(itr1,j,last);
         while (last != j)
         {
            ++j;
            ++itr2;
         }
         rotate(k,itr2,last);
         return true;
      }
   }
   rotate(first,k,last);
   return false;
}

int main(){
    cin.tie(0);
    ios::sync_with_stdio(false);
    ll N,K;
    cin >> N >> K;
    vector<ll> v(N);
    iota(v.begin(), v.end(), 0);
    do{
        printa(v,K);

    }while(next_combination(v.begin(),v.begin() + K,  v.end()));
}

next_combination関数がメインとなる部分。この関数を通した後、先頭K要素を取得することで今回求める組み合わせを全て出力することができる。

なお、iotaは指定した数値から始まる数列を生成する関数。原始関数のι(イオタ)が由来だとか。
この関数を用いるとN!の全列挙ではTLEするようなケースでも組み合わせを求めることができる。
試しにいくつかの(N,K)でやってみたところ、(20,10)や(100,3)程度なら高速に動作した。
オーダーがどれくらいか見積もることができなかったけど、Nがそれほど大きくなければ $O(N^K)$ くらいで動いている気がする。
誰かちゃんとしたオーダーがわかる人がいたら教えてくだされ。

追記:
next_combinationで生成された、先頭からK個の数列がCombinationということは、その部分数列(ソート済み)をnext_permutationにかけてあげればpermutationの全列挙も可能だということに気づいた。
先ほどのコードのwhile文のところを

    vector<ll> v2(K);
    do{
        rep(i,0,K){
            v2[i] = v[i];
        }
        do {
            printa(v2,K);
        }while(next_permutation(v2.begin(), v2.end()));

    }while(next_combination(v.begin(),v.begin() + K,  v.end()));

みたいにすればv2にはnPkの全列挙が入るね。やったね。
計算時間はK!倍になるのかな、いや律速はnext_combinationだからそこまで変わらないのかな。よくわからず。

なんか全体的にもっと速い方法がある気がするなぁ。突き詰めてくと面白そう。

2018-10-30

MacでDockの日本語表示が文字化けしてしまった

ふと自分のMacのDockerのtooltipをみたらこんな感じになってました。
f:id:yuji9511yuji:20181030223213p:plain
文字化けですね。何やらunicodeっぽい何かが出てきてしまっています。

原因は突き止められていないんですが、変わったことといえば自分のポケットWifiを自分のMacBookに接続したことくらいなので、多分その時に自動的にインストールされたドライバとかが原因ではないかと思われます。

とりあえず、ググって上の方に出てきた

$ killall Dock

こいつをターミナルで実行してみたが解決せず。

そのあと別のページにあった「/Library/Preferences/com.apple.dock.plistを消してDockを再起動」を実行したら直りました。つまりこんな感じですね。

$ rm /Library/Preferences/com.apple.dock.plist
$ killall Dock

これ叩いて念の為Macを再起動してあげればうまくいくと思います。
Speed Wifi nextのドライバには気をつけましょう...