2025年12月31日水曜日

【感想/考察】(謎が)果てしなきスカーレット

果てしなきスカーレットの感想や考察を述べていきます。記事後半にはネタバレも含みます。



何故この映画を見たのかと言えば、それは何故わざわざジェットコースターに乗るのか、何故わざわざお化け屋敷に入るのかという問いと同じであり、つまりは怖いもの見たさであった。YouTubeでは酷評に晒され、行きつけの美容院では、

「この映画の感想を聞くと皆さん『うーん』と黙ってしまうんですよ...w」

と言われ、逆に自分の目で確認したくなってしまった。



ちなみに果てしなきスカーレットを見てきたのは先々週の土曜日。前日の金曜の時点でも席は7割ほど埋まっており、前評判ほどのスカスカっぷりではなかった。

映画の感想に移ります。まずはありがとう。(これから殴りますという宣言)


CGはそこまで問題なかった

映像についてはまあまあ安定してた。多少CG臭がきついシーンもあったが、そこまで悪い箇所はなかったと思う。1週間以上経過して覚えてないだけかもしれないが、忘れるくらいには自然だったということで...

ただ海外ウケを意識した造形は気に入らなかった。ぶっちゃけ可愛くない。スカーレットは劇中殴られたり鼻血を出したりと無様に描かれるシーンがあったが、美醜の落差を感じられずあまり刺さらなかった。もっと萌え豚に媚びた造形にしていれば、売上も1割くらい上がったんじゃなかろうか。


声優もそこまで問題なかった

主人公のCVは芦田愛菜"さん"で、ところどころイントネーションに違和感があったが、全体を通してみれば悪くなかったと思う。でもまあ普通に声優使った方がもっと良かった気もするけど。

あと敵役のクローディアスのCV(役所広司)が良かった。これは手放しで褒められる。



ここからはストーリーに触れるため、ネタバレを含みます。

「『ここからはネタバレを含むわよ!』と注意をしてくれるウマ娘のダイワスカーレット」というプロンプトをnano banana(非pro)に投げた結果


謎1. スカーレットの生還条件

「許す」がこの作品の主軸であったように、「クローディアスを許したから死者の国から生還できた」というストーリーは自然に感じる。もちろんこの考え方を否定するつもりはないが、当サイトでは「仮にクローディアスに復讐したとしても生還できていた」説を提唱したい

というのも、死者の国からクローディアスが消えたのち、あの謎の婆ちゃんはスカーレットに対して「時間切れ」という言葉を使っていた。「許したから」ではなく、単に「時間切れ」によって死者の国を去ったのではないか。

少し話は変わるが、スカーレットとクローディアスは合わせ鏡のような存在である。 スカーレットが叔父クローディアスへの復讐を望んでいたのと同様に、クローディアスもまたスカーレットの父であり兄である国王アムレットを処刑し復讐を果たした。国王として実権を握った後も反乱分子筆頭候補のスカーレットを生かし続けたのは、復讐に駆られる姪をかつての自分と重ねていたからではないだろうか。

ではスカーレットが叔父への復讐に囚われたまま生還し、国王の地位を授かっていたらどうなっていたか。恐らく憎き叔父と同じような、力で民を掌握し相互不信がまん延した国を運営していただろう。

この作品を語る上で最も重要な箇所は、死者の国でのくだりにはなく、むしろその後の所信表明演説にあるように感じた。死者の国で叔父を許したからこそ、民からの信頼を得られ、天気も国民の気持ちも晴れた。その許す/許さないの集大成が演説という形で表われていたと思う。


謎2. 渋谷のダンス

16世紀デンマークの王女は父を殺めた叔父に復讐をするべく死者の国を彷徨う中、現代世界から転生してきた聖と出会い夢に見た光景がこれ。


なんでやねん。

