読者です 読者をやめる 読者になる 読者になる

ぱろっと・すたじお

技術メモなどをまったりと / my site : http://parrot-studio.com/

その文明はわりと現役です(「女子高生プログラマーの大バトル!〜コボール文明の逆襲〜」を解いた件)

POH Ruby

いやまあ、別にこのBlogはPOHの結果を貼るためのものではなく、
前回から今回までの間にLTをやったりはしていたのですが、
仕事がなかなか忙しくてですね・・・(´-ω-)

さすがに新しい仕事に移って半年だと、
Blogで書けるような新しいネタも少なくて・・・
まあ、LTのネタを書き忘れていたのは単なる怠慢ですが

それはさておき、6回目です

paiza.jp

前回が4月なので、約半年ぶり・・・って、そんなに経ってましたか(lll゚Д゚)

parrot.hatenadiary.jp

4回目くらいで難易度が下がりはじめ、
5回目でパフォーマンスを気にしなくてもいいレベルまで下がってましたが、
今回はさらに下がっていた気がしますΣ(゚Д゚)ガーン

f:id:parrot_studio:20150920103011p:plain

(仕事が忙しくて)着手がだいぶ遅くなり、
今ならもう皆さん解いているはずなので、
今回は答えを本文に書いてしまいます...φ(・ω・`)

緑川つばめの問題

https://paiza.jp/poh/joshibato/tsubame

難易度の表示とか何もなく、実際は「霧島->緑川->六村」の順で解いたのですが、
Blogでは簡単な順に書きます

・・・とはいえ、この1問目はあまりに簡単すぎますΣ(・ω・ノ)ノ

「プロのプログラマ」がこの問題を一瞬で解けない場合、
「貴様、普段全くコードを書いてないどころか、まともに書いたことないな?щ(゚Д゚щ)」
と疑われるレベルでしょう
(逆に、あまりに単純すぎて、何か罠があるのでは・・・と疑ったくらいで)

ただですね・・・「転職支援サイト」で、
このレベルの問題を「最低ライン」として提示しているということ自体、
「プログラムを書けない人」の転職が増えているのかな・・・とも思います(´-ω-)

正直、残すほどのコードではないですが、一応こんな感じで

https://gist.github.com/parrot-studio/8fae30021b17177d4ba4#file-tsubame-rb

六村リオの問題

https://paiza.jp/poh/joshibato/rio

さすがに多少難易度が上がりましたが、ご丁寧にも詳細な計算式が提示されているため、
ただその仕様を実装するだけのお仕事です(´・ω・`)

ただ、「小数」を扱う関係上、数値の取り扱いを間違えると誤差が出ます
私も手抜きしたら通りませんでしたし

https://gist.github.com/parrot-studio/8fae30021b17177d4ba4#file-rio-rb

厳密にいえば、きちっと精度を確認し、
BigDecimalやRationalを検討すべきなのかもしれませんが、
今回はFloatで問題なかったのでこれで

さすがにFloatの方が速いですしね・・・ *1
ただ、誤差で思いもよらぬバグを生み出すこともありますが(´-ω-) *2

霧島京子の問題

https://paiza.jp/poh/joshibato/kirishima

今回のメイン・・・ですが、これも前回よりは簡単な気がします
わりと力技で通ってしまい、アルゴリズム的な小技が不要なので

この問題はとにかく「問題を理解すること」が重要で、
その上で「文章をコードに落とし込めるか?」がポイントであり、
あとはせいぜい効率化を考えるくらいでしょう

ルールに従い、順番に盤面をparseしていって、
ゴールにたどり着けば「Yes」、止まるか外に出たら「No」、
ここまではすぐ思いつくレベルです(効率はともかくとして)

問題は「循環して止まらない場合」です
これを排除できないと、単にparseしていくだけでは終わらなくなります(lll゚Д゚)

要は、「一度通ったところを再度踏むと循環する」ということなので、
通った場所を記憶しておいて、また踏んだら「No」と考えればOKかと

そして効率化ですが、当初は盤面をあらかじめ逆にparseしておき、
「数値が来た時点でO(1)の計算量」的なものを目論んでおりました

ただ、実際は盤面のサイズが大きくなるほど、
無駄な計算が多くなる可能性が高く、コードも複雑化しそうだったので、
単純に「一度計算した結果を覚えておく」程度にしました(´-ω-)

https://gist.github.com/parrot-studio/8fae30021b17177d4ba4#file-kirishima-rb

たぶん、名前のついたもっとうまいアルゴリズムとかあるのだと思いますが、
今回はこれでも0.1秒を切ってますし、気にしない方向で( ゚Д゚)y─~~

まとめ

ということでざっと見てきましたが、
2〜3回目くらいの「TestCase5が通らないのぉぉぉぉっ!(つД`)・゚・。」
みたいな難易度からはすっかり遠ざかった印象です

前回のおまけ問題がそれに近いのかもしれませんが、
あれはあれでガチすぎて手を出す前にあきらめる問題だったので、
「なんとなく手を出したら深淵が待っていた」くらいのが個人的な好みです

まあ、そういう問題を出されると、
一週間くらいはその問題のことで頭がいっぱいになるので、
仕事が進まなくなるのですが・・・Σ(・ω・ノ)ノ



<おまけ1>

具体的なコードと結果を貼り付けておきます(´・ω・)っ

gist.github.com


<おまけ2>

なんだかんだでCOBOLの需要は結構あるはずです

古いメインフレームはハードとソフトが密結合しており、
またクリティカルなシステムで使われているため、
COBOLが読める人がそういう現場で重宝されているからです*3

そんな古いシステムだと、仕様書もないでしょうし、
実際のコードから仕様を洗い出すとかざらでしょうしね・・・(´-ω-)

むしろ、最近危険だな・・・と思っているのはPerlです

Rubyなど後発の隆盛や、現代的なパラダイム(関数型とか)についていけないのもあり、
下火になっていたのはありましたが、それでも使われている場面もあったはずです

なのですが・・・まさかPerlにとどめを刺したのが、
「時代」ではなく「人」だとは・・・Σ(゚Д゚)ガーン

404 Blog Not Found:Disowned by a Dysfunctional Family

*1: C言語レベルで取り扱えるので

*2: つい先日、Floatの誤差でバグが出まして、原因がわからずに数時間つぶれたこともΣ(゚Д゚)ガーン ロジカルなレベルでは間違いがなく、特定の値が来るとおかしくなるってのは、実にデバッグが難しく・・・

*3: 某まつもとさんの会社はCOBOLの人を雇っているので有名です