KtyaのHOJの記録その2
2026/8
- （上に新しいものを書いてみます）
- Problem 0322 14->13(best) 12Bsolver ステップ数が足りてなかったっぽい。他の二問もそれかもな
- Problem 0231 49->45(単独best) ギザギザ系の数値関数。いろいろ工夫をしていたら最終的に4変数になった。
- Problem 0666 34->33 パーツ選びが大事っぽいけど及ばず
- Problem 1190 48->37(単独best) 縦方向に取るパーツを用いていたが、横方向の方が移動などが少なく済むし、3倍関数系ともすこし相性が良かった。
- ちょっと更新サボってました、考察はそこそこしてたつもり。数式系の記事も作成中です。
- Problem 1276 17->15(best) solver 再帰解があった。この付近難しい問題集まってますね
- Problem 0663 71->58(単独best) 数値関数使った(n歩、n倍）。こういうので威力を発揮すると面白いですね。
- Problem 0134 62->57 棒立てる方法でちまちま圧縮。互除法も別手法もノータッチなので考察の余地がありそう。n歩、m歩をまとめて実行、的な関数がまだわからない。ついでにProblem 0980を考察してn歩右、m歩右をすこしだけ考えたが1Bしか縮まず。
- Problem 1995 75->63(best) ちょうどIOIが開催されていたらしい（偶然）。[ みたいな形のパーツでうまくなぞる。不人気ですがbestに追いつくのは全く容易ではなかった。
- Problem 1384, Problem 1086 どちらも+1Bで80万ステップoverの答えが存在することを確認したが、肝心のbestはヒットせず。ステップ数なのか、多重再帰なのか、数値なのか、漏れなのか、solverのtestが必要そう
- 25Bくらいの未ベストを考察するより、長文やる方が成果でるなあ。
- Problem 0153 83->76(単独best) もともとの経路のままで更新。後半を無理やり再帰に乗せる、上側をslsベースで取る、sXYXsを用いる、という方針。パーツ吟味などちゃんとしていないので、もっと縮むと思う
- best率95%乗りました！正直すでにかなり厳しいですね…2か月前と比べて、やった時間に対する成果がかなり少ない状況
- Problem 0184 38->36(単独best) 互除法に二倍関数入れたやつ。もともと経路でいいことに気づけていたので、その分で単独bestになったと思われる
- Problem 0370 19->14(best) solver たしかにスカスカだしまあまあ規則正しいのでsolverで倒せちゃうのか。ちょっと悲しい。
- Problem 0771 79->75(best) 大きな関数はそのままで、n歩を定義していろいろ書きなおしてbest化。あまり時間かけていないのでもっと短くなりそう
- Problem 0828 28->27 数値関数がいいと聞いて書いてみたが、おそらくヒントとは異なりそう（実行部分がb(26)b(26))
- Problem 0838 27->26(best) 四倍関数+命令、という書き方だったけど、四倍は命令つけず、二つのパーツを同時に表せる関数を用意して書いた。正方形で塗りつぶす際にsssrで書くとうまくいかなかったのでズラしてssrsを用いた。
2026/7
今更過ぎるけど、新しい成果を上に書いた方が見やすいよな・・・
- 特に嬉しかった成果を太字にしてみた。
- Problem 0589 20->19(単独best) solver ♯みたいな形で塗りつぶしている
- Problem 0425 33->32(単独best) 33B,34Bが元々いっぱいあったが、一つだけとあるテクで縮められた
- Problem 0553 47->46(単独best) コードだけ
- Problem 1052 38->32(best) いい数値関数を探してなぞる。二倍関数とパーツを両立するように書く。上の方を取る方法でだいぶ迷走して33Bから困ってた（三変数で後ろにパーツくっつける方法などなど）が、二変数のままで後半をそこそこ綺麗に描けた
- Problem 0415 _misakiさんが言ってた三変数の方の28Bも見つけた。こっちもテクい
- Problem 0265 43->42(best) 後半を書き直したらなんか縮んだ。長文はこういうの多そう
- Problem 1667 29->27(単独best) 今見ると縮みそうでしかなかったのでトライ。コンテスト系は全然結果を出せず、本気を出した上位勢との差を痛感する場という印象で、特に2nd HOJ festivalは「勝てるわけがない」と一番感じた大会だったなあ。
- Problem 0686 26->25 結構考えたけど全く分からない。今の解き方だとどれほど都合の良いパーツでも21Bになるように見えるのでそもそも方針が違う・・・？
- Problem 1315 32->28 もともと再帰でやっていた。フィボナッチ長の一辺のパーツを育てて小で大を挟む関数を使いまわす。辺のパーツ構成時にちょっと寄り道をすることで正方形の内側も塗りつぶせる。向き調整が甘いのか1B足りず
- Problem 1660 18->17(best) 例のsolver作った
- Problem 1795 26->25(best) slsとsrsだけで、という大ヒント活用 点対称じゃないの知らなかった
- Problem 1391 30->26(単独best) 「割と綺麗な経路」が見えた。（パーツとしては一種類で、つなぎ目の移動を少なくする）大きなパーツで少ない成長なので書き方に困るが、結局再帰。27Bらしきものを経由しなかった。
- Problem 0589 19->18(best) solver ステップ数の関係で漏れてた。縦6をいい感じに乱発してるな
- 競プロでAIが超難問を解いて人間を凌駕していて、HOJみたいなパズルゲームを純粋に楽しく他者と競えるようになるのも時間の問題なのかなとか思ってしまった。「最強のsolver」や「答え」があったらそれを見ていないという保証はできなくなり、自己満足の世界になるので。
- ちなみにAWTFの実況（？）配信のMCがchokudaiさんとmasさんでHOJer的にもアツい。
- Problem 1907 26->25(best) 関数のrを前に持ってきて、パーツの順序を変えることで、二変数関数を使えるようにする。確かに見落としだけど、lXXみたいな向きが先頭に来る関数は初めからそれだけ使う前提で経路組まないと忘れる
- Problem 0011 17->16(best) 特殊な初項 この手のパーツいじりは_misakiさんの単独bestをチェックしていて鍛えられた
- 暫定的ですが、best数がトップタイに。復帰してから結構増やしたな。詰めてて気づくbest率99%とかいう異常記録
- Problem 0270 28->27(best) snukeさんが数学問題に分類してた問題でこれがあるのを忘れてた。rsrrsrを二倍関数で圧縮する部分とlがうまく両立しないのが悩みだったけど、数値を調整すればいいという話だった。毎度lを4回呼ぶ感じ。
- Problem 1013 35->34(best) もともとssssXssXとpXqを用いて書いていた。メインを二変数にして、pXqも少しいじって34B もう1Bくらい縮むかも？
- Problem 1328 19->18(best) 再帰 特殊な初項で長方形の形にrrを入れてうまいこと全部取る。r+実行部だな
- Problem 1888 28->27(best) 12B構文応用 3変数目に成長を記録する感じになる。数列探しもそうだが、実現する数列の最後を調整することで実行部が減らせる。28Bはa(X,Y,Z,W):YWa(sX,YXXXX,Z-1,Xr)という関数を使ってた。
- 12Bsolver、いままで数列だけ切り取ってたのと、クレイジー系の検索が漏れ気味だったので大改修中（といいつつ最近更新されている問題達は12B構文まわりじゃないかもしれませんが）
- Problem 1016Problem 2009Problem 2010Problem 2011 15->13(best) 12B構文 1016みたいな問題をチェックできるのがすごいし、2009~2011の存在を思い出せるのもすごい（すっかり忘れていた） ところで全部ほぼ同じ解に結果的になってしまったのは悲しい。
- Problem 0248 38->35(単独best) if文をどう埋め込むかばかり考えていたけど、まさかのメイン部分が流用できた。盲点だった。結局37Bは踏まず。実は工夫し方がたくさんある問題なのかもしれない。
- Problem 0171 37->36(best) 上の副産物。偶奇分けのやつは面白いけどこの方法には使えない。0248と比較するとmasさんとは答えが違いそうなので、まだ圧縮余地がある？測らずも15年前の自分のコメントと同じ状況に戻った。
- 数式(数学？)系全部bestになったと思う。まとめておこうかな。
- 更新祭りで嬉しい悲鳴
- Problem 0230 が 15B ってマジですか？半分に圧縮するのは結構前代未聞ｗ
- Problem 2004,Problem 1532,Problem 0884 13,13,14(best) 12B構文続編 のクレイジー12B構文に記載していた「a(T):[1]a(AT+B)[2]a(CT+D) a(E)」について、a(CT+D)の後ろに命令が付くケースをすっかり見逃していた。
- 部位固定探索の時の設定を変え忘れたままだったのを修正。ちゃんとしたプロンプトなしで雑に投げると気づきにくいバグを埋め込む可能性あるな。
- Problem 0877 28->27(単独best) いくらpracticeとはいえ、この手の28Bでこんなに大量に並ぶ訳がないですよね。
- Problem 0011 16->15(best) solver ステップ数ちょい多め
- Problem 0011 15->14(best) solver ステップ数ちょい多め 乱歩チャンスのある問題を一斉摘出するコードつくろうかなあ
- Problem 0230 30->15(best) solver これは検索をかけようとすら思わなかった。割と奇跡的に見える。30Bはa(X):XXXXssを使ってました。
- Problem 0919 18->14(best) solver 18Bもsolverだったけど、検索サボってたらしい。人力では23Bまでで、その時はa(X,Y):XYXYXXssXXとかいう苦労の跡が見える関数を使っていた
- Problem 1086 がsolverで見つからないな… もうちょっとsolver強化が必要かも。12B構文の場合、パーツ選びやパーツの場所にセンスが試されるな（14Bならその辺も全自動にできそうだけど）
- Problem 0466 34->30(単独best) 多重再帰。まあまあいい感じに書けた。
- Problem 0491 46->45(best) 数値関数をちょっといじった。今まで両方に突起を出していた（+++みたいな)が、片方だけ(⊥⊥⊥みたいな）になった。
- best率 94%乗りました！
- 久々にまとまった時間を取れる＆モチベーションがあったので、放置していた数値長文の勉強と試行錯誤（solver作成）をやっていた。と言いつつほぼグラフパス探索の動作を待つ時間だったかも…
- Problem 1508 241->240(best) パスがよくなった感じではないので、まとめ方？
- Problem 1509 231->216->215(単独best) s,rを並べるタイプのやつで書いてなかった。直線が多く、歩数がそこまででもない場合はこちらの方がよいのか。パスがよくなくて219Bを踏んだ。一般の盤面に対するs,rの個数の最小化や、7文字の先頭がsになるバージョンなどなどの兼ね合いは試してない。ちゃんと検索したらもっといいパスがあって更新。
- Problem 1511 234->219->218(単独best) 同上 パスがよくなくて221を踏んだ。ちゃんと検索したらもっといいパスがあって更新。
- Problem 1507 250->248(best) s,rs,rrs,rrrsを並べるコードで。なんとかパスを見つけた。
- Problem 1707 97->84 s,rs,lsを並べる。(r/rr/rrr)lls という関数を作った。1B足りない。
- Problem 0510 210->207 木構造じゃないやつの調整がまだダメダメ。sの個数最小化でたどる方法を考えるのだが、厳密にやるととんでもない時間がかかるので適宜人工的にやっている。このmapに関する経路だけずっと探索するコードを動かすのも一案か
- Problem 0127 122->91(best) s,rを並べるやつ。これも経路探索は手でやらざるを得ない。305文字の経路あったけど、もうちょっと多くても91Bにはなる。この方針で縮めるには297文字くらいまで減らすか、全く同じ塊で移動するかの二択で厳しそう。
- 本当は互除法回りもちゃんとsolver化していろいろ試すつもりだったけど、ながらでやっていたら全然捗らなかった。結局、数値長文は残った非ベストが自作問なので自分で自分を苦しめている展開
- ようやく非ベスト残り100問切りました
- Problem 0489 108->104(best) s4つの間に向き並べる方。一旦妥協。
- Problem 1762 15->14(best) 2変数solver こんなのあるのか
- Problem 0658 18->17(best) solver 18をsolverで見つけてから特殊な初項。検索漏れてたし、そもそもパーツ検索していたので引っかからなかった。普通といえば普通なんだけど、自分はこのマップ見てこれは出てこないですね。
- Problem 1765 17->16(best) solver 二変数 絶妙
- Problem 0538 74->70(単独best) 既存のやつそこそこをいじった
- Problem 1618 14->13(best) 数値solver。この見た目で二歩系じゃないのか
- Problem 0455 28->27 フラクタルで。400番台あと1B…
- Problem 0975 18(best) solver 見つけたら自動投稿するようにしてたので気づかなかった。問題名の命令とは異なるけど、挙動は一緒（左に往復する）なので変数変換したら一致するのかな？
- Problem 1442 19->18(best) 19Bができてたら18Bもできるだろというぐらい自然な解。コピペしてたから見逃してたパターン。
- Problem 1468 29(単独solve) 結構前にズレがややこしすぎるのでHerbertEditorで無理やり対称性があるように塗り替えて考察してから放置していた。久々に取り組んでみたら、灰マスを踏まない＋イレギュラーな部分をきれいにとるパスを偶然発見できて、そこからスルスルと全体パスが決まった。二種類のパーツで取っている。29Bにするまで結構苦労したのでもしかしたらまだ見えてないのかも？ともあれ長年未解決のものが倒せてうれしい。同じノリでProblem 0931やProblem 1439もたまにやるけどあまり進捗はない（Problem 0931は将来性ありそうなパーツは見つかっている）
- えっ、Problem 0304 が解かれている！？！？？しかも20Bで？？
- Recentでドデカ成果が並んでるとこわい
- tozan氏の問題はなんだかんだ解がちゃんとあるので、HOJの問題の中で解の存在が不明なものってProblem 1797だけですかね？こんなにたくさん問題があって1問だけって相当民度高いな
- Problem 1714 17->16(best) solver 灰マス踏まないので検索はしやすい（灰マスを踏まない系だろうと検索前に推測するのが本質かも？） 前にも書いた通りなぜか1マス上にはみ出る。
- Problem 0824 26->24(単独best) もともとの自分の解が割と工夫可能だった。ステップ数とんでもない… 1714でいろんな解を探してそれを応用する作戦はうまくいかなかった。
- Problem 1183 18->17(best) solver 特殊な初項で圧縮するタイプだけど、圧縮する元のコードが違っていた。
- Problem 0371 16->15(best) solver 検索漏れてたな〜 こんなのあるんだ 人力では難しそう
- Problem 0667 18->15(best) solver 18Bはa(X,Y):ra(sX,Y-1)srXrsで。確かに Problem 1762みたいなのがあるとわかってから検索すべき問題ではあるなあ。
- Problem 1023 19->18(best) solver もともとa(X):XsXa(slsrsXlsr) a(l)を参考に内側をフラクタルで埋める1変数解だったが、結局solverで制約つけて検索。全然違う経路でびっくりした。毎度中心にもどるのね。19B解もsolverで見つけたものとはいえ、そんなに不自然でもないので、こっちが先に出る人もいそうなもんだけど。
- Problem 1068 16->15(best) 12B solver 2歩ベースで。結構変なやつしか出てこない。探索しきってないのでまだ縮むかも？
- Problem 0510 207->206->205(best) 結構考慮するべきパラメーターが多くて難しい。結局256にssls的な向きを一個含むものを割り当てる方針で205に。s4個区切りにした時にssssが出てこなくて、sの個数が最小のもの、をもう少しちゃんとやれば縮みそうだけども、面倒だな。
これだと別の突起部分を取れていないし、別の突起部分をもう一種類パーツ作って埋めようとしてもイレギュラー部分が出てきてしまうのだけど、もっと直線的に処理することを考えたら、類似した二種類のパーツで埋められそうなことがわかり、適当に調整してたらそれらも合わさって埋まるやつを発見した。こちらは制限byte数がゆるゆる（おそらく出題者もテクニックがない？）。ズラされまくってて見えづらいのが悪意満載ですが、Problem 1468よりは人間的でまともな経路でした。灰色の枠内を全部通ります。
- Problem 1439 はパーツすらめどが立たない。意外とProblem 1496なんかは直線的でわかりやすい系の問題なのではないかとにらんでいる。
- そういえばtop50内の人間でbest率が80%台の人が一人もいなくなった。あと10数問ほど倒すとひたすら単独bestを倒さなければならなくなり、一寸先は闇。
2026/6
- 今までで一番理想的な時間の割き方してる（息抜きに気が向いたときに1時間ぐらいやる感じ）
- Problem 0566 27->25(best) 二変数で書いていたが、命令も込めた。10年前ほど前にもらった「関数が弱い」のヒントがようやくうまく使えた。
- Problem 1331 27->26(best) とあるテク 自力で解いたけどよく見たら_misakiさんが答え書いてくれてた
- Problem 1339 22->20(best) 向き調整できないと思っていたけど、向きの付け方を前後で入れ替えたらできた（良い向き調整が存在した）。
- Problem 1715 21->19->18(best) 1変数solverで19B その経路を見ると先に灰マス通りながら左側を取ってから一周していたのでそれを参考に直接書いた。
- Problem 1720 30->28(best) 行って戻るだけじゃなくて4歩進むのもまとめて書けるように関数を作る。一番シンプルに作れば後ろにr(もしくはl)がちょうど4つありますよね。
- Problem 1148 17->16(best) この辺の問題は全部snuke theory （数値多重再帰） Problem 1151もそれかと思ったけど作問者が違った
- Problem 1180 52->51 Hilbert curveの特定の段階の書き方が�‘鵑銚澆い妨討唸腓Υ愎�作る��一つの関数で向きを入れてもう片方を呼ぶ際はrrをつける��'rとl相当の変数を作り入れ替える��再帰で構築し、特定の数値だけ呼び出す、といくつか選択肢があって、� 銑�どれも向き調整があるのが面倒。今回は�△鬮�'にしてパーツのつなぎ目（20歩以上進部分）で再利用ができて1B減った。Problem 0075 のコードは確かに短くなりそうだけど、�△僚颪�方をしようとすると初項の表現が出来なくてうまくいかない。。
- Problem 1184 22->21(best) 多重再帰。再帰の実行部分がXXrYYrXXrとなっていたのでそれは縮む。
- Problem 0025 25->23(単独best) 前からワンチャンあるとは思っていたけど、縮んだ！古の問題なので挑戦者多いと思うし、大分嬉しい。解法としてはフラクタルで、実現したい数列が作れない(か、大損になる）なと思っていたところがよく考えたら作れた、という感じ -> マップ全体がフラクタルのパーツの一個になるようにする。5n+2ではない。
- Problem 1671 27->26(best) 向き調整と数値関数使いまわしパーツ作るところはいまだに苦手意識ある
- Problem 2042 19->18(best) 2043ができててなぜかこれができていなかった。多重再帰でパーツを使いまわす。切れ目の認識がむずい。向き合わないと思っていたけど左右対称じゃないので逆回りにすれば調整できる。
- Problem 0845 26->25(best) 命令を四倍にくっつけたいけど、そうすると無駄が発生してしまうので変数を挟むことで回避する。
- Problem 0920 25->22(単独best) 再帰でなんか合うやつがあった。未だに経路不明。
- Problem 0292 33->32(best) 直接書いた。フラクタル系でよくある、初項のrrを書かなくて済むやつ。
- 単独best集計プログラムがすぐに作れる。いい時代になった。
- Problem 0190 24->21(best) これまでは左、右、真ん中の順で取っており、ssXXXXを用いていた。経路は変えず、関数を改良。10歩と2歩がメインなのでssXXXXが強いかと思いきや、パーツの形や向き的に二変数の別のやつの方が強いのは盲点だった。
- Problem 0983 41->35(best) 前半と後半の数列の構造が似ていることに着目するのはできていたが、途中で止めるために3つ目の数値変数を使っているのが無駄だった。後半に長さの制約がないのでcを定数として(X+Y,Y+1,Z-1)は(X+c-Y,Y-1)と書く方がよい。途中の13歩連打を関数の後ろに仕込むのは昔の解でできていた。
- Problem 0838 28->27 前の解はおそらく想定解で、長さnの正方形をフラクタル的にくっつけたパーツで再帰で埋める。今回は3*3の正方形を埋めるパーツを使って直接書いた。1B足りず。
- 「直接書く」という表現は違和感なく使っていましたが、確かに用語ですね。初出は2011年のmasさんの雑記？
- その他数問考えたけどあまり成果はなく
- best率93%乗りました！
- Problem 1463 21->20(best) 21Bの時とほぼ同じ関数を使っているのだけどなぜか得している。21Bは実行の最初でa()とか書いているのでそこが無駄なんだろうな。
- Problem 1504 32->30(best) 12歩を超えない数値調整をしているところから、成長回数に着目して14,8,6,5,4・・を作るために12B構文を使っていた（数値変数は一つで済むけど、-4倍から4倍の間では実現できなかった）。もともと「n歩ずつ成長させて12歩を超えない」なので数値変数二つ使った双曲線っぽい成長の方がよい。数値を求める部分は生成AIに投げた。r+実行 という答えもあるなあ。
- Problem 1113 25->24 渦。いい感じに位置があった。1B足らず。
- Problem 1660 20->18(best) 二変数solver コード自体は人間的に見えなくはないけど無理
- Problem 0011 20->17(単独best) solver 人力で見つけた20Bはお気に入りだったので残念
- Problem 1027 33->29(単独best) sqrt(n)歩進む関数と、144から平方数引いていく関数の構成が似ている(a(X,Y):rsla(X-Y,Y+2)lsrとb(X,Y):**b(X-Y,Y+2)）のでこれらがうまく合わさる解法があるとは思っていた。Problem 0840の24B解と近いことをしたらうまく一つにまとまった。もっと変な解もあるのかも？ x^2+y^2<=144の規則でテクニカルに書けたのでかなり満足。
- 数学っぽい題材の問題は残り約数カウントの二問だけかな？厳密には素数のやつをちゃんと数式でbest化していないけど。
- ふと「新しい黄緑増やせるのかな」と思ったけど、現状だとProblem 1278を解く以外自力で黄緑を増やす方法はないらしい。（ちなみに32Bから縮まない）
- Problem 0192 更新できそうなアイデアがあったが条件に合う最小の数が342で無理だった
- Problem 0283 25->24(best) 三倍関数まわりで。壁使わないと聞いていたが自分の解は使っている。向きの調整でrrをうまく括り出せた感じ。
- Problem 1225 35->33(単独best) 昔の雑記で「まだいけそう」という表記があったのでチェック。コードだけ見て縮めた。元々無限ループと関数定義がどちらもあって使いまわせてない感じだったので関数側に変数増やして直接書く感じに変えた。
- Problem 1322 27->26(単独best) 昔の雑記で「まだいけそう」という表記があったのでチェック。元々の作り方だと工夫があまりできなかったけど、sXsという真ん中を成長させる作り方じゃなく、XsXと両端を成長させる作り方にするといい感じに。すぐ単独じゃなくなりそう。
2026/5
- お久しぶりです（テンプレ）
- 生成AI使いながらsolverを改良した。
- solver自体の改良に使えるのはまあ自然なんだけど、経路発見とか、圧縮に効くよい関数の発見とかに活用できないかと考えている。使いこなせてないな。
- Problem 0248 39->38 if文/剰余判定/約数カウント/main と分けていたが、真ん中二つがいい感じに合わさった。合わせるときに剰余判定の途中経過が約数カウントに影響を及ぼさないように「1度だけ実行」という機構を入れる必要があって、そのために変数を追加した。あと1Bについてはif文(a(X):s)は相変わらず浮いたままなのでそこがポイントなのかな?
- Problem 0253 30->28(best) (93+3n)/(3+n) という式が想定解で 2変数でg(A,B):f(A,B)sg(A+3,B+1)という書き方をしていたが、(93+3n)/(3+n) = 3 + 84/(3+n) なので、A+3側は定数にして3の分をあらかじめ仕込む、というだけだった。（pastaさんの「4歩下駄はかせる」と全く同じ）
- Problem 0296 22->21(best) 特殊な初項で、3変数版の解をいじる形。メインパーツにおまけパーツをくっつける際に、変数を増やしたことで組み込み方が実は複数ある。このうち、初項に入ってしまっていた向きを消せる調整がある。「ssslsr」というパーツ側に、成長記述の「ss」を使うのかと思っていたけど、それは無理。
- Problem 0516 29->24(best) 4倍を使いまわすのでなく、4回に1回成長する、というのを書く。さらに、4回に1回成長するのを再帰ではなく数値で書く。こういう書き方をする問題は殆ど無い（a(X):sa(X-1)的な物を使う）ので、割と初期の方が思いつきやすい、という感じでしょうか。
- Problem 1023 23->19 1変数solver久々に動かした。いい感じに往復しながら渦上に取っているが、構造があんまり理解できない。このコードを多変数で書くのかな？
- Problem 1025 30->29(best) とあるテク（弱）の復習
- Problem 1440 17->16(単独best) solver まああるよね
- Problem 1941 15 いつの間にできてたやつ
- best数が1600を突破！結構シンプルなことに気づけてないケースが多い。
- 自分の様に「久しぶり」を繰り返すプレイヤーにとって、拡張機能のmemoが神すぎる。数年前の思考や試したことがメモってあるので。
- Problem 0753 30->28(単独best) 経路はそのままで、いい補助関数が使えた。
- Problem 1814 28->26(best) 1815と類似して渦っぽくとるというヒント？から。直線の途中にslsr入れてうまく灰を避けているけど、これもっといい解ありそう。
- Problem 1936 31->29(best) srsslsパーツで取る
- Problem 2053 27->25(best) 1936と同じ補助関数、結局再帰でやった。直接でもできるらしいが・・・
- Problem 0667 20->18(best) 太く中心に戻ってくる渦の数値関数使いまわす問題かと思っていたけど、もっとシンプルに同じ関数で2パーツ配置するだけでいい。向き調整の分は圧縮できる。
- HOJって15年も経ってるのだな
- 1500番台をメインにチェック。黄緑がとても多く、実は苦手意識のあるページかも。
- Problem 1189 27->26(best) _misakiさんが得意な、成長させない数値関数の手法（n歩n倍両立）
- Problem 1553 24->22(単独best) 二変数の再帰で書いていたが、初項がどちらもrrだったところを育てているパーツ側を使い回すことで誤魔化す方向で描き直したらなんか埋まった。1マスだけ取れなかったり真ん中1行だけ取れなかったりして調整にやや苦労した。太いパーツなので類題には使えない方針だった。
- Problem 1569 31->28(単独best) 12B構文 いつ22歩行って戻るのか、というのを12B構文の数列として表現。いい数値がヒットしたおかげで（？）単独。「12B構文」と言っても対象とする数列をどれにするかの選択肢があるのが悩みどころ。
- Problem 1567 44->40(単独best) 以前の考察で原始根かつ7乗との和が最小のものという考察で47,_misakiさんからのヒントで (-a)^7=-a^7を用いて直接書く方法で44だった。「原始根かつ7乗との和が最小のもの」の部分で23に近い数字を負の数として記述できることが完全に盲点であった。(ここまでで42B) そのあとはn歩の関数に命令をうまくくっつけて「棒を立てて戻る」部分を構成する。向きが上手いこと記述できる絶妙な関数を見つけて40Bになった。（ちなみに、負の数の部分の気づきについては生成AIが間接的に活かせた）
- Problem 1998 22->21 a(X,Y,N):Xa(YX,Y,N-1) 的関数を使って記載。22のときはその構造になんとなく気づいていたが、うまくまとまらずパーツを直接書いて再帰していた。成長させるパーツがs,r,lというところなどが他の手法の存在を示唆してそうだけど、思いつかず。
- 数値関数と命令を混ぜたやつ、非常に強い手法なのに、存在に気づいたのがかなり後なので考察漏れが大量にある。
- Problem 0290 22Bまで作れた。あと1Bだが…
- Problem 1572 35->33(best) いままで4変数で1/x計算用に二つ、成長用に一つ、if文用に一つとしていたが、if文用の判定は計算のところを無理やり使う形にできる。命令用の変数に変えて、二倍を実現できるようにした。
- best率92%乗りました！
- Problem 1541 25->24(best) 5倍関数で。他二人と違いそう
- Problem 1555 29->24(best) 誰も雑記を書いていない問題。渦系の数値関数で結構テクいことをしているので他の人とは違いそう。とはいえ、揃う問題にはとても見えないので簡単なものを見逃しているっぽい。まだまだ縮むんでしょうかね。
- Problem 1682 20->19(best) XssX を使う。rssrssrssをra()a(r)a()としてしまっていたが、これは損している。
- Problem 1717 21->20 a(X,Y):sa(X-1,Y)lYを用いた。壁も使っているし綺麗にかけたつもりだが、bestじゃないのでまだ認識できていないか…
2023/7
- パソコン新しくしたついでにsolver動かしてみたりして久しぶりにログインした。
- 数式系とsolve0人にちょっかい出すだけの人になってる。
- 今流行の生成AIと組み合わせて探索を狭めたり効率の良いsolverを作ったり自分の思考を真似たコード生成を行ったりできないかなあ
- Problem 0184 40->38 互除法に無理やり二倍関数を詰め込んで圧縮した。数種類のパーツを並べる手法でいいのないのかなあ。あと1B
- Problem 0270 29->28 rsrrsrの無駄の解決と曲がるのが両立しなかったけど向き入れ込むだけでよかった。あと1B
- Problem 0171 -Problem 0248 再度考えたが進捗なし。if文周りが下手っぽいんだけどいい感じにならない。
- Problem 0285 48->47 パーツの成長に向きを入れ込んで1B圧縮。逆順でも縮まないなあ。。
- Problem 0285 47->43 47B解の5変数関数定義は１行のやつはパッと見よさそうだけど、曲がるためだけの変数を何度も書いていて無駄っぽいので、ビットカウント部を分離して関数を3個にしたら縮んだ。if文(i(X,Y):Yみたいなやつ）を一度しか使っていないのがいかにも無駄だけどなかなか微調整が効かないな。。
- Problem 1943 20(単独solve) ヒントに倣ってパーツを追加したsolverをとりあえず作った。（２変数のYに指定したパーツを入れるだけ）検索したら22Bで引っかかったが、lrみたいなのが含まれてたので普通に20Bになった。灰マスは通らない。経路はまあ予想外で人間的には解きづらいかなあ。
- Problem 1472 24->21(best) 長さの差が2の長方形をたくさん書く方針だったが、よく見たら正方形でもサイズがでかくなった時に隙間を取ってくれることに気づいてbestになった。回る向きとかも大事。imagine cupは想定よりも数周期分多く実行した結果をmapにしがちだな。
- Problem 1467 26->25(best) 0から考えたらいけた。渦で挟んだのを無限に繰り返す方針。26の時は数値関数を使い倒してた。正直縮みそう。
- Problem 0569 best solver 多分前つくったやつだと見逃してた。X+X+cのcが0になるので縮んだみたいな感じ。
- Problem 0526 best 実行部分XXでも検索できるようにいじって検索。
- Problem 0630 best 再帰、自力でやった。細かい調整がむずかった。今までは数値関数使いまわし。
- Problem 0857 best L字のパーツの縦育てるのと横育てるのを分割してあとは数値と向き調整。l+実行なのでまだ行けたりするのかな。この手の成長の調整が複雑なタイプは数値がよさそうなんだな。
- Problem 1800 71->65(単独)
以前の解釈は「2以上n未満の最大の fibonacci num を引いていき、2残るときに棒を立てる。255超えてしまう分は、あらかじめ233(fibonacci num)を引いておいて対応する。」という方針。fibonacci num を引く過程で、1を引いてしまうとすべての数が2に行き着いてしまうため、2個前のものとペアにすることで処理していた。
該当する fibonacci num は高々1回しか引かれないことを利用して、書き直した。
Xが今調べている数、YとZを fibonacci num の組として以下のような変更をした。
a(X,Y,Z):a(X-Y,Y,Z)a(X,Y-Z,Y-Z-Z)b(X) (二つ目の項はY≧Xで実施,bはXが2のときのみ実行)
f(X,Y,Z):f(X-233,Y,Z)a(X,144 55)f(X+1,Y-1,Z)lf(X+1,Z,Z-1)
↓
a(X,Y,Z):a(X-Y,Z,Y-Z)a(X,Z,Y-Z)b(X) (二つ目の項はY≧Xで実施,bはXが2のときのみ実行)
f(X,Y,Z):f(X-144,Y,Z)a(X,144,89)sf(X+1,Y-1,Z)lf(X+1,Z,Z-1)
こうすると、同じ fibonacci num を何度も引くことがなくなる。また、1を引いてしまう問題については、「1以上n未満の最大の fibonacci num を一度だけ引き、途中経過が2になる」ことと「2以上n未満の最大の fibonacci num を引いていき、結果が2になる」ことが同値なので、これで圧縮が効く。Xに入る数によっては途中経過が何度も2になるため、従来のコードと挙動が異なる。
加えて、if文を二倍関数にすることでrsrrsrの無駄と引き換えに実行時間を（指数関数的に）増やす方法で圧縮した。数値選びに少し苦労。
- Problem 0285 43->41(best) 「if文が無駄だなあ」と言っていたけど、ただ変数増やしてそこに入れればいいだけだった。。向き＋実行みたいになっていて、「逆順にしたら縮んだ」の仕組みを導入できていないので、そこ次第ではさらに縮むと思う。
2022/12
- 年末急にHOJがやりたくなる
- Problem 1239 25->23(best) 三倍＋向き 多分作問者想定解。分かってしまえばかなりシンプルなコード。偶然答え登録したのが同じ日だ（１１年も違うが）
- 単独ベストが作問者というやつを狙撃したいけど、まあ当然難しいね。
2022/3
- 別ゲーやりたくて回してたsolverを止めたため進捗がほぼなくなってしまいました
- best率90、数式系、気になる再帰系を倒した関係でモチベがあまりないというのもありますが、いつか長文系もうちょっとトライしたいなとは思ってます
- Problem 1387 21->20 逆順に sovlerで変な答え探せば縮むかも？
2022/2
- Problem 0722 18->17 丁寧に書き下して、いい感じに再帰。
- Problem 0700 直接書いても28になるのかー 絶妙な関数とか経路認識がありそうなものだけども。。
- Problem 1028 45->39 n!をn+1回 足すのではなく、n+1をn!回足すことにするとnの更新用の変数が減らせる。
- Problem 1551 39->35 上の方針に加えてsnukeさんが紹介している変数の順序を変えてNLE回避するやつを適用。前から処理するからこういうことできるのか〜（脳死でコピペしてたため、自分にとっては新テクだったのは秘密）。n歩を中に入れて一行にするのは、従来の手法で保存用として使っている変数を削っている関係で無理だった。
- 単独best集計を依頼 変な文章で依頼したらコンパイルエラーを指摘されてpますstますさんに依頼したことになってしまった（？？）
- Problem 0265 46->43 XsYsXを使ったらわりとあっさり46くらいになって、そこから使い回す部分の選択や経路に少し工夫。単独で喜んだら一瞬で抜き返されてなぜかテンションが上がってしまった。
2022/1
- Problem 0578 27->24 数値から再帰へ。調整がちょっとむずい。
- Problem 1504 33->32 12B構文で変数を減らしたものの。。足りない。
- Problem 0405 24->23 数値で書いた。絶妙に再利用ができず無限ループになってしまう。
- Problem 0667 21->20 数値関数再利用で。18????
- Problem 1032 30->28 結局再帰で縮んだ。Problem 0404と同じ圧縮。
- Problem 1765 21->18->17 solver まだ可能性ありそう。
- Problem 0527 52->51 数値関数で書いて雑に変数増やしたらあっさり51Bになった。右下は後回しにして中心に戻らずとってるのがポイントかも。まだ縮むのでは？
- Problem 0912 23->22 見落としと言われればそうかもしれないけど、見落としやすくて苦手な圧縮だった。
- Problem 0498 34->32 灰マス突っ込むと関数を簡単に使いまわせるのか。直接書きました。無駄がありそうに見えちゃうけどそうでもないのかな？
- Problem 1512 47->45 多重再帰とpXqした まだ縮むかもしれない？→多重再帰の意味がなかった。pXqがうまく使いまわせるようにパーツを調整。
- best率90%! モチベ少し控えめになりそうです。
- Problem 0981 19->18 二変数solver部位固定 賢いなぁ。。
- Problem 1357 22->20 模様乱歩＋特殊な初項 wwvwwさんの雑記を見る感じ全然違う答え？
- Problem 1271 28->26->24(単) 模様乱歩+特殊な初項 惜しいやつがたくさんあって調整とパーツの統一が悩ましい。こちらは多分27の人たちと方針自体は一緒かな。一マス埋まらない気持ちを共有したいやつ。今回はメモに惜しいやつが書いてあったのでそれを流用。->もうちょっといい奴が向き調整の末発見できた。
- 模様系（≒同じ形が敷き詰められている系）の問題リストが欲しい。。
- Problem 0229 22->15 一変数solver オン会でも行けそうだなと思ってたやつ
- Problem 0933 未->17 ステップ数多い 灰マス以外全回収 かなり人間的だけど解ける気がしない。対角線部分を無視して拾う方法と対角線を拾う方法を別に考えればワンチャン？imagine cupは傾向的に灰マスはあまり踏まず、コード自体は人間的なものが多いのかな。未solveに活かせるといいのだけども。
- 関数展開する際に1stepカウントされる仕様っぽい。関数の展開回数が多すぎる問題は普通の再帰だとあまりないけど、数値乱歩とかだとそこそこ影響ありそう。
- Problem 1470 未->20->18(単) 一変数solver 灰マス踏まないです。このコードで出題するとして、このmapにするのはさすがに出題が下手だなと思ってしまうが。オン会などで自分の未solveのヒントもらいまくった分こういうので成果を出せたという点は嬉しい。
- 1300番台緑一色すごすぎる 長文でない非ベストがたくさんあるなあ
- Problem 1393 22->20 とりあえず横槍入れてみた。21がわからなかった。もっと縮みそう。
- Problem 1174 Problem 1310 Problem 1311 なるほどn歩を使うのか。再帰にこだわっていた。1311とかはワンチャン縮むやつがあったりしそう
- Problem 1495 未->20(単) solver なんか出てきた。灰踏みません。 コード自体は理解可能ですけど、まあ不可能ですね。。a(X):XXXXa(sXl)というやつの亜種です。
- Problem 0133 25->24->22->20 一変数solver パーツ指定。これだけ対称性が高いならまあまあやりたい放題ということで
- Problem 2072 Problem 0414 16B(19B)いやこの認識はすごい というかそこが初期位置の方がHOJ的には自然なのが意外すぎる。 オン会で「最初に３歩進みますよね」と言っていたのは経路的に３歩進んでいるだけなのかと思ったのですが本当にsssa(*)みたいな書き方をするんですね〜
（ちなみにsolverで検索しました。一変数も特殊な初項の二変数もありますね）
- Problem 0409 縮んでいる！？考察せねば
- imagine cup迷宮入りしてた三問を教えてもらった。単独潰してしまう&経路発想に重点が置かれている問題なので解いてしまうか迷いましたが、結局投稿。降参した問題だということはちゃんと書いておきます。
- Problem 0926 54->38->35 全部再帰でまとめて取るのではなく、二回に分ける。規則認識自体はあの図でできていたのに単純なことに気付いていなかった。。ちゃんと解けるべきところまで行っていたので悔しい。best化少し苦労したけど、まだ縮む可能性はある。
- Problem 0928 未->39->32->30 長さ3の正方形書いて進んで右に曲がるというパーツを３回使って何周もすると何故か埋まる。何周もするのが盲点であった。こちらは自分の力のみでは絶対に解けないなと思った。最初配置方法が下手だったけど四個とって後ろ向いて何歩か歩く、というのを３回やると綺麗に埋まった。四倍と三倍の関数でbest化
- Problem 0933 実は検索をかけていたんだけどステップ数が足りてなかった？ 灰踏まない＋片方がパーツ育成というところから再度検索中
- Problem 0926 54->38 全部再帰でまとめて取るのではなく、二回に分ける。規則認識自体はあの図でできていたのに単純なことに気付いていなかった。。
- Problem 0928 未->39->32 長さ3の正方形書いて進んで右に曲がるというパーツを３回使って何周もすると何故か埋まる。何周もするのが盲点であった。最初配置方法が下手だったけど四個とって後ろ向いて何歩か歩く、というのを３回やると綺麗に埋まった。
- Problem 0082 21->20->19 大きい方からやる渦関数使い回す。あの作り方でずれる分も使い回すことでうまく修正できる。
- 0番台緑一色！！ ただ0000があるのでちょっと怪しいか。
- Problem 0646 25->22->21模範解答かってくらい綺麗に全部取る答え。最初数値でやってたけど再帰でも大丈夫。四隅のパーツ取るやつで真ん中の十字も取れちゃうという。
- Problem 0217 32->31->30 結局外側とってから内側取るやつに戻した。対称性がないのでどこから始まってどこから抜けるかで調整が変わってくるのが難点。
- Problem 0424 33->32 直接書く系で一変数＋向きで33にしてたけど、ちょっと違う関数で32になった。そもそも縮みそうだなと思ってはいたのでいい機会ではあった。
- Problem 1600 18->17->16 灰マス結構踏む18Bがあって、それに特殊な初項が使える。パーツ構成的にもっと実行時間をかけてワンチャンあるやつを試すと通る。位置が合う理由については全くわかりません。。XsslssXrs→rXrsXXXrって変数変換的な操作から導けるのかなあ
- Problem 1714 18->17 2変数solver 灰マス踏まなさそうだなと思って条件変えたらすぐ出た。出たのはいいけど、原理が全然わからない。なぜはみ出る？？
- Problem 1928 21->20->18 数値で書いていたのを直接書く方針に変更。直角二等辺三角形を拾っていく方針。ただ、最近見つけたあの手法が適用できる可能性もある。
- Problem 0808 23->22(単) 当時は模範解見て「こんなの無理だ」と思って完全に諦めていた記憶があるんですが、真っ白な状態で再チャレンジしたら縮んだ。
- Problem 1053 65->63(単) 既存の答えいじっただけ 長文は後回しにしちゃってる（後回しと言いつつ勝てる気がしていない）
- best率89%! そろそろsolverができる仕事もなくなってきてかなりキツい。。単独を投げ合う争いみたいになっている。
- Problem 1883 -Problem 1884 24 確かにまあまあシンプルな書き方だった。以前のはわりと自然な三変数関数で今回はパーツに適合した二変数関数 三変数の方が自然な発想に見えちゃう。
- Problem 0808 22->20 えっ！！
2021/12 その２
- ここ二ヶ月だけでだいぶ更新してて、モチベの波の激しさが見える。
- アルファベットシリーズは残すところあとRのみ！ 数式系と長文系以外のあらゆる技術が詰まっていると言っても過言でないぐらいに全問題が完成されているシリーズ。緑化したい。
- Problem 0430 20->16(単) 20Bは12B構文に二変数目を生やすことで無理やり打ち切って実現していた。さすがにこれは無駄だらけなので、近い発想を用いて、12B構文で成長するパーツを保存して適切に配置することでまさかの16Bにまで圧縮できた。19Bは多重再帰(snuke theory?)らしいのでチェックしておきたいけどわからない。数値やパーツの調整が少し難しかった。講座を書いたことでこの辺の理論が脳内で整理されたのが良い方向に作用しているようだ。
- Problem 0440 30->28 misakiさんのヒント通り、再帰でとる。再帰で都合よく書くためにいくつか工夫が必要だった。補助関数ともうまく適合してなんとか28Bになった。これが何もないところから出てくるのはすごすぎる。
- Problem 0434 20->16(単) Problem 0430 の系。これで縮むやつ結構ありそうだな。
- Problem 0419 24->23 数値の方の24B解にもう一個変数増やして、「両端から同じもので挟む」を実現する。塊だけじゃなくて、パーツのl 21歩 l と l 9歩 l についても縮められて、結果的に23Bになる。こういう圧縮が効くんだなあ。Problem 1244ではできなくてこの問題ではできる、というのがヒントだった。
- Problem 1481 30->28 多重再帰のお勉強に。書き直したらわりとすぐにbestになった。
- Problem 0432 色々試しているけど縮まない。 試しているうちに多重再帰への慣れが出てきた。
- なんとかRank1位になったけど、向こうの白見ると余力の塊な感じなので実感が全くない。まだbest率も全然ダメですね〜。
- Problem 1176 28->20(単) 普通にギザギザ3個パーツで乱歩検索。一瞬で出てきてびっくりした。みんななぜか検索しようとしてなかったやつ。12Bの乱歩をベースにしていて、灰マス踏まないです。
- Problem 0740 33->27 成長をうまくずらすと十字パーツ6まで+8歩、十字パーツ2まで+4歩がかけて、パーツ間の移動も数値関数使いまわせる。bestはわからない。。
- Problem 0926 59->54 無理やり解いてるだけ。多分何かに気づいてない。無駄なパーツの連打、変なパーツ移動が多すぎて大変なことになっている。
考察した時の画像を一応共有
- Problem 0282 56->52(単) 以前雑記に書いた方針で「[K/10]下に行って[K%10]上に行く 的な関数の効率良い生成方法」の部分でだいぶ怪しいことができて圧縮に成功。初項の処理がわからないのでいまだにllsa(-,...)みたいな実行になっている。
- デカい点数の問題ばっかり考察してる。自分ポリシーとしてはbest率の方が重視したい(bestボーナス、みたいなのがあってもいいと思っている）んだけど、戦うためにはsolve数方向に頼ってしまう。。
- 本当は多重再帰系と数値系に時間割きたかったりする。
- Problem 0588 srsとlslで雑に検索(sをsrs,lをlslと変換する感じで大丈夫） 結局一変数ので済ました。数値の可能性も複雑な再帰の可能性もある。
- Problem 1087 初項に入れておけばいいのに無駄なことをしていた ふつうにf(X):XXXXf(Xss) f(-) で書ける。特殊な初項で21B
- Problem 1348 長さ測るのが難しいやつ。結局投稿してた答えに多重再帰が使えた。
- Problem 1445 パーツの育て方を間違っていた。初項のパーツを三倍にしていく戦法でやっていたが、2個ずつ増やすだけでいい。
- Problem 1467 何にもわからない。渦関数をちょっと使いまわして単独ワースト回避。
- Problem 0915 いろいろヘタクソだったので経路そのままで数値関数を改善。特殊な初項でパーツ間の移動をよくしたのと使い回しを増やして23B あと1Bはわからない。
- 多重再帰構文！！ キター！ ゆっくり消化しよう。あえて変数を生やすやつが下手くそなので練習が必要。
- Problem 0195 sとr並べる互除法。互除法solverっぽいものを作ろうとしたけど、全部を圧縮するやつはまだ作れていない。。最後は無限ループでギリギリsolve 壁をうまく使って向きを削ればもうちょっと縮むのかな。問題名的にa(X):sa(X-1)srみたいな関数でなぞるのかなと思ってたこともある。→というか、sとsrを並べるという択もあるか。
- Problem 1782 bitの1の数が偶数の時棒を立てる。最初めちゃくちゃ下手な書き方で110Bくらいになったけど、「bitの1の数が偶数の時棒を立てる」関数をメインとは別に作って繰り返しまくっていた変数の分離に成功。中心の方は256以上の数値への判定になってくるので、128以下と129以上で分けてます。
（一応今の解は使っている数値255超えてないはずです。）
- Problem 1800 とりあえず解いた。nに対して2以上n未満の最大の fibonacci num を引いていく作業を繰り返し、2残るときに棒を立てる、という規則。1782と同じで単純にどっかで区切ればいいのね。if文使いまくってるのでその辺がうまく圧縮できるのかもしれない。オン会でちらっと見たmisakiさんの答えとは全然見た目が違う気がする（そもそも233とか144とか55とか書いてなかった気がする）
- Problem 1277 lssrslsrsslsをパーツになぞる。31Bが量産されて困ってたがなんとか30Bで解けた。
- Problem 1279 1/4周ごとに sXlsr と lsrXs を互除法で選択する方針 + 後半無理矢理再帰でひとまずsolve 全体を無理やり再帰で書く方針もありそう。一応 sXlsr or lsrXs みたいなパーツで構成されているけども、成長の規則が謎すぎる。True Spiralというぐらいだしr=aθ的な式に乗るのかとも思ったけどよくわからない。この手の作問者単独系の中では一番まともな問題（というか経路が明らか）なのでなんとかしたいとは思うけども。。
- solve者3人以上の白は潰せた！次は2人のやつですが、流石にキツいのばかりですね。以下個人的なメモ。
- Problem 0928 何となくなぞれそうなパーツは見つけたけど、埋まらない。
- Problem 0946 a(X,Y):a(lX,Y-1)X的なのを使い倒すんだろうけど、いいのが見当たらない。どうせ8以上だと同じパーツ繰り返すので探索範囲狭いはずなんだけども。。
- Problem 1239 互除法であるみたいだし頑張ってみるか。想定解、数値解じゃないかなあとか思っている。
- Problem 1278 これは意味がわからない。 この灰マスの配置的に乱歩ってことはあるのだろうか。。
- Imagine Cupの二人solveを結構たくさん取ってるの偉いな（自画自賛）。過去の努力が見える。
- 覇王との差はこれらを解いても埋まらないので、ちゃんとbest化を進めるしかなさそうだな。
- Problem 0942 イレギュラーなところをめっちゃ下手くそに取ってたのでいろいろ頑張ったら24Bで更新！→別のことをしている間に更新返しされてて楽しい。そもそも経路見えてない説ある。→久々にリアルタイムで争えているのが楽しくて頑張って更新返した！まだ縮んでもおかしくないので震えながら待ちます。最近勉強中（？）の数値関数系でやりました。
- Problem 0917 向き調整とパーツへの適用を考えて追いついた。もともとパーツの共通部分を置換しただけだったからまあ妥当。
- Problem 0947 最初のオン会でいろいろヒントもらったけど結局数値解の延長線上にあるやつで解いた。再帰という噂でしたが。。
- Problem 0988 42->31(best) ��3x+1の処理の時に2で割った後の変数使いまわしていたけど３変数目を作って圧縮(40Bくらい？）��n歩の関数にif文つけて圧縮(37B)��そもそもn歩進むのも一緒にできることに気づいて一行の関数になって圧縮。メイン関数は f(X,Y,Z):ssf(X-2,Y+1,Z+6)以下略 という形なので奇数歩進む時用の調整変数を付け加えてあとは調整。曲がるタイミングとか一歩増やすタイミングとかやりようがあるけど31と言われているので見つけやすかった。
- Problem 1107 意外と経路の種類がありそうだけど、まあ普通にT字みたいな感じで縮んだ
- Problem 1114 とあるテク（弱）
- Problem 1290 ヒントに従って色々テクが使えそうな形に変更してなんとか28B 直接書いた圧縮がお気に入りだったけど確かにこっちの方が色々やれるんだな。まだ網羅的な吟味をしていないのでこの問題で技術を習得したい。→たしかにあっさり26になった。。難しい技術使う方は別問題で頑張らないと。
- Problem 1681 リンク先のmasさんの答えの一つをいじって圧縮した。もっとありそう。
- Problem 0010 やーーーーーーっと倒した。結構ヒントをもらっていたのに全然活かせてなかった。当然考えたことのある経路のはずだったんだけど、全部同じパーツで行こうとしすぎてた。一変数で壁を使います。HOJの問題で一番時間費やしたと思うけど、この手のがこんなに時間かかってしまうんだよなあ。（この解よりもProblem 1802の方が好き。）
- 「見落とし」にも文字通りのパターンと異常に難しいパターンの二種類の意味があるようだ。
- Problem 1712 なぜか難しい関数を使って損していた
- Problem 0930 経路あってたけど向きで損しまくっていた
- Problem 1805 二変数solver 言われてみればこれで実現できるか
- Problem 0515 0歩を実現するために扱う数字にX+1の変数変換を行って数値遷移をX+Y-1と書いていたけど、5-Xの変数変換を行うとスッキリかけた。
- Problem 0553 既存の答えをちょっといじったら47Bにできた。いい関数を使ってるなあ。
- Problem 0898 二変数solver
- 12B構文続編を執筆。とあるテクの方は全然使いこなせてないので最近ようやく理解してきた部分を列挙した。
- Problem 0439 再帰で位置調整をうまいことする23Bがあって、それを実は22Bにしても位置が合うという話。23Bの方がそもそも出てきていなかった。
- Problem 0637 数値関数で埋めた。
- Problem 1718 勘違いをしていて、数値を全部n倍する必要があると思っていたけどそんなことはなかった。だから前に共有した時にmisakiさんの反応が微妙だったのか。赤っ恥であった。
- Problem 0999 _misakiさんのそのままパクった。初項はパーツを軸に射影した感じ。変数増やすとあるテクで書いても縮まなかった。
- 1500best!
- オン会実施 masさんの参加もあって大盛り上がりでした。
- 主に300番代をチェック。以下ボチボチ感想書いていきます。
- Problem 0301 おそらくそんなヘンテコな問題じゃないと思うんだけど、いまだになにもわからないやつ。300と似てるとは思うんだけどね〜 渦をうまいこと数値関数で書くのかな
- Problem 0303 互除法の場合，変数を増やしたバージョンで数値の方をいじると節約できるらしい。数値関数で頑張る方でbest化した。そもそもX歩rX歩rの書き方がいくつかあるのね
- Problem 0304 なんか棒立てる系説を思いついたけど気の狂った乱歩の可能性もあるんだよなあ
- Problem 0306 34Bで並んでるけど結構人によって違った。自分はsrslでゴリ押す系。ただ、一つ前のパーツを使いたくて二変数。masさんはsslsrとsrsslとかだったかな？ 自分の綺麗な経路35Bも供養できた。
- Problem 0310 関数組み合わせる系。自分はpastaさんから学んだやつ。
- Problem 0311 自分だけXsrslXを使っていた。
- Problem 0315 数値関数をパーツにも使い回すやつ。小さい方からやるやつと大きい方からやるやつ二通りある。どちらもきれいな答え。
- Problem 0319 「3回に2回rr」的なものを実現するのですが、フィボナッチ数列の考え方で実現できます。これによって変数が減ります。初項が2,0のフィボナッチ数列をmod 4で書くと「2 0 2 2 0 2 2 0...」となりますよね。
- Problem 0320 masさんと全く同じだった。
- Problem 0324 -Problem 0336-Problem 0340 -Problem 0341-Problem 0346-Problem 0371ワンチャンありそうだと思った。→Problem 0346は15Bsolverで解いた。
- Problem 0328 同じかと思ったらちょっと違った。二変数で書いてます。
- Problem 0331 pastaさんのsolver使って見つけたのに，pastaさんは検索を放棄していたらしい。
- Problem 0333 見た目がゴツい関数を作る。なぜ予習段階で解けなかったんだろう。。
- Problem 0339 masさんは初項を調節したフラクタル構成だった。
- Problem 0350 17Bのすぐそばにあった。向きが減らせる。
- Problem 0349 19Bの二人は手法が異なった。
- Problem 0356 自分は三変数。pXqの補助関数が仕事をしている。パーツと成長の調整用の変数をうまいこと減らしている感じ。長文気味だけど、規則が無い30B~50Bくらいのやつより取り組みやすいと思う。
- Problem 0357 大きいのを実行する用の変数Zを用意して、a(X,Y,Z):a(X,Y-1,Z)XZとかいて実行でa(,12,a(,15,a(,10,))的なことをするとある成長の12段階目→ある成長の15段階目と実行できることを利用するらしい。そもそも大きい方だけを数値関数で実行するのが賢いのにこれまでやられたらすごすぎて。 後半のsrslの渦へのつなぎ目の書き方が下手なのか、５Bほど追いつけていない。これもbyte数あるけど長文って感じがしない。
- Problem 0359 (x+2)/3 だと思っていたら実は x + 2/3 らしい。確かにa(X,Y,Z,T):Xra(sZ,sX,Y,T-1) la(,,,9)を実行するとちょっと埋まる。この辺の数値関数をうまいこと使うんだろうけど結局互除法の関数でsとl並べたものを無限ループしてます。
- Problem 0361 なぜか変な数値関数の答えがあった
- Problem 0374-Problem 0381 この辺は縮まない系かなぁ
- Problem 0398 これは最初に見つけた人が偉い関数
- Problem 0224 棒立てる系の数値関数再利用 手法の発想はあったけど、向き調整方法がいろいろあることに気付いていなかった。なるほどなあ。
- Problem 0282 以前雑記で書いた部分がmasさんのやつだとうまく書かれているのだろうなと想像したらそうではなくメイン関数内で命令を合成する形で書いていた。確かにその手法だとa歩上b歩下みたいな関数を作る必要がないのか。めちゃくちゃ盲点だった。。
2021/12
- Problem 0081 solverと協力しながら更新。絶妙な答えになった。
- Problem 0302 32Bはおそらくみんな再帰じゃないかな。直接と聞いて関数いじってたら良さげなの見つけて久々にいい感じに単独更新。
- Problem 0415 直接書くとどうしても31Bから縮まなかったけど、斜めのパーツと真ん中の棒がうまいこと合わせて記述できる数値と関数の複合系がつくれて、30->29->28 と縮んだ。真ん中の棒が太さ2なのはこの関数が模範解答なのかってぐらいピッタリ。向き調整とか余計なsの捨て方もあってすぐに28にはできなかった。今までやってこなかったタイプの圧縮なので使いこなせるようになりたい技術。
- Problem 1585 パーツを分解して書き方変えたら短くなって解けた。
- Problem 0368 古くから伝わる悪問。確か壁も使わないし灰マス踏まない直接書くコードだったと思うんだけど、8年前の時点で答えを無くしてたと思うので当然今あるわけもなく。反省の意味も込めて解き直してみたら、相当制限の厳しい問題だった。対称性とか考慮せず、てきとうに攻略。いろんな人を困らせたであろう自覚があるので、問題ページに今回作った自分の解貼りました。誰かが投稿したら合わせて投稿しようと思います。
- Problem 0357 もっと工夫できるのかな。まさに「Bestがこの世のものとは思えぬ短さ」
2021/11 その3
300番台みてます。400番台もやってます。
以下オン会まとめ用スペース
最近自分の中で流行の12B構文関連の数値手法について共有。その後は100~299について情報交換。同じbyte数の時全然違う解だったりするのがとても楽しい。オン会後の進捗とか見ると自分だけ一方的に得してしまっていることが多そうなのがちょっと申し訳ない気はする。講座として多重再帰（とあるテク）、if文消去テク、互除法によるパーツ配置、12B構文の引き算引き算、12B構文クレイジーバージョンなどなどあってもいいのかなと思ったり。
自分の講座書きかけだったり意味不明なこと書いてたりするのが多いので、随時消して書ききらないとな。。特に長文のやつなんて、問題ごとのコメント欄に書けばいいだけの話だよな。関数の分割統一のやつももっといい感じに書けそうだし。
2021/11 その2
やること：(a,b) (c,d)の間に(a+c,b+d) のペアを生成する。b+dが9以上の時は生成をやめる。
��a,b,c,dと調整用変数Nを用いて（a,b,a+c,b+d,N-1) [上にa+c歩下にb+d歩 b+dが9以上ならやらない。] （a+c,b+d,c,d,N-1)的なことをやる。
[]内の実行用にg(x,y):上にx歩行って戻る、下にy歩行って戻る、一つ右に
という関数を定義しておく。
Nは永遠に展開することを防ぐ変数。「b+dが9以上ならやらない」の部分は上と下に歩く関数にダミー数値変数つけてそこに9-b-dなどを書き込めばできる。
この方法だと、関数の初項が(0,1,1,1,N)みたいな感じで0が混じるので、いわゆる分子に相当する部分をすべて+1するように変換。
a+cの部分がa+c-1みたいになる点に注意。左端と右端を実行しないので直接気味に書く必要があるけども、これくらいで多分80は切れるはず。
�∈乎爾髪γ爾鮗孫圓垢襪燭瓩暴藕爐猟汗亜�(a,b,c,d) = (-1,1,1,0)として、前述の実行部の条件に分子に相当する部分であるa+cが-1の時はやらない、というものを加える。
分子相当の部分を+2,分母相当の部分を+1し、if文などでa+c-1を変数に付け足すことで達成可能。すこし調整難しい。調整次第ではあるけどもおそらく70前半にはなる。
��「b+dが9以上ならやらない」のためにダミー変数（もしくはif文？）的なことをしていたが、ダミー変数を使わずに、下にb+d歩行く、の部分に9-b-dを渡し、g自体を上にx歩行って戻る、下に9-y歩行って戻る、一つ右に
とすることで、ダミー変数ないしif文を消せる。これで70は切れるはず。
�ご愎瑤量妓妥験�を防ぐために使用していた5変数目のNを消すことを考える。b+dが9以上ならそもそも関数を展開しない、というように書き換えたい。
そこで��と近い発想だが、分母に相当する b,d を M-b,M-d に変換する（Mは9以上の整数)ことで、「9以上なら実行しない」というのを内包できる。
これで自分は60B解になりました。
�イ修發修�a,b,c,dは8以下なので高々64通りしかない。しかも分母>=分子みたいな条件もある。また生成式もただ足すだけと単純。よって(a,b)を一つの数字で表すことにすれば
メイン部分が変数二つで済む。(a,b)を10b+aとか変換して考える。このとき「90以上でやらない」が「b+dが9以上ならやらない。」に相当
このとき以下が問題になる。
・[K/10]下に行って[K%10]上に行く 的な関数の効率良い生成方法
・ �△任笋辰燭茲Δ塀藕爐猟汗以�法ができなくなるので、実現方法
後者ができていないため結構損して現在57B(llsして色々調整したものを実行している） 前者も下手なので損してそう。数値系の圧縮の際の頭の使い方が今更分かってきたなあ。今まで解くだけで終わり、コンテスト系でコピーして満足というプレーをしていたのは良くなかった。この問題はもう少し考察してみます。
2021/11
- Problem 0840 あ〜〜〜なるほど これはめちゃくちゃ感動した。masさんの雑記の「これはあの辺でぶっ壊れちゃうから無理だよな〜と 思っていた方針が実はちょっと順番を変えたら行けたという話．」がめちゃくちゃヒントだったことに気づいた。
- Problem 0840 向き調整できて縮んだ びっくり
- 麺類solverが天から降ってきたのでいろいろお勉強。
- 品のあるC#コードで、構造や書き方など真似したいなと思った。C#自体は書いたことなかったので動作や書き換えに少し苦労した。コードが綺麗なので読解には苦労しなかった。
- 一関数の部分はアルゴリズムから勉強になった。使いこなせると強そう。
- 12Bのやつは展開部分の改造と本質的な枝刈りが必要そうだった。展開部分は、引き算引き算のケースでうまくいかない実装になっていたので再帰で原義的に変更。枝刈りに関しては、最大公約数チェックしたり実行部分が少ないやつをなくしたりした。あと検索漏れがあるので書き換え。まだデバッグ中で使ってない。->スタックオーバーフローしたので書き方変える必要がありそう
・数値引数が全て引き算で構成されるときは後ろに命令をつける意味がある。そもそも乱歩的なものはこの引き算引き算の構成になるため、これを重点的に調べる必要がある。
a(X):[0]a(X-p)[1]a(X-q)[2]と書くとき、一般的な12B構文と違って、sとrをどのように入れても意味を成すため,12Bだけでも12通り調べる必要がある。
こう見ると12B構文の乱歩はかなり可能性あるな… 13Bにしただけでもさらにヤバいのが増えるので、動作速度的にも枝刈りがとても重要そう。
- これくらいのツールが普及して調べ方や固定方法、枝刈り方法などで差がつくのが理想だけど、これやると低byteの乱歩の理解をサボるようになって、
応用が下手になるというデメリットがあるかなあ。
以下 solver成果。15以下埋まったら新規開拓でピンポイントで探してみたい。
- Problem 0008 二変数 逆にこれできる人がいなかったのがちょっと不思議。考察すれば出てきそう。とはいえ難しい解。改めて素晴らしい問題だなと思う。
- Problem 0382 一変数 15Bの時の類似解で最初ちょっと灰マス踏む。邪魔な分を捨てたり、いい感じに位置があったりで解は人間的だけど解けたらすごいタイプの一問。
- Problem 0200 三変数 masさんの雑記に一~三変数と書いてあるときは三変数説ある。さすがにソルバーを作りましょうって感じの問題。この手の乱歩はもう全部答え公開してもいい気がしちゃうな〜
- Problem 0331 三変数 上の予想はやはり当たっていた。当然人外解なんだけど、想像よりも綺麗に回収してた。まだまだ縮んでも不思議ではない。
- Problem 0957 一変数 人間的。灰マス踏まない。長さ1で近い形を見つければ方向調整って感じか。
solver以外成果 最近solverだけが仕事してて自分は雑記に感想メモるだけの人になってる。
- Problem 2058 こうすると一度だけlという実行ができるのか
- Problem 1982 人力で。埋まり方面白い。
- Problem 0766 多重再帰 この手のmisakiさんとwwvwwさんのチェックしてる問題をゆっくり確認していかないとな。
- Problem 2002 オン会にて話を聞いたときは問題の概要もあまり覚えておらず何も理解していない状態だったが、ようやく問題概要を思い出した。sXXlの19段階目を実行するためにどうするか、という問題の認識で、普通の19を作ると展開中に壊れるため17作って関数に入れるとか小さい数字にして色々くっつけるとか工夫を要するのだけど、もっと小さいの連打でいいよねということか。これも最初に15にした人が1000点なタイプ。
- Problem 1889 関数が下手だった。
- Problem 0943 大きい渦描いた後ちょっと移動して少し小さい渦 再帰ではなく、大きい方から書く渦を二回試すというタイプだった。昔考えたときに今回の方針自体は試していたけど、二個目の小さい渦に移動するときに、右の方に行く必要があると勘違いしていた。左側にも縦につながっているとこあるじゃん！19Bがたくさんできたけど、うまいこと調整すると向き部分が一つ減らせて18Bにできた。未solve撃破うれしい！
- Problem 0431 自分の答えだと見落としだった。
- Problem 0441 これ複数解あったのか。。自分の一つ目の解は縮まないやつだった。
- Problem 0156 渦関数でとるとかいう発想がすごい 発想一つでもっと縮みそうではある。乱歩もあるか？
- Problem 0025 ２５Bがたくさんある。模様乱歩的構成がありそうだが。
- Problem 0197 真ん中のsrsl的部分が奇数個なら縮むんだけどなあ
- オン会でモチベが0からεくらいになっている。 ０番代と気になるやつの情報交換を行った。以下メモ
- Problem 1532 if文込みで３行になっているが、これを２行にするらしい。→なるほど、「特定の数値の時のみ実行される」ように上手く数値調整&実行用の３変数目作成。combinationのやつは数値調整が下手ですぐにはできなさそう。
- Problem 0840 「一度だけ曲がる」を三変数目に数値をつけて実現する。確かに「一度だけ」という要素がif文っぽいと思えばわかりやすい認識だった。24Bは「行って戻ってくる」というのは実現できている。21B考え中
- Problem 0842 自分は最初から「一度だけ曲がる」を三変数目に向きを定義して実装していたためこれだけ短めだった。ちなみに、前回雑記に書いたコードのlをずらす（a(X,Y):Xa(sX,Y-1)lla(sX,Y-1)X)ことで直線を往復するものになるので、これをうまく利用した感じです。
- 840の経路の発想を得た後に数値を使う手法に行けないのはなんか自分の脳みそのセンスのなさを感じた。
- Problem 0947 数値で書いてたけど再帰で頑張る系らしい。
- Problem 1445 前半を一辺4の正方形で書いて後半に外回りに正方形書くとあの二箇所が取れないな〜と思っていたけど、実は前半後半を近い認識で取れたという話。前半の認識の正方形書くところで余計に回ると後半も取れそうな感じの図になって、それを利用して普通に書くと29B。「余計に回る」ところを大胆にして再帰とみなすことで27B。再帰にするやる方が下手な感じはある。
- Problem 0421 実は自分が大昔投稿していた25Bが普通に23Bになるやつだった。下手くそすぎて_misakiさんに介護してもらいながらbest化
- Problem 0812 再帰。若干向き調整難しかったけどこっちが模範解という気もする
- pastaさん「単独bestを出したらバレないように0001を解きまくって隠すテクがあった」←めちゃ笑った
- 以下0番台
- Problem 0011 に存在するjulikさんという方の点数がバグっている上にアカウントが存在しないことになっているので面白いと言う話。ランキングを検索するとJulikさんという方はいるようで（頭文字が大文字）、点数的にダブルカウントされてしまっている？という結論に。
- Problem 0008 zigzagの応用(壁超えに近い）的なコードっぽい。たしかに16B解のssYrrみたいなところは無駄な感じする。普通に人力とのこと。
- Problem 0010 関数が下手とのこと。
- Problem 0011 直接書いてたけど再帰でも似たような感じで取れるらしい。
- Problem 0013 経路が偉いとのこと。
- Problem 0017 昔の解は変数増やして移動と成長の不釣り合いを解決していたけど、真ん中付近に移動して特にずらさず成長させる感じ。移動部分をうまく使いまわせて圧縮できる。
- Problem 0018 関数定義をひとまとめにできるやつ。コードの見た目がこわい。
- Problem 0025 なんか今見たらワンチャンありそうだけど厳しいのかな
- Problem 0048 どうやって気づいたんだ… 最初に縮めた人だけ1000点でいいと思う。
- Problem 0053 ワンチャンオーラ出してるけどよく見ると相当厳しい。
- Problem 0057 パーツ変えたり数値関数使いまわしたり。自分の考察がまだ足りていない一問。
- Problem 0058 変数増やして三倍関数を作って使い回す。
- Problem 0075 変数変換でなんとかなるはずとのこと。少し書き方変える必要があるかもしれない。
- Problem 0081 壁を生かしきれてない解なので要検討。そもそも縮む可能性もある。
- Problem 0082 みんな答え違って笑ったやつ。直接でもいけると。自分のは数字二箇所だけなのでワンチャンありそうに見える。
- Problem 0091 最初の方灰踏んでもよくて12B構文でうまい数列をつくる系。ソルバーを作る必要がありそう。→数値だけ出すならソルバーもすぐ作れる。シンプルなやつだと24B解しか見当たらなかったけど、ちょっと変更するとヒット。これ既知だったのか。あと一通りしかない上に数列もたまたまちょうどピッタリだった。
- Problem 0096 向き合わせの選択肢が実はかなりあることに気付いていなかった。それがわかればあとは数打ちゃ当たるで（）
- 他にはHOJ関連の昔話をして老害を存分にアピールしました。やっぱり人とやるのは楽しい〜
2021/10
- お久しぶりです。
- pasta神の頑張りのおかげでHOJを以前と近い操作感で遊べるらしいです（フラッシュ終わってから全く触ってなかったのでありがたみを理解しきっていないのは秘密）
得点計算とかが停止しているので解いた問題とか縮めた問題の見た目以上の更新が行われないようです。
- Problem 2006 いい問題だった。経路ゲー問題出しまくってたくせにこういうのなかなか解けないという最悪なパターン。最後は関数をなんとか使い回した感じ。
- Problem 2051 この手の出題者単独は経路が認識できてないだけだろうしできると思ってトライするも全然わからず。結局ずいぶん前にやった時に書いた気持ち悪いパーツを気持ち悪い感じに並べる以上の綺麗な認識ができなかった。Problem 1239なんかもそういう系なんじゃないかなと思ってるけどどうなんだろう。imagine cupみを感じる。
- discordで話しながらなんかやるのとかオフ会みたいにできて楽しいかもなと思ったので、id貼っておきます。フレンド送ってください→Ktyaしゃーぷ7525
- Problem 0840 向きちょっと弄れて28B解が26Bにできた。a(X,Y):Xa(sX,Y-1)la(sX,Y-1)lXを変数増やしていじる。
- Problem 0842 前の解は840の28B解ベースで作っていたので当然縮んだ。840全く理解してないのに単独なのは謎 840の答えはここの問題に活かせないのかな？
2020/5
- ぱすた先生に単独ベスト集計依頼をして更新していただいた（何もしないでやらせるクズ）
- 想像以上に_misakiさんが覇王になっていて笑ってしまいました 現役勢の思考みたいなのはいつか聞きたいですね
2018/6
- えっらい久々に開いたら誰にも本質的に解かれていない問題があったのでちょっとだけ考えた
- Problem 2029 L字でL字を書きながら戻るみたいなよくあるやつにさらによくわからないものが付加してる感じだった。パーツ自体も使い回しで綺麗に書ける 適度な時間で適度に楽しめる問題だった まだあと1Bは縮むらしい
- たくさん更新してから書こうと思ってたけどモチベーションが落ち着いているのと時間がなかなかとれないのとでそういうわけにはいきませんでした。多分急にやりたくなるやつなのでまたそのうち
- 前にも書いた気がしますが，僕の投稿した解について気になる部分があるとかモヤモヤしてるとか少しヒントが欲しいとかあればツイッターにどうぞ(Ktya_59)
2017/10
- ガッツリ時間をかけてやれない期間が続くと思うので少し作問&その意図などを書き残しておきます
- そのうち戻ってこれるように精進します
- とあるテク＝1975での自分の別解 新テクなのかどうかよくわからない（昔あった気もした＋本解の発展にも見える） 本解と類似してる点はあるが使い所が難しいのでぜひ開拓してもらいたい
- 使えそうな問題を探すモチベと時間と考察が足りてないのでその辺もいずれ時間が取れたらやろうかなと思ってます
- Problem 1975 とあるテクでa(X,Y):YrYXrYXa(sY,X) が実は圧縮できる a(X,Y):YrYXrYXa(sY,X)r と思うとわかりやすいかも？
- Problem 2014 Solve:長さをしっかり測って成長を調整しましょう Best:とあるテクでYrYYXrrYYXrYYXrを圧縮
- Problem 2015 出来事からてきとうに出題 成長段階を少なくしてアプローチを増やしてみた Best短いですね
- Problem 2016 とあるテクについての問題のつもりだったけどいたって普通の問題になってしまった。まあたまにはいいということで（逃）
- Problem 2017 Solve:タイトルの通りにするだけでやれることがほとんどなくなると思うのでその範囲で Best:とあるテク 短いし入門といえそう Solveの解を縮める感じです
- Problem 2018 Solve:経路自体は単純かなと思います Best:とあるテク（かなり上級な使い方？）
- 2018のような比較的ありふれた形に応用が効きそうなので強力そうですが、使い所が非常に難しそう（というか実験して形を覚えるぐらいしかなさそう？）というのが現時点での感想です
- 他にもいくつか問題にしようかと思いましたがむやみに作るよりはテクを研究していった方がいいかなと思いボツにしました
2017/09
- 五億年ぶりに
- 全く解けないです… 原始人のようなコードしかかけない
- Problem 1975 _misakiさんのヒントとsnukeさんのヒント見てどうも自分の解と合わないなぁと思っていたら別の解が想定解だったというオチ これに気づかず1991がすぐには縮まなかった
…ということはもしかして自分の過去の解はまた別の新テク（？）なのか？
- Problem 1991 上の問題のトリックに気づいたらすぐ縮んだ
- Problem 2002 解いている人がいないのはかわいそうなので解いておいた しかしほぼ同値なコードが通ったり通らなかったりして仕様の理解が不足してる 追記:どうやらそのうち消されるらしいので暗黙の了解で解いていなかっただけなのかな どちらにせよ2001がわかってないので考えないと→やはりあっさりと抜かれた 仕様と戦う感じがProblem 1786っぽかった
- Problem 0018 昔30Bで喜んでた時の解が例の手法で縮むやつだった こっちを経由してないと厳しそう
- Problem 2014 急に作問欲に駆り立てられてテキトーに作った原始的問題 タイトルも関係ない上に塗り方も雑（灰マス以外は全て通ります）ですがお許しを [追記]よく見たらスペルも間違っていた
2016/11
- 二ヶ月振りに
- コンテストの自分の解答は結局発掘してないです
- _misakiさんの新問二問！どちらもとても歯ごたえありました
- Problem 1974 数列をググったらしっかり出てきて笑ったw 最初愚直にヒントに従って24B それを縮めるのかと思ったけどそうではなくある種の引っかけ問題だった．まだ縮む気もするけどとりあえず解けて満足．
- Problem 1975 普通に考えたら15Bでテキトーに試してたら新テク？っぽいものを発見 それを弄ってたらなんかできたw もの凄く汎用性高そうなテクですが自分はまだ使いこなせなさそうです．r+実行部分 という答えなのでまだ縮む？
2016/09
- どうもご無沙汰してましたKtyaです．最近めっきりやってないです…
- 調べた所名前を非公開設定にしていたらしい（記憶に無い）．facebookでの投稿に依るとBlakeさんという方が一位で自分は二位のよう．
- 一応自分のスコアは30000ちょいです（30000超えて止めたので）皆さんどうだったでしょうか？
- コードはメモっていないのでバイト数（これもメモ準拠）だけでも
4B,11B,11B,11B,22B
10B,25B,23B,18B,21B
34B,23B,24B,20B,17B
21B,--B,31B,18B,19B
13B,24B,21B,21B,20B
1:いつも通り．Max5Bには何か意図があるのかなぁ？
2:急に難しくなる．6倍関数で壁を利用したりして19B その後solverにかけて11B
3:2より易しいと思う．まずは普通に書いて13B その後solverにかけて11B
4:3の斜めバージョンと思って18B ぐるぐる回って12B solverにかけて11B
5:アホみたいな書き方で35->32B 別の良い経路に気付いて25B 初項の無駄を削るべく中心に行く様にする22B
6:即座にsolver 10B こういう出題はいい加減やめるべき．逆に想定解が気になる．
7:良問 最初は経路探すところから 良い関数XYXXYXを見つけて24B 関数に命令が無いのが気がかり
8:難問 solveから苦労した まず24B->23B 同じ問題が22B制限で存在すると言う事で粘る
9:四倍関数でてきとうにやって19B XssXで18B
10:特有のズラし問題 ズラして見切りにくくしている分パーツの作り方（どこを始点にするかとか）の自由度が 減るので一度解くと縮めにくいと言うイメージ
５歩+9ギザギザ パーツの並べ方との兼ね合いも見てXYYXYという関数で21B
11:s4つ,r一つ,l一つを並べたパーツを3連打する問題 HOJにも複数出題例あり．あらかたまとめて書ける関数を用 いたもののなかなか伸ばせる気がしない solver視野
12:なぜか真ん中に寄っていない問題．壁があるので直進を止めてもらう様に活用 これも関数に命令が入ってい ないのでやや不安な感じ
13:多分大多数の人が思った事:「これ25より難しくない？」 といってもフィボナッチと二乗ってだけであまり変わ らない
14:HOJをやっていたお陰か再帰的な解が最初にすんなり出てきたので印象が無い問題
15:感想は上とほぼ同じ 作問者側はちゃんとこの答えを導き出せていたのだろうか．
16:やりようがあまりに無さ過ぎる問題．Herbertを始めて間もなければ楽しめそうな問題ではあるけども．
17:このセットで一番難しい問題．微妙に対称性が崩れているのが多分混乱の原因なんだろうか．四隅のみ奇数座 標にあるのも謎．ただ制限byte数がやたら緩いので解かないと差をつけられると思って必死に頑張り中
18:圧縮問題 これもやりようがたくさん合って（自分は）好きな問題．イマイチ納得のできる圧縮が見つからな い問題 30切るくらいが合っても良い筈なんだけども
19:これもとりあえずsolveしたあと割とすぐにsolverに投げた パーツ固定で18Bを発見 まだ縮んでも何ら不思 議ではない．ただこういうのはものすごく差がつく（M/n-M/(n-1))が大きくなる ので要注意ではあった．
20:経路発掘するまでが大変 これは想定解という確信が持てますね．何か適合するテクニックがあるのではないかと思ったけど結局深入りしなかった．
21:まず落ち着いて数を数えてそれっぽいのを試したら半分程回収するやつを発見．それを上下に生やしたら丁度埋まった．結論から言うと何も考えずにsolverに投げてしまうのが正解だった．
22:これはパーツ探し等から結構苦労した．最終的に置換だけで想定解っぽいものを見つけたけどなかなか圧縮に繋がらず．
23:六倍関数をテキトーに使うだけ．これもっと前の問題で良かったと思う．
24:圧縮問題．こういうきれいな模様を上手い事埋めるのにかなり苦手意識が合ったので何回も書き直した．乱歩がありそうなのが怖い所
25:ある意味定番な「最後の問題は簡単」というやつ．
- 全体として:素朴な問題と数値系問題が一つもないのはいかがなものかと．強いて言うなら24？ 殆ど全部答えありきに見える．贅沢ではあるけど出題者も学習して欲しいと感じる．
Summer contest 2016
- 気になる（と思われる）問題の自分の感想をメモる事に
- 5 初期位置やマップのズレに不満が残る問題．つい最近ちょっとまともな経路を見つけたが苦手な部類．
- 7 経路発掘から，多岐に渡る圧縮（初期向きの解決など）があって，とても良い問題．
- 8 このレベルの割に難しい問題．経路がまだ見えてない？
- 9 ひとまず某テクで．まだあるのではと思ってしまう
- 11 壁じゃなくて灰色マスで良かったのではと思ってしまう問題．結構似た問題がHOJにもたくさんあるけどまだ詰めが甘そう．
- 12 これもやりようが多くて困るタイプの問題．これもそうだけど何故真ん中に配置しないのか…
- 17 未solve 対称性が無い箇所が謎すぎる 乱歩なのかなぁ？
- 18 これもまだ甘そうな一問．経路自体は楽ですね．
- 20 何かしら適合するテクがあるかもと思わせる一問
- 22 意外と綺麗に書けたけどそこから縮められていない．
- 24 これは苦手なタイプ．上手なコードがありそう
- 勝負を分けそうな問題のみが残った solvedについてはまだ10問ぐらい不満点が残っている感じ(逆に10数問はもう更新が難しそうな感じ？）勝負を分けそうな問題についてはsolve自体は必須という読みなのでしばらくは辛い戦いになりそう．solverの使い方も吟味しないとなぁ(7/10)
- みんなやってるのかな？とりあえず自分はunsolvedがあと二問 内一つは勝負を分けそうな問題でもう一つがlevel 一桁という… まずはsolvedしておきたいところ(7/8)
- Is it allowed to make the same problems as "Summer 2016 Contest" on HOJ?
For me, it is much easier to check the movement of Herbert on HOJ...
2016/07
:2016/07/10
- Problem 1970 まったく検討がつかない…
- Summer Contest，もうちょっと詳細に（問題番号とかを付記して）状況を書こうか迷う所．
2016/07/05
- 新問ラッシュ！相変わらず脳味噌に良い問題が多くて楽しいです．
- Problem 1963 best 規則見つけるのに若干手間取った．初期位置を合わせるのが難しい？
- Problem 1964 best 最初3変数で書こうとしたけど数値が変わるのは3回だけなので変数が減った ここ最近では一番好きな問題
- Problem 1965 パーツ圧縮技術を問うていると見ていいんでしょうかね？まだ試していない事が多いけど眠いのでまたそのうち
- Problem 1966 特に変な事もせずにスタンダードに もう数捻りぐらいありそうな気もするけども果たして…
- Summer contestをちょっとやってます 得点の形式上ガチでやるならsolverが滅茶苦茶重要という感じがして，元solver難民的にはそこに罪悪感みたいなものが… 問題自体は傾向は偏っているけど面白いと思います
2016/06
2016/06/27
- 雑記更新ラッシュに乗る
- Problem 0184 今までと方針をがらりと変えて40 まだ縮みそうな気もする
- Problem 1962 見た事あるような無いような と言う感じの手法
- 公式コンテスト是非参加したいんですが，これってMacで参加出来るんですかね？どうもダウンロードできなくて問題すら見れない…なんとかしたい所
2016/06/某
- 久しぶりに自分のbest数みたら滅茶苦茶減っててビックリしました！ すごい！
- 90%復帰チャレンジしたいけどできるかな
- 特に1600番台がボコボコですね 一時期solverで何とかなりそうな二問だけって状態だった筈なのに
2016/04
2016/04/29
- ちゃんと「息抜き」として活用出来ているのでそこは良い感じですが宣言には反してしまっていますね
- 一関数solver製作しようかなと思案中 コード生成から面倒だなぁ
- Problem 1740 17 二変数solver
- Problem 0227 32->単独 抜かれていたので抜き返し．32の時は上から8マス目まで移動してそこから右向きに長さn,n,n,13の棒を立てるやつを作ってそれで塗りつぶしていたのでぴったり32と言う感じだったけど今回はそれっぽいパーツを探してなぞった まだ行けそうだけど
- Problem 1634 29->best 潰されてたので 前からちょくちょくやってたけど思った以上に縮まないこの問題
もどかしいですね
2016/04/23
2016/04/20
- 最近あらゆる事に脳味噌全然使えてなくて本当に駄目（ここに書く事ではないけど）
- best率90% 長かった しばらくはsolver以外脳味噌使わないと思います
2016/04/16
- 雑記書き漏らしがある気がするけど面倒だ…
- ただ単にsolverと書いたら1変数を指してます
- Problem 0045 solver まぁ人間的ではないですね
- Problem 0243 solver めちゃくちゃ人間的 出来なかったのを反省 1,3,7のパーツと壁を利用してとりましょう
- Problem 0450 二変数solver 四歩で検索 二歩とかでも試しておくべきかもしれない
- Problem 0479 solver さぼってた
- Problem 0482 二変数solver 思ったよりすぐ出た これはレパートリーとして持っておきたい
- Problem 0535 solver 降参して検索 賢いなぁ
- Problem 0752 solver 昨日も書いたけどbyte数偏ってるやつ検索漏れしてた バグとかじゃなくて良かった
- Problem 0762 solver これ一変数だったのかw というかパーツ一つで良いのか（驚き）
- Problem 1157 二変数solver こんなのあるのか 応用が利きそうだけど果たして
- Problem 1230 solver まぁありそうな変換で出来てた 昔18Bを人外扱いされたけど_misakiさんも出してたようでちょっと共感したw
- Problem 1257 solver ちょっと理解し辛い 15Bでの構成をバラしてる感じか 位置が合う理由はしらない
- Problem 1427 solver たしかに割と人間的だ もっとstep数多い人外解があるかもしれないけど
- Problem 1786 solver よくみたら1779のコピペで行けるんだったw
- Problem 1787 1779のコピペじゃだめなのでなんとかするという問題 テキトーにやったら通ってしまって今更Herbertの仕様を知ると言うw step数の解釈として実行しているものだけじゃなくて，展開している文字列がある一定の長さを超えるとアウトなんですね〜 実行を上手く先取りする事で解決しました 何気に単独阻止
追記：よく見たらmasさんの雑記にちゃんと書いてあった
2016/04/15
2016/04/某
- 新問題出しました
- Problem 1956 一辺15がヒント 棒を立てます 15といえばHOJ的には2^4-1ですよね
- Problem 1957 本当に普通の問題 ターゲットをこうするだけで大分経路見にくくなりますよね
- Problem 1959 前にちょろっと触れたあまり使わないテクに関する問題 タイトル通りに書いて26ぐらいになりますがそこから23を目指しましょう（それより短いかもしれませんが）
- solverはもう面倒だしよくわからないのでいいやという感じ 二変数は結局調べるものを減らせなくて断念 アイデアはあるっちゃあるけど
- Problem 0282 97->87->77 とりあえず数式で解いた 変数が減らせるのかな？
- Problem 0842 48->35 840でフラクタルっぽい方針を思いついたので試したら28Bで絶望してたけどこの問題に関しては上手く適合していたようで縮んだ．snuke先生のヒントを見るに840はスタート地点に戻らない書き方をするのかな？ とりあえずフラクタルっぽく書いてみようとして「１回だけ右/左に曲がる」と言うのを実装したら縮みました もうちょっとで840もできそうですが…！
2016/03
2016/03/31
- Meshでそれっぽいの試そうと投稿したら案の定固まったw
- その間に決め手になりそうなのがsolverで検出されてそわそわしてスマホから解を投稿
- Problem 0762 19B 乱歩の知識が少し増えたので
- Problem 1138 14B solver なるほどなぁ
- つかの間の総合一位！！！！！！！！！実感無さすぎ！ つかの間だろうけど嬉しすぎてスマホでスクショ撮ってしまったw
- 冷静になるともう5000点ぐらい取らないと本質的に一位とは言えないのだよな
今後の課題
- 一変数solverの高速化
- 二変数以上のsolverで成果出す
- 一関数solver
- 迷いの木系のbest化
- Problem 0840を考える
- Problem 0282を考える
2016/03/30
以下全て一変数 solver
- 迷いの木系の問題といたらギリギリでpastaさんを追い抜きつかの間の総合二位！！ まぁ新問に低く見積もっても2000点ぐらいは余裕で落ちてるから本当に暫定的ではあります
- 迷いの木系の問題まったく追いつけない時ともうちょっとの時と二通りあって後者は経路取りなんだろうけど前者が謎 そんな大きく変わるようには思えないけどこれも経路取りなのか？
2016/03/5週
- ぱすた大先生に依頼して単独best表更新してもらった（いつも唐突に自分勝手に要求して申し訳ありません，と同時に対応して頂きありがとうございます．）
- 自分の予想を大きく上回るレベルに単独bestが増えていて笑ってしまった 結構阻止されている印象が合ったんですがこの一ヶ月は人のbest率を削る事だけ考えて緑を再更新しまくってたのでそれが大きい感じがします
- いよいよsolverなんとかしろの声が大きくなりそうな感じが
- Problem 0605 21->16 wwvwwさんの雑記をヒントに．多分同じ経路だと思う．1変数だと17でそれを2変数にした感じです 乱歩的動きの理解は大切だ
- 試しに15B以下未best数えたら100問程あった
- Problem 0096 26->25 25B量産した 何が足りないのだろうか
- Problem 1351 26->best sの個数が多くて補助関数が上手い事使い回せそうだったのでなんとかズラして成功
- Problem 0339 22->best 思った以上に普通だった 一変数．⊥みたいなパーツを利用しましょう．
- Problem 0668 16->best 非常に普通の再帰 昔の答えの方が難しい
- Problem 1271 31->best 昔は渦を書いた後に外側を取ってたがパーツをデカくして縮めた やりようがありすぎる
- Problem 1826 解き忘れ solverにかけときたい
- Problem 0726 29->26->24->23(単独) 壁を利用し忘れていたのでそこをしっかりして26 masさんの雑記の二変数と言うのをヒントにして24 あとはいじって23 加えてヒントを出すと「パーツの区切り目」 未だにBITというタイトルの意味と問題ページのmasさんのコメントの意味が理解出来てない…
- 人の単独それぞれ見てて思うけどすごくプレイヤーの特徴が出ている気がしますねw 特にsnuke先生の単独が一番追いつけない絶望感があるなぁ
- Problem 0230 38->34->32->30(単独) やーーっと撃破！ 右上の白と左下の白でbyte数かさみがちだったけどどちらも同じ解釈で取れるパーツがあってそこで4倍関数を使い回せた
- 0226~0231全best! この6問だけでもかなり難しいですね
- 一瞬だけbest率86%迷いの木全部解けば一時的にpastaさんに追いつくか？ solverをまともにすればいよいよmasさんも視野かもしれない（ほんとか？）
- Problem 0461 24->23 関数が使い回せた これはbest化したい
- Problem 0530 17->best ようやく．惜しい所までできてた 直線とギザギザを同時に
- Problem 0548 23->best 数値だと気付けばまぁ
- Problem 0556 22->best 経路はあってて圧縮が下手だった こういうのはもうちょっと嗅覚よくしないと
- Problem 1019 20->19->best 19にした時点で縮むのはわかっていたけど眠くて向きが合わず断念．翌日案の定縮められていたのでやってみたらできた 上と下の壁の意味ないですよね…？(逆回りを阻止しているぐらい？）
- Problem 1958 テキトー．solver勢待ち
- Problem 0156 44->42 snuke先生が異常に短いシリーズ パーツを上手い事やらないと無理だこれ
- Problem 0824 未->26 テキトーに．これとclimb over wallはよくわからない
- Problem 0830 23->22(単独) 自分の解法だと自明な圧縮忘れがあったw この壁越え系もそうだけどmasさんとsnukeさんがぽつんと並んでいる問題は全く追いつけないか稀によくわからず追い抜くかというのが多いなぁ．天才の発想は似るんでしょうか．
- Problem 0844 未->best 解けたーーー！！良問ですね．初期位置の右に5個白が並んでいますがこれは意味があって，初期位置の右6升目は灰色の方が解きやすかったですかねw 経路がわかった後も初期位置に悩まされましたが書き方を変えて何とかなりました．
- Problem 0980 111->84 とりあえずn歩+r(n=2~9)にそれぞれ名前をつけて書くだけで90代，それをテキトーに圧縮して84 もう5くらいは行けるかもしれないけどそこから先は宇宙
- Problem 1086 27->19 おしい13Bがあるんですね solverに任せたいけど人力でも十分縮みそう
- Problem 1706 21->best 3歩単位でrとlが隣り合うような乱歩って と考えたら当たった solverでも解いておきたい一問
- Problem 1740 未->26 良くわからないので直接かいた
2016/03/4週
- Problem 0334 24->23 な阪関無 手法的にはpastaさんが得意そうなやつで縮めた
- wwvwwさんの活躍もありあと4問！
- Problem 0284 再チャレンジしたけど歯が立たず．数値じゃない長文の中でも一番力入れてるんだけどどうも届かない 経路もあまりへんてこなのには出来ないと思うから純粋に圧縮勝負って感じで悔しい
- Problem 0410 30->26->24->22(単独) なんで25で並んでいるのか謎（全くそれっぽい解に出会わなかった）理解出来ないbyte数で並んでいるのを抜くってのがよくあるなぁ 結構自然な認識で24くらいになって関数を工夫して22に．もっとエグい作り方がある気もしますね(wwvwwさんとか得意そう)
- Problem 0963 24->23 見落とし そもそも問題が難し目ですね
- Problem 0738 25->24 見落とし まだ縮みそうではある
- 単独って付けてるやつはある程度は難しいやつで付けてないやつはしょうもないという感じの使い分けです
- あと1問！とりあえずアレを頑張るか
- Problem 1665 135->116 自分の昔の答えを参考に圧縮しやすくしたら案外あっさり行けた まだかなりガバガバだけど縮んだからよし！
- ついに（まともにやっているプレイヤーで）best率90%以上の人が一人もいなくなった！ かなり性格の悪いことをずっとやっていたのでこれからは気が向いた時に黄緑を考える事にします。。
2016/03/3週
- 直接書く系ならかなり戦えるって漸く自分でも言える気がしてきたけど時既に遅し
- Problem 0419 25->best 直接書いてbestとれた 他のbestの人達は全くの別解法で数値使っているらしい（確かに普段なら単独取れそうな答えではある） ワンチャン縮むんじゃないかなぁ
- Problem 0541 44->41->40->best 関数の分割を上手くして最初の関数を再利用したら41 最後ずるして40 よく見たら逆回りで向きが削れて39（こうなるともはやord2_nではないですがw） 特に難所ないから久々にやったらあっさりだった 前悩みまくっていたのは何だったのか
- Problem 1953 25->best 四倍にこだわり過ぎだった 今まであんまりやんなかった組み合わせの圧縮だったと思う
- Problem 1488 20->19(単独) wwvwwさんがやってらしたので．全く記憶に無い問題で新鮮だった．解法も自分が見つけただけでも4種類(経路は実質2種類?)あったのでもっとsolve者がいても良さそうな問題
色々試してたらちょうど欲しかった数列になるやつを見つけた こういうのは他の人の方が得意そうだけどなぁ
- Problem 1635 24->21(単独) コンテスト中にこういう解が出なかったのが意外 調整に手こずった
- Problem 1012 25->24(単独) 25のすぐそばにあった
- あと6問
- 最近は25B以上の緑を巡回している（性格の悪さ）
- Problem 0357 69 とりあえず70切った 左上の処理が悩みどころ過ぎる 地味に初めて使うテク（というか書き方？）したのでそのうち問題に出そうかな
- Problem 0527 55->54(単独) ちょっと関数に工夫を
- Problem 0732 32->31 ただの見落とし
- Problem 1494 未->best 思っていたよりも大分単純な問題だった
- Problem 0750 こんな経路でも良いと思いついて模索したけど縮まず
- 他4問程チャレンジしたけど縮まず
2016/03/2週
- 新問を三問投下 １回ミスってしまったので番号飛んでおります
- Problem 1952 なんかどっかの問題とかぶっている気がしなくもないけど出題 区切り方ですね 普通に書いても25Bくらいにはなると思います
- Problem 1953 これはテキトーに生成したパーツを綺麗に並べてみただけの問題 よくわからないパーツの圧縮がimagine cupとかにもありそうな感じ
- Problem 1955 壁ゲーをあまり出題した事が無かったので あまり吟味していないのですがもっと縮むかもしれないです
- Problem 0278 未->best ちょっとズレるやつは前から得られていたんだけど調整が出来ていなかった 後ろにある文字を前に持ってきて調節すると言う技をあまり使っていなかった
- Problem 0291 未->best �ヽ謄僉璽弔六�計回りに取る�∧篏�関数の類いは使わない�０貶竸堯，鬟劵鵐箸鵬鬚い拭＼擇賁椶魄媼韻垢襪�19Bで向き違いが出来てくれてなんとかsolve
- Problem 1348 未->best 完全に答え無くしてたので考え直した問題 多分作った時はテキトーに見にくくしてやるぐらいにしか思ってなかったんだと思うけど割と丁寧に考えて解けるタイプだった
- 1329縮むと睨んでるんですがどうなんでしょう
- Problem 0265 49->46 縮んでて滅茶苦茶驚いたんですが辿る順番を変えて関数もよさそうなのにしたらなんとか縮んでくれた 後々やったらより簡単に二種類目が出来てしまった やってて思うけどa(X,Y):XYXとかよりもs,r,l等の命令込めた一変数の方が強いし小回りが利く事が多い
2016/03/1週
謎の集団が突然沸いてめっちゃ笑いましたw
外国のどこかの集団に発掘されたんでしょうか？
何にせよウェルカムです！
ここから新問 典型もあったけど糞問はなくて楽しめました
- best率85%到達！solverちょっと諦め気味なんですが文字列操作ほんとどうすれば速くなってくれるのかな。。
C++の知識はほぼ無いので色々試さなきゃなぁ。
- 最近の問題結構単独で生き残ってますね Problem 1950は冗談抜きに良問だと思うのでやってみてほしいです（とかいってbestじゃなかったりするかも知れませんが）もちろん壁使いまくりで再帰です
- Problem 0011 22->20(単独) まさかのこの位置で更新！！めっちゃ嬉しい！！！（+2点）
- Problem 0502 ->25 ちょっとテコ入れ 縮まない
- Problem 0666 35->34(単独) 意地で単独守った
- Problem 1022 23->best 十字を律儀に二つ作るだけ やっぱ綺麗に埋める乱歩はもっとレパートリー持っておきたいなぁ
- Problem 1061 13->best ワンチャンを試したら通った
- Problem 1158 34->27(単独) 再帰で書きやすい様にパーツを書き直したら27になった 寧ろ30とか31が謎
- Problem 1414 21->19(単独) 前の経路をちゃんと書き直したら縮んだ 単独！
- Problem 1951 29->27 パーツを増やす事で初期位置に理由付けした 補助関数使ってた前の解の方が気に入ってるけども
- masさんのbest率を90％にした
- Problem 0553 49->48(単独) 使えそうな関数を試したら1B縮んだ この辺シビアだなぁ
- Problem 0573 29->26(単独) こういうの（他の人と比べて）多分得意なんだからさっさと取るべきだった 得意っていうか最近だと関数の選択肢がみんな多いから慣れた人が解いたらそんなたいした事無いかも？
- Problem 1297 30->29 テキトーに更新したら案の定あっさり抜かれたw コンテスト問題は詰めが甘すぎるのでコピペして満足したやつは定期的にチェックしないと
- Problem 1297 29->27 snukeさんの解の回収方法を少し変えて28B その後関数をちょっと改造して27B 単独になってくれるかな？
![[PukiWiki]](image/hojwiki.png "[PukiWiki]")
0013_keiro.png
0926.png
スクリーンショット 2016-03-19 1.57.06.png