そもそもダンスがなんかチープ。聖も野原ひろしとジョイマンを足して2で割った感じ。あと視点の切り替えも少ない。1つのカメラを動かすだけってどうなんだ。スカーレットが楽しそうに踊っているのを見せたいなら、もっと顔に寄って笑顔にフォーカスしなきゃダメだと思う。あと周りの人ももうちょっと描いてあげて。

そもそも何故現代の渋谷で踊るのか。このシーンでスカーレットは、今とは違う自分、強引に換言すれば理想の自分を発見できたわけだが、観客の中で今の渋谷を理想郷と思える人は大変少ないのではないか。ハロウィンでは車が横転するし、JRの改札近くの通路でホームレスの方が寝てるし、イスラエルへの反戦デモが車をせき止めて一時一帯が渋滞してたし(その時現場にいた)。まあ渋谷でなかったとしても、現代日本を理想郷としてしまうと観客から白い目で見られるのは必至だろう。

何より面白いのは、この渋谷ダンスが仮に無くなってもストーリーの進行に特段の支障がなかったことだ。一応復讐以外の生き方を知らずに悩むスカーレットが楽しそうに踊る自分を見て今とは違う生き方を知るという意義がこのシーンにはある。ただ後半のストーリーに深く絡んでたかというと......。なんというか渋谷ダンスを入れるために生き方云々の話を持ってきたという印象を拭えなかった。

これは想像だが、ストーリーを改善するうちに不要になったが諸々の理由で映画に含めざるをえなかったのではないか。例えば、「渋谷再開発関連のステークホルダーに既に話を通していて今更変えられなかった」「既に莫大な資金を渋谷ダンスにつぎ込んでいて変えられなかった」とか。あとは売上面。

渋谷ダンス前後が不自然な流れになっていたことを監督自身もさすがに理解していると思う。そうでなければ、映画後半でこのダンスがもっと導線になっていただろうし、シーン自体ももっと気合い入れて作っていたはず。その上で捻じ込むだけの非ストーリー上の理由があったんだと思うが、まあこれ以上は邪推ですね。


謎3. デカい竜の正体

あのデカい竜は何なのか。なぜスカーレット達を助ける行動をとっていたのか。最後竜は無数の鳥として消えていったがどういう意味なのか。

なんとなく「神はお前らをみているぞ」と的なノリを主語を竜にして実装した印象を受けた。ただ、最後は単純に竜としての役目を終えて消えようとしたのか、それとも一羽一羽の鳥が国民というメタファーであり「民はお前たちを見ているぞ」的なノリで終わらせたかったのか不明。すいません、良く分からなかったっす。


謎4. 婆ちゃんの正体

他の人の考察も見てみましたが、分かりませんでした!いかがでしたか?


まとめ

  • CGや声優も見られる程度には良かった
  • 許す/許さないがこの作品のテーマで、最後の演説がその集大成だと思った
  • 渋谷ダンスはカス
  • デカい竜と婆ちゃんは何なのか分からん


冒頭に述べた「感想を聞くとみんな黙る」という美容院の人が放った言葉は意外と芯を食ってたと思う。明確な感動ポイントが存在せず、残された謎も解決されない。だがなぜか渋谷でダンスする。全く面白くなかったわけではないのだが、面白さよりは謎が勝る作品だった。


逆に言えば、謎解き気分で見に行く人にとっては楽しめる作品だと思います。是非この記事を参考にして、自分なりの考察にたどり着いていただければ幸いです。


2025年11月25日火曜日

【えいがさき感想】虹ヶ咲学園スクールアイドル同好会完結編第2章を観てきました

えいがさきを観るために、お台場まで1時間をかけて見に行った。お台場は虹ヶ咲学園の舞台でもあり聖地巡礼の意味合いもあるが、単純に上映時間の都合が良かったのがお台場を選んだ主な理由である。

既に公開から2週間が経過しており、どの映画館でも1本/日程度、その上朝8時とか9時とかに上映する映画館も多かった。ラブライブの、しかも虹ヶ咲を観るような人間がそんな朝早くから観に行けるわけないだろ。まあスパスタだったらギリ通用するかも、スパスタ好きは早起きできそうだよね逆に(再偏見)

