usakdsteen

ゆうさくですてぃーん

2021年08月22日(Sun)の独り言

の呟きは 84

 < の独り言 | の独り言 | の独り言 > 
  •  #

    転生してから40年。そろそろ、おじさんも恋がしたい。【改稿版】『71』 https://ncode.syosetu.com/n7029ga/72/ #narou #narouN7029GA

    わるいおじさん

  •  #

    実行時間10倍にしてみたが
    まぁ微妙な・・・

    f:id:neetsdkasu:20210822003849p:plainf:id:neetsdkasu:20210822003901p:plain
    •  #

      1.00は26個?
      26/70はだいたい3分の1か?

      まぁ1.00と言っても
      現行BESTが本当のBESTとは限らないから
      現行アプローチで到達可能なBESTではあろうけど
      そのBESTすら確実に取れないという・・・

    •  #

      No.1~No.39やNo.66~No.70は難しいケースが多いから99%未満のがちらほらあるけど
      No.40~No.65はむしろ99%以上は前提で細かいスコアの改善が出来ないと勝ち目がないケース…

      •  #

        前者と後者では
        攻略法に違いがあったりするのかもしれない

        •  #

          前者は見える路が少なく
          後者は見える路が多い

          前者は存在するのかも分からない路を見つける感じ?
          後者は無数の見える路の最適な組み合わせを見つける感じ?

          いあ、違ってそう

          •  (UPD ) #

            前者は負の路にしか見えない大きな迂回路を突き進んだ先に正が見えるなんてことになりそうだけど
            後者は負の大きな迂回路をあえて選択する理由がそんなに無さそうなイメージがある

            •  (UPD ) #

              前者はそもそも他の正の領域同士を繋げられないというところから来るスコアの停滞であり
              後者は容易に他の正の領域と繋がれるから前者のようなスコア停滞はなさそうなイメージ

              •  (UPD ) #

                前者は接続のためだけに正の領域を生贄にする必要がある感じで
                後者は生贄を捧げてまで繋げたい他の領域は無い感じで

                まぁ想像だけど

                •  #

                  どちらもダイクストラによる最短接続が最適ではない部分が大量にありそうではある

        •  #

          正の領域の割合を評価してから
          それにあわせたアプローチを展開するって手法あるかもしれなくもないが
          (コード量・・・ソースコードサイズ・・

      •  (UPD ) #

        小さいスコアの改善がどのケースも必須だから
        その小さいスコアが取得スコアにとってどれだけの割合かが前者と後者の違いで結果として前者が99%未満になりやすく後者は99%以上になりやすい、という感じか

        •  (UPD ) #

          前者にとっての500点の改善と後者にとっての500点の改善は
          取得スコアにおいての割合が違う、というだけ

          •  (UPD ) #

            BESTが6000点くらいだと500点は1割近い改善だけど
            BESTが100000くらいだと500点は1%未満の改善でしかない…

            そして割合としての改善が大事なのではなく
            500点の改善がいずれのケースでも勝負で効いてくるという

    •  #

      ALLBESTTOTALとの比はあまり意味ねーな
      スケールの違うスコアを混ぜるから小さいスケールのスコアが霞む

      •  (UPD ) #

        合計点勝負の場合は・・・
        上位が僅差という場合でもない限りは
        小さいスケールのスコアはそんなに考慮しなくてもいいのかもしれない・・・?(どのスケールに対しても同一のソリューションをぶつける場合においては・・・

      •  #

        そもそも個別ケースのBESTとの差が小さいせいなのが影響として大きいのか・・・

        •  #

          BESTとの差の合計という評価のほうがいいのかな・・・?

    •  #

      いくつかBESTが更新されたので・・・
      まだまだ到達できてない世界が多すぎる・・・

      f:id:neetsdkasu:20210822013955p:plainf:id:neetsdkasu:20210822013921p:plain
      •  #

        No.66~No.70
        もっと高いスコアが出せるアプローチとか
        世の中には存在してそう

        •  #

          この番号帯は特殊ケースすぎる

          •  #

            まぁNo.61~No.65も特殊ケースではあるから
            これらも他のと同じアプローチは最適では無さそう

      •  #

        流石に1ケースあたり50秒もかけると
        70ケースに1時間近くかかってダメ

        •  #

          CPUリソース的にもう1スレッド使う気にもなれないし・・・

          •  #

            2コア2スレッドで論理4コアなわけだが

  •  #

    https://neetsdkasu.gitlab.io/paiza-steinsgate-rankingproblem/?solver=1

    同じ路を何度も接続しようと試みるところからし
    路をメモ化して使いまわすとかするといいのだろうか

    •  #

      さすがにこのソルバではベスト解には至れないようだ・・・

      f:id:neetsdkasu:20210822014006p:plain
      •  #

        ベスト解はこれなのだけど・・・

        f:id:neetsdkasu:20210822014017p:plainf:id:neetsdkasu:20210822014028p:plain
        •  #

          左と右の領域の接続自体は-300の箇所を通さなくてもいいはずなんだけど、これに落ち着くのなんでだろう?

          •  #

            もう一度トライしたら生成された

            f:id:neetsdkasu:20210822013932p:plainf:id:neetsdkasu:20210822014039p:plain
            •  #

              右側のやつ
              コーナーケースの生成過程を勘違いしてたようで
              意味ない領域となっている・・・

      •  #

        キター!

        f:id:neetsdkasu:20210822013943p:plain
        •  #

          数十回くらい回した・・疲れた

  •  #

    さっさとshower time

  •  #

    ブログ
    なんかゾロ目チャンス

    f:id:neetsdkasu:20210822051357p:plain
    •  #

      今日は連続222日で
      明日独り言あれば投稿4444日

      アクセス数は
      いつの間にセルフアクセスで稼いでしまったのか、あと少しで8888アクセス

      投稿数の8888は1ヶ月以上先になるかと・・・

      •  #

        俺以外によるアクセス
        平均すると月1回もなさそう・・・

        •  #

          定期的な検索ボットによるアクセスはあるっぽいけど
          それらは月1回もないっぽい

  •  #

    MADE IN CHINAの衣類って
    某地区が関係してると常に疑ったほうがいいの?

  •  (UPD ) #

    接種証明書て
    体質や持病などの問題で接種不可能な人向けの接種不可能証明書とかは作ったりしないんかなあ・・・
    まぁ俺はたぶん関係ないけど

  •  #

    アラフォーだし
    ウイルス感染時のリスク高そうなんだよなあ
    ワクチン接種すべきだろうけど

  •  #

    old

    f:id:neetsdkasu:20210822051345p:plain
    •  #

      current

      f:id:neetsdkasu:20210822061417p:plain
      •  #

        develop

        f:id:neetsdkasu:20210822061429p:plain
        •  #

          うーん、誤差レベルぽい気がする

          •  (UPD ) #

            もう一度これら動かして比較するなりしたほうがいいかもなあ

          •  #

            誤差どころか全く違いがなかった
            勘違いにより全く意味をなさない実装だった・・・

            •  #

              別の箇所で処理してフィルター済みだったデータに対してまた同じフィルターを使う(ふるい落とすものが何もない)ことをしていた・・・

      •  #

        current

        f:id:neetsdkasu:20210822185054p:plain
        •  #

          たぶんold..

          f:id:neetsdkasu:20210822195149p:plain
          •  #

            oldとcurrent
            実は差は皆無なのでは・・・?

  •  #

    https://www.html5rocks.com/en/tutorials/developertools/sourcemaps/

    へぇ
    ソースマップというやつがあるの全然知らんかった・・・

  •  #

    パソコンもうだめかも
    ディスプレイに今までなかった
    怪しい線が出てきた・・・

    •  #

      線が出たり消えたりしとる・・・

  •  #

    ん、もしかして
    アレは今週末?

    •  #

      2000も配るんだったけ・・・?

      f:id:neetsdkasu:20210822071449p:plain
      •  #

        まぁ上位2000とか無理ゲーだが

        •  #

          一昨年はまともだったのに
          去年は酷い結果だな・・・

          何故・・・?

          •  #

            ああ、
            断ってから半年以上経過してるから
            単純に能力劣化か

          •  #

            (omitted)

        •  #

          R2の上位2000だよな?おそらく

          •  #

            R1突破ができないのに
            R2で得点とか無理だろJK

  •  #

    https://en.wikipedia.org/wiki/Clique_problem

    うーん、よくわからん

  •  #

    https://en.wikipedia.org/wiki/Category:Approximation_algorithms

    わからん

  •  #

    https://en.wikipedia.org/wiki/Category:Optimization_algorithms_and_methods

    ほええ

  •  #

    わからぬ・・・

    f:id:neetsdkasu:20210822195137p:plain
  •  #

    lowestedgeconectivitybasedkickとは・・・?何?????

    最低辺連結度ベースキック??

  •  #

    キックベースとハンドベースというベースボールぽいゲームがあった気がする

  •  #

    英語wikipedia項目だけは充実しててうらやましい(内容の質はわからんけど

    まぁ英語を使える人間の数と日本語を使える人間の数に大差あるんだから

    記事の量に差が出るのは仕方ないのか・・・

    •  (UPD ) #

      専門的な日本語情報、インターネット上に少なすぎ問題

 < の独り言 | の独り言 | の独り言 >