そんな中、お台場の映画館はこれ。流石は聖地、1日に8本を上映する怒涛っぷりである。



東京テレポート駅では虹ヶ咲メンバーのパネルがお出迎えしてくれた。テンション爆上げだったのだが、駅を出た時点で上映まで残り10分程度だったので写真を撮るのは断念した。ちなみに帰りはゆりかもめ台場駅を使ったが、虹ヶ咲関連のパネルは置かれてなかった。現在進行形でコラボしてるのに...


映画を見終わり、「せつあい良ぃ...」となった衝動で2人のアクリルキーホルダーを買った。俺は軟派なオタクだからよぉ、素直で性格が良い陽キャ目な女の子に夢見ちまうんだ


アクアシティの三階では映画館のものとは別の虹ヶ咲グッズが販売されていた。そこでアクリルスタンドが飾ってあったので撮ってきた。


今気づいたけど右4人に蛍光灯が反射してた。すまない...俺が写真とは無縁の人生を送ってきたばかりに...


あとは映画の感想です(ネタバレ含む)







  • ポニテ+和テイスト衣装の栞子さん可愛すぎだろ...
  • アプリが落ちただぁ?負荷テストさぼってんじゃねぇぞ
  • 果林先輩が「侑には伝えるな。」の後に「愛たちにも言っといて」とさらっと言ってたのにスマートさを感じた。アニメの果林先輩にはこいつ賢いなと感想を抱くことが多い。
  • ミアちゃんもお姉ちゃんに本心を伝えられて良かったねぇ
  • 璃奈、お前それ犯罪だからな
  • せつあい最高。「スクールアイドルを辞めたら優木せつなはいなくなる」と言うせつなに対して「スクールアイドルを通して中川菜々が優木せつなに近づいている」と。中川菜々が優木せつなを理想の姿として作り上げたわけだが、優木せつなも中川菜々を作り替えつつある。これを同じくせつなに作られた(=せつなに感化されスクールアイドルを始めた)愛さんが言うわけですね。アニメの頃から一貫しているが、スクールアイドルは自分を成長させるきっかけを与えてきた。ミアのように自覚がある場合もあれば、菜々のように後から変化に気づくことも。ニジガクメンバーは覚悟が決まりすぎているので前者が強調されることも多いが、後者のような救われ方も美しいなぁと思った。

ブログ名を変えた

 前のブログ名気に入ってなかったんすよ()


...というわけで「雑多なブログ・フォン・あすらと」に変更しました。

ちなみに「フォン」は所有の前置詞で、ドイツ語版の"of"です。大学の第二外国語としてドイツ語を選択した経験が遺憾なく発揮されています。ちなみにドイツ語の数字はuns?(1), zwei(2), drei(3)までしか思い出せません。


「雑多なブログ・フォン・あすらと」もちょうど3つ目のブログ名になりました。投稿しない期間が長引くとなんかブログ名を変えたくなるので、今後変えないためにも投稿を頑張りたいなあと思います。なによりこれ以上数えられませんし。





2025年7月21日月曜日

個人的25春アニメ評価(アマプラ星基準)

アマプラの作品は、0.5点刻みで5点満点で評価される。

マイ基準はこんな感じ

  • 5.0: 神。1年で2~3本程度の面白さ。
  • 4.5: 傑作。自信を持って他人におすすめできるライン。
  • 4.0: 良作。豊作のクールはこの層より上が厚い。
  • 3.5: 普通。放送クールでないならわざわざ見る必要ないライン。ただし稀にめちゃくちゃ面白い掘り出しモノのようなアニメがある。
  • 3.0: 凡作。これ以下は基本見ない。


個人的な2025年春アニメの評価はこんな感じだった

  • 5.0: ひびめし、ジークアクス
  • 4.5: WITCH WATCH、薬屋、ウマ娘 シングレ
  • 4.0: にんころ、アポカリプスホテル
  • 3.5: ざつ旅、ロックレディ


今日言いたいのはほとんどこれで、

ひびめしありがとう

いやー、のんのんびよりのスタッフが集まった時点で良い作品なのは確定的に明らか。最終話Xのトレンド1位おめでとう




ついでにジークアクスも面白かったよ


流れてきた岡田斗司夫の切り抜きはわりかし同意できた。曰く、「ギャグアニメのスピード感をシリアスなアニメに導入したことで面白さに繋がった」と。やっぱアニメ単体だと脳のリソースを余らせて退屈になるんだと思う。テンポ良く話を回すか、ニコニコでコメントと合わせて見るかしないと。

ただ俺は「二次創作」は割とキーワードな気がした。特にソシャゲの二次創作と相似形で、「ソシャゲの二次創作という概念をアニメに導入したことで面白さに繋がった」んじゃないかと内心思っている。

ほら、遊んでないソシャゲの二次創作見てキャラ覚えちゃうし、なんなら二次創作経由でソシャゲ始める人多いでしょ?なあ、ブルアカ。なあ、ゼンゼロ。おい何目を背けてるスタレ。お前もこっち側だからな。

1stガンダム未視聴であってもジークアクスを二次創作として楽しめる土壌はソシャゲによって既に養成されていて、だからこそガノタ以外も巻き込んだあの盛り上がりようになったんだと思った。特に根拠はないけど。


2023年12月31日日曜日

【Unity】アスペクト比を維持して固定値を使わずに整列させる

アスペクト比を維持して固定値を使わずに整列させる方法をなんと2つも説明します。

問題設定

まずは目指す状態について説明します。

上の画像では半透明の範囲に本の画像とその白背景のセットが2つ描かれています。また白背景は正方形で、本の画像はその中に収まります。つまり、本+白背景の縦横比は1:1になります。

整列の設定を上手く施すことで、中身を増減させても自動的に間隔を調整してくれます。実際私は、以下の画像を作る時に位置や大きさを入力しませんでした。


以降の章でこの自動整列の設定方法について解説します。

なお、この記事では横に整列させる方法を解説しますが、Horizontal←→Vertical、Width←→Heigh(t)と適宜変換すれば縦にも同様に整列させられます。

共通部分

自動整列を実装する方法は複数ありますので、まずはそれらの共通部分について説明します。

上の画像は本の画像と白背景のセットが2つある場合のヒエラルキーです。

上のヒエラルキーに登場するCanvas内のGameObjectが有するComponentを以下に示します。

  • Area(親オブジェクト)
    • Horizontal Layout Group
      • 横に整列させるやつ。今回の主役
      • Control Child SizeのHeighをTrueにして、子の縦の長さを親に合わせるようにする
      • Child Force ExpandはいずれもTrueに
    • Image
      • 半透明なやつ
  • GameObject 1(子オブジェクト)
    • 今は何もつけない
  • Background(孫オブジェクト)
    • Image
      • ただの白背景なので、Spriteは何も入れない
  • Book(孫オブジェクト)
    • Image
      • 本の画像を挿す
      • 画像の比を維持するため、Preserve Aspectをtrueに

これらに追加でComponentを加えるケースもあります。

Aspect Ratio Filterを子オブジェクトにつける方法

Areaに紐づける"Horizontal Layout Group"の"Control Child Size"のHeighがTrueになっている場合(上の画像)、子のオブジェクト(GameObject1)のHeightには何も入力できない状態になります。"Control Child Size"はその名の通り、子のWidthやHeightを親が決定するかどうかのフラグであり、Trueになると子オブジェクトに対するWidth/Heightの入力を受け付けなくなります。

子オブジェクトにてHeightが入力できない状態

本と白画像のセットの縦横比は1:1にするためには、Widthの値をHeightからコピーしてくる必要があります。そこで、子オブジェクトに"Aspect Ratio Filter"を適用します。

Aspect Ratio Filterはそのオブジェクトのアスペクト比を自動で決定するためのComponentです。Aspect Modeで"Height Controls Width"を選択すると、WidthがHeightの値から自動入力されます。このように設定することで、本+白背景を複製しても同じ親にある限り上手に間隔を作ってくれます。

しかし残念なことに、子オブジェクト以下をPrefab化してスクリプト上から複製すると自動整列が機能しません。Aspect Ratio FilterとHorizontal Layout Groupが共存すると発生する問題のようで、入力をロックする箇所が異なっていても動作しないようです(実際警告が出てる)。Aspect Ratio Filterが先にWidthやHeightをロックすることで後のLayoutGroupが動作できなくなり、機能しないのではないかと睨んでいます。Prefabから生成する場合は次の方法を試してみてください。

Aspect Ratio Filterを孫オブジェクトにつける

代替案として、子オブジェクトの代わりに孫オブジェクト(Background)にAspect Ratio Filterをつけることでも自動整列が可能です。その際、Aspect Modeを"Envelope Parent"に設定しましょう。Envelope Parentモード下では、元々設定していた孫オブジェクトの大きさを子の大きさによって拡大することが可能になります。

孫オブジェクト(Background)のComponent

上の画像ではW Deltaに82.79999と入力されています。これは親オブジェクトのHeightが182.79999で、元々設定されていた子オブジェクトのWidthが100であり、Envelope Parentによって引き伸ばされた分がW Deltaに入力されます。

この方法ではPrefabから生成しても自動整列が機能します。Aspect Ratio FilterとHorizontal Layout Groupが同じ箇所をロックすることもないので、警告も発生しません

余談

自動整列問題がややこしいのは、WidthやHeightを画面の大きさに応じて変化させようとするからです。WidthやHeightに固定値を入力させられれば、Layout Elementなどを利用してもっとわかりやすく自動整列を実装できます。まずは画面のサイズを最初に決めて、WidthやHeightに固定値を入力させるのが良いと思います(一敗)。

まとめ

  • XXX Layout Groupを親に設定して整列させる
  • Aspect Ratio Filterを子か孫に設定してアスペクトを維持させる
  • 画面のサイズは最初に決めよう


以上です。

【ゲーム製作】日◯簿記の問題集で家を確保するゲーム

日◯簿記の問題集で家を確保するゲームを公開しました!

URL: https://unityroom.com/games/boki-warashibe

よかったら遊んでください。(偉い人に怒られたら消します)

2023年7月2日日曜日

【プログラミング】ヘクス座標系でのマスの管理方法

 
こんにちは、あすらと(@__asurato__)です。

モダンなゲームではあまり見かけなくなりましたが、大戦略やCivilizationのような戦略シミュレーションではヘクス座標系が採用されています。ヘクス座標系では1つのマスが正六角形になっており、正六角形の各マスは隙間なくマップに敷き詰められます。本日はヘクス座標系のマスの管理方法について考察しましたのでご覧ください。



ヘクスマップの例

前提


本記事では以下を前提としています。これらの前提が容易・高速に達成できるアルゴリズムが良い手法であるとここでは定義します。
  • Tileクラスが各マスの情報を表す
  • Tile型のインスタンスは配列や二次元配列に格納される
  • マスが指定されたらそのマスに関するTile型のインスタンスを取得したい
  • あるマスに隣接しているマスも取得したい

例えば tiles[id] 等でそのidに関するTile型のインスタンスを取得することができれば前の3つについて達成されます。言い方を変えると、関数f: id→Tile となる関数が作れるならOKです。

またマスXに隣接したマスYを取得できれば最後の項目は達成されます。前3つの項目によりidからTileへの変換は前提とするため、XのidからYのidが取得できれば達成されます。


以下からマスの管理方法について章立てで説明します。


並んでる方向にIDを振る手法(一次元)


すごく自然なIDの振り方で、右上のマスは+3、右下は+4と隣接マスも計算しやすいです。ただし以下のような上下で対称でないマップの場合、右上のマスはIDが+4 or +5され固定値になりません。

上下が非対称なヘクスマップ

このような場合はIDを振る方向を横に変えるとなんと解決します。


すごくない?
  • 特徴
    • 隣接マスのIDの取得が簡単
    • 自然な発想
    • メモリの無駄がない
    • マップが長方形の場合のみ使用可能

二次元直交座標に変換する手法


一次元的にIDを与えるのではなく、二次元座標を用いて各マスを二次元配列に格納することもできます。座標[a, b]のマスはtiles[a][b]として取得します。

問題点として、tiles[0][0]とは異なりtiles[0][1]には値が存在しません。tiles[a][b]が存在するかを常にチェックする必要があります。

  • 特徴
    • 隣接マスのIDの取得が簡単
      • 例)a→a+1、b→b+1で右下のマスを取得できる
    • 全てのマップ系で使用可能
    • 座標にマイナスの値が含まれるときは別途対処の必要あり
    • 配列の戻り値がTileとNullの2種類があり、Nullチェックが必要
    • 二次元配列のうち半分が死にマスとなり、メモリの無駄遣い♠️


二次元直交座標+Map法


上の手法の派生系で、二次元座標を文字列に変換してMapに格納する手法です。ちなみにPythonのようにタプルをキーにできる言語や、座標を示す構造体をMapのキーに自前で設定する場合は文字列への変換は不要です。メリットはメモリの無駄がないこと、デメリットは座標とMapのキーとの相互変換が面倒な点でしょう。

  • 特徴
    • 隣接マスのIDの取得には座標とMapのキーとの相互変換が必要
    • メモリの無駄がない
    • 座標がマイナスを含む場合も対応できる
    • 全てのマップ系で使用可能


二次元座標+配列法


私が考えたイケイケアルゴリズムです。

まず上図のように軸を設定し座標を計算します。B軸の位置について、Aの要素が0以上になるように設定しましょう。

次に2つの配列を用意します。1つ目の配列には全てのマスが格納され、もう1つの配列には前者の配列のキー(ID)が入ります。


まず要素Aが小さい順に、要素Aが同値の場合は要素Bが小さい順にマスを配列1へ格納します。その格納の際に、要素B=0となるマスの(配列1における)IDを配列2に格納します。2つの配列を用いて、座標(a, b)のマスは arr1[arr2[a] + b] として取得できます。


  • 特徴
    • 隣接マスのIDの取得が簡単
      • 例)a→a-1、b→b+1で右下のマスを取得できる
    • ほとんどのマップ系で使用可能
      • ただし間が空くマップ系だと「二次元直交座標に変換する手法」と同様にNullチェックが必要になる
    • メモリの無駄がない
    • 軸が斜めになっているので直感的ではない
      • でも頑張れば直交座標でも使えそう

まとめ

  • マップが長方形ならIDを縦or横方向に振る方法でよい
    • 縦か横かはその時のマップの性質によって見極める必要がある
  • 二次元直交座標+Map法は任意のマップで使えるので、最終手段として検討しよう
  • 二次元座標+配列法はコードが少し難しくなるが色々効率的

参考サイト

http://higesusk.blog.fc2.com/blog-entry-146.html
https://ninagreen.hatenablog.com/entry/2015/11/14/193417
https://sinsei.space/blog/11747
https://www.redblobgames.com/grids/hexagons/

2023年6月28日水曜日

【Blogger】ラベルを階層化する


階層構造に、改装!w こんにちは、あすらとです。

Bloggerでは記事に対してラベルを付与できますが、このラベルの機能はあまりリッチではありません。そこで、当BlogではBloggerのブログアーカイブのHTML構造を参考にし、比較的自然なラベルの階層化機能を自前実装しました。本日はこのラベル階層化の手順について解説します。

先に完成後のスクリーンショットを以下に載せます(まあPCなら横に表示されているとは思いますが念の為)。



ご自身のブログに同様の機能を実装したいと感じた方は是非最後までご覧ください。



まずBloggerはラベルの階層化機能を提供しておりませんので、HTMLを自分で編集する必要があります。「テーマ」→「カスタマイズの横の下三角」→「HTMLを編集」とクリックしHTMLの編集画面を開きます。


続いて、編集画面で「id='Label1'」で検索し、ラベルの機能を探します。(検索にない場合は元の画面に戻り、「レイアウト」からラベルガジェットを追加してください。)おそらく以下のように表示されていると思います。



最後に<b:widget...から次の</b:widget>まで以下のコードに差し替えて終了です。


  <b:widget id='Label1' locked='false' title='カテゴリ別' type='Label' version='1'>
    <b:widget-settings>
      <b:widget-setting name='sorting'>ALPHA</b:widget-setting>
      <b:widget-setting name='display'>LIST</b:widget-setting>
      <b:widget-setting name='selectedLabelsList'/>
      <b:widget-setting name='showType'>ALL</b:widget-setting>
      <b:widget-setting name='showFreqNumbers'>false</b:widget-setting>
    </b:widget-settings>
    <b:includable id='main'>
  <b:if cond='data:title != &quot;&quot;'>
    <h2><data:title/></h2>
  </b:if>
  <div expr:class='&quot;widget-content &quot; + data:display + &quot;-label-widget-content&quot;'>
    <ul class='hierarchy' id='rootNode'>
      <b:loop values='data:labels' var='label'>
        <li class='labelNode archivedate collapsed' expr:name='data:label.name'>
          <b:include name='myToggle'/>
          <a class='post-count-link' expr:href='data:label.url'>
            <data:label.name/>
          </a>
          <span class='post-count' dir='ltr'>(<data:label.count/>)</span>
          <ul class='hierarchy' style='padding: 10px 0 0 10px'/>
        </li>
      </b:loop>
    </ul>
    <ul class='hierarchy' id='templateElement' style='display:none;'>
      <li class='labelNode archivedate collapsed'>
        <b:include name='myToggle'/>
        <a class='post-count-link' href='javascript:void(0)'>LABEL_NAME</a>
        <ul class='hierarchy'/>
      </li>
    </ul>
    <b:include name='quickedit'/>
  </div>
  <style type='text/css'>
li.collapsed &gt; ul.hierarchy {
  display: none;
}
  </style>
  <script type='text/javascript'>
// 深さ優先探索でHTMLタグを形成する関数
function dfs(ul, obj) {
  for (const label of Object.keys(obj)) {
    let {node, children} = obj[label]

    if (!node) {
      const template = document.querySelector(&#39;#templateElement&#39;).innerHTML.replace(&#39;LABEL_NAME&#39;, label)
      node = new DOMParser().parseFromString(template, &#39;text/xml&#39;)
    }
    node.firstElementChild.addEventListener(&#39;click&#39;, () =&gt; onToggled(node.firstElementChild))
    console.log(ul)
    console.log(node)
    ul.appendChild(node)

    if (Object.keys(children).length &gt; 0) {
      dfs(node.lastElementChild, children)
      continue
    }

    node.removeChild(node.lastElementChild)
    node.removeChild(node.firstElementChild)
  }
}
// トグルがクリックされた時の関数
function onToggled(element) {
  element.parentElement.classList.toggle(&#39;collapsed&#39;)
  element.parentElement.classList.toggle(&#39;expanded&#39;)
  element.firstElementChild.classList.toggle(&#39;toggle-open&#39;)
  if (element.parentElement.classList.contains(&#39;expanded&#39;)) {
    element.firstElementChild.innerHTML = &#39;&#9660;&#160;&#39;
  } else { // 縮小する
    element.firstElementChild.innerHTML = &#39;&#9658;&#160;&#39;
  }
}
function main() {
  const treeObj = {} // 木構造を有するデータ
  document.querySelectorAll(&#39;li.labelNode[name]&#39;).forEach(node =&gt; {
    node.parentElement.removeChild(node) // 一旦DOMから消えてもらう

    // ラベルの名前をツリー状になるように登録する
    let obj = treeObj
    node.getAttribute(&#39;name&#39;).split(&#39;_&#39;).forEach((label, i, a) =&gt; {
      if (label in obj === false) {
        obj[label] = {&#39;children&#39;: {}, &#39;node&#39;: null}
      }
      if (i === a.length - 1) {
        obj[label][&#39;node&#39;] = node
      } else {
        obj = obj[label][&#39;children&#39;]
      }
    })
  })
  dfs(document.querySelector(&#39;#rootNode&#39;), treeObj)
}
main()
  </script>
</b:includable>
    <b:includable id='myToggle' var='interval'>
  <a class='myToggle' href='javascript:void(0)'>
    <span class='zippy'>
      &#9658;&#160;
    </span>
  </a>
</b:includable>
  </b:widget>

保存は忘れずに!お疲れ様でした!

2023年5月6日土曜日

【Rust】IteratorとVecの関数が多すぎ?


RustはC言語並みの実行速度、モダンな言語特有の安全性、堅牢な型システムを有するプログラミング言語です。

Stack Overflowの調査ではRustは最も愛される言語に選ばれましたが、Rust固有の概念や型システムは難解で言語の性能に比べて愛用者は少ない印象です。「好きな言語?まぁ、Rustかな。」と言った日には圧倒的玄人感で周囲を威圧させ、その眩き威光には流石の水戸黄門も平伏すしかありません。

そんな厨二病患者へのサポートも欠かさない言語、Rust。私も最近勉強を始めました。しかしサクッと競プロも問題を数問解いてみたところ、このような感想を持ちました。



ということで検証しました。


Rust


Rustの関数の個数は以下でした。(手作業のため誤差があるかもしれません)
  • Iterator: 75個
  • Vec: 50個
  • Array: 12個

やっぱりVecとIteratorの数が多いですね。これはRustがオーバーロードを実装していない点が原因の一つです。reduce関数fold関数は顕著な例で、初期値の有無のみで2つの関数に分かれています。


続いてRust以外の言語の関数の数について紹介します。


JavaScript


  • Array: 45個

(そうだよ!これだよこれ!)

JavaScriptのArrayはVecとIteratorの役割を同時に果たすことも相俟って、関数の数は少ないです。まあブラウザで動かし続けないといけないからね。そりゃ慎重にもなる。


Java


  • Stream: 33個(オーバーロードの関数名重複ありで39個)
  • List: 22個(オーバーロードの関数名重複ありで28個)
  • Arrays: 17個(オーバーロードの関数名重複ありで155個)


155個!?

これは私の推測ですが、Arraysクラスの関数の多さはJavaが互換性を残しているためだと考えられます。binarySearch関数は全部で18個存在し、T[]のようなジェネリクス以外にint[]やdouble[]を引数として用意する徹底ぶり。

しかし、比較的新しいStreamクラスについてはRustに比して関数は少なく、Listクラスについても同様です。


C#


  • LINQ(IEnumerator): 66個(オーバーロードの関数名重複ありで213個)
  • List: 32個(オーバーロードの関数名重複ありで48個)
  • Array: 32個(オーバーロードの関数名重複ありで94個)


さて私の愛するC#ですが、意外と関数が多い。競プロで使うくらいLINQ好きなんですけどね...

なんか雲行きが怪しくなりました。


Scala


さて、Pythonは組み込み関数だから比較は難しいし、あと触ったことがある言語は......Scalaかぁ。




  • Collection: 150個




結論



疑ってすまないRustくん。君も多い方なんだろうけど......

あと今日からScala叩きに転身します。


P.S. Pythonのリストの関数は11個でした。



終わり