Unityと数学の学習帳

Unityと数学の同時学習を目的としたブログ

ポインター

僕が考える翻訳の本質とは魂を伝える事だと思う。魂とは何かというと包括的にとらえるとポインターなのだと考えている。つまりグラフにおける指し示す記号。
パス(経路)。「指月の譬」だと思う。「私は、あの月をあなた方に指し示すことはできるが月を見るか見ないかはあなた方の自由意志に任されている」という、お釈迦さまの格言がある。
その指が魂。
f:id:cqbosinko:20181218111749p:plain
指月の譬 - Google 検索

コンピューター。Siriやグーグルの検索にはパターン学習が利用されている。最近では翻訳にも利用されている
wired.jp

ある統計モデルは「ボンジュール」を「ハロー」と翻訳する。場合によりそのポインター(指月の譬)は正しく機能するが、ある場合によっては「情報の欠損」があるだろう。
自分が考える良い翻訳とは、この情報の欠損がないことだ。場合によっては増強できれば尚良い。色々考えると、色即是空とはおそらく関数のことをあらわしているのではないかと考える事がある。
関数の語源は数学などの教本によるとハコ「函」から来ているらしい。現代においての関数の当て字に対しての僕の感想は違う。二つの関心がある事柄を繋げて考える。
関係性や関心の「関」から来ているのではないだろうか。繋げるためには間にパス(経路)が必要になるだろう。

指数とはまた面白い言葉だ。

虚数の情緒P471メモ

虚数の情緒P471メモ

虚数平方根を求める

{ x }^{ 2 }=i

xa+biの抽象化した複素数の式と考える
iは定数。abは変数である事を意識すると
iは実部が0なので

\overbrace { i }^{ 定数で実部が0である } ={ \left( a+bi \right)  }^{ 2 }=\underbrace { { a }^{ 2 }-b^{ 2 } }_{ 実部なので0 } +\underbrace { 2abi }_{ 2ab\times i } \quad \cdots ①

これは恒等式における係数比較の考え方を利用している。まとめると

\begin{cases} { a }^{ 2 }-b^{ 2 }=0\quad \cdots ② \\ 2ab=1\quad \cdots ③ \end{cases}

連立方程式となる。この根は②より

{ a }^{ 2 }-b^{ 2 }=0\quad \Rightarrow \quad { a }^{ 2 }=b^{ 2 }\quad \Rightarrow \quad \begin{cases} a=b \\ b=a \end{cases}

③に代入して

\begin{cases} 2{ a }^{ 2 }=1\quad \Rightarrow \quad { a }^{ 2 }=\frac { 1 }{ 2 } \quad \Rightarrow \quad { a }=\pm \sqrt { \frac { 1 }{ 2 }  } \quad \Rightarrow \quad { a }=\pm \frac { \sqrt { 1 }  }{ \sqrt { 2 }  } \quad \Rightarrow \quad { a }=\pm \frac { 1 }{ \sqrt { 2 }  } \cdot \frac { \sqrt { 2 }  }{ \sqrt { 2 }  } \quad \Rightarrow \quad { a }=\pm \frac { \sqrt { 2 }  }{ 2 }  \\ 2b^{ 2 }=1\quad \Rightarrow \quad { b }=\pm \frac { \sqrt { 2 }  }{ 2 }  \end{cases}

この結果を正の数のみ考えて①に代入して

i={ \left( \frac { \sqrt { 2 }  }{ 2 } +\frac { \sqrt { 2 }  }{ 2 } i \right)  }^{ 2 }\quad \quad \Rightarrow \quad { i }^{ \frac { 1 }{ 2 }  }=\frac { \sqrt { 2 }  }{ 2 } \left( 1+i \right) \quad =\quad 0.7071...+0.7071...\cdot i

これを複素平面上に置いてsin,cos関数と合わせて考えると以下のような図になる

虚数平方根ガウス平面上でちょうど斜め45度のオイラー角の位置の点、ラジアンでは\frac { \pi  }{ 4 }になる
これに対しての絶対値を求める。これはP463の式を使う

Z=a+bi\\ { Z }^{ * }=a-bi\\ \left| Z \right| =\sqrt { Z{ \cdot Z }^{ * } } =\sqrt { { a }^{ 2 }+b^{ 2 } } \\

複素数Z、トレース{ Z }^{ * }、絶対値\left| Z \right| 、という意味になっている。これにあてはめると

\sqrt { i } =\frac { \sqrt { 2 }  }{ 2 } +\frac { \sqrt { 2 }  }{ 2 } i\\ { \sqrt { i }  }^{ * }=\frac { \sqrt { 2 }  }{ 2 } -\frac { \sqrt { 2 }  }{ 2 } i\\ \left| \sqrt { i }  \right| =\sqrt { \sqrt { i } { \sqrt { i }  }^{ * } } =\sqrt { \left( \frac { \sqrt { 2 }  }{ 2 } +\frac { \sqrt { 2 }  }{ 2 } i \right) \left( \frac { \sqrt { 2 }  }{ 2 } -\frac { \sqrt { 2 }  }{ 2 } i \right)  } =\sqrt { \frac { 2 }{ 4 } +\frac { 2 }{ 4 }  } =\sqrt { 1 } =1\\

これによりベクトル長(Length)が1であることがわかる。つまりsin,cos関数の単位円上に乗っている

そもそも円と\piは何か?を考える

翻訳を支援するunity用プログラム

HatInTimeの翻訳を支援するunity用プログラム

正規表現を利用してテキストファイルの中身を解析し目的に沿った編集を行った上で非破壊的にデーターを出力するプログラムを組んでみた。
個人の目的に特化して作られたコードだが、正規表現を利用した親子構造を持つスクリプトの内容の置換は応用が効く為、よく似た目的を持つ人の参考資料になるかもしれない。
コードはunity上で実行されることを前提に書かれている。適当なgameObjectsにクラス名を合わせてAddComponentすれば、すぐに動くと思う。

HatInTimeの翻訳を支援するunity用のプログラム

やっていることの例:
以下のような二つのテキストファイルがあるとする。refは元の翻訳前のテキストファイル。workはrefに対して同名同フォルダ構成の翻訳作業後のテキストファイル。
f:id:cqbosinko:20180929141923p:plain

各セリフのデータはシーンを表すヘッダ「[シーン名]」と、そのシーン内でキャラクタが喋るセリフ「タグ=台詞」で構成されている。
workデータは翻訳作業や様々な理由により、refデータの行位置関係と比べバラバラな位置になってしまっている。
このプログラムはrefのデーターをベースにしてworkの各コードを抽出し位置を合わせて整理する。

結果、以下のようなテキストファイルをフォルダやファイルの位置関係も合せながら別途に出力する

f:id:cqbosinko:20180929143218p:plain

ゲーム側のスクリプト処理の特徴として

[groupA]
voice1 = code1
voice2 = code2

[groupB]
voice1 = code3
voice2 = code4

というスクリプトがあった場合、ゲーム側はgroupAにvoice1=code1とvoice2=code2を関連付けて処理する。
従ってgroupAにvoice2 = code4が関連付けられたり、groupBにvoice2 = code2が関連付けられるとデータとしては使えなくなる。
この「親子関係は維持」して変換する必要がある。

[親]
子1=code
子2=code

当プログラムは、これを正常に変換する。
変換後の翻訳作業にはVisualStudioの「比較モード」を利用して翻訳作業を進める。比較モードは実行ファイルよりオプションと対象ファイルを指定して実行する必要がある
例えば以下のようなバッチファイルを作り、あらかじめ一つVisualStusioを起動した状態でバッチファイルを起動するとすべての対象ファイルがタブに収められる

cd C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\
start devenv.exe /diff C:\Users\yourPC\Desktop\labo\ref\sequences\seals_ship.int D:\SteamLibrary\steamapps\common\HatinTime\HatinTimeGame\Mods\JapaneseMod\Localization\INT\sequences\seals_ship.int
start devenv.exe /diff C:\Users\yourPC\Desktop\labo\ref\sequences\alpv_ship.int D:\SteamLibrary\steamapps\common\HatinTime\HatinTimeGame\Mods\JapaneseMod\Localization\INT\sequences\alpv_ship.int
start devenv.exe /diff C:\Users\yourPC\Desktop\labo\ref\sequences\crows_ship.int D:\SteamLibrary\steamapps\common\HatinTime\HatinTimeGame\Mods\JapaneseMod\Localization\INT\sequences\crows_ship.int

画面はこのようになる
f:id:cqbosinko:20180930145319p:plain




A Hat in Time のMOD制作忘備録

「A Hat in Time」はアンリアルエンジン3を利用して作られていた。MODを作る際にUE3の知識が得られたので忘備録として残しておく
あくまでunityユーザーからのUE3機能把握を感覚的に忘備録として書いているので内容は”いいかげん”です。ふーん。そんなものかな?といった感じで読んで欲しいです。

  • UE3は基本的にマルチランゲージをサポートしている
  • ゲームフォルダ内のLocalizationフォルダ内のintフォルダが初期言語として設定される(大抵、英語)拡張子は各国別に3文字で指定できる。日本は*.jpn。メモ帳やヴィジュアルスタジオなどで開くと分かるが単なるテキストファイル。このファイル内で使われる文字コードにより自動的に利用するフォントをエンジンが決定している
  • KISMETは視覚的に確認できるプログラミングでActorと連携して機能させることが出来る。非常に癖が強い。Actorをドラッグ&ドロップすることでクラス機能を配置できる
  • ActorはunityにおけるGameObjectに相当するらしい。Actorに対して*.ucスクリプトファイルを利用してクラスを作成し、関数やプロパティを実装、処理する
  • UPKファイルはunityにおける圧縮され整頓されたAssetBundleのようなものに該当するらしい。画像、フォント、音楽などの素材データになる
  • 「A Hat in Time」ではMODフォルダ内に決まった形式でデーターが収まっている必要があった。好き勝手にデータファイルを置いてもうまく動かない
  • Classesフォルダ。MODそのものが利用し生成したクラスファイル。基本的にMOD_Managerアプリに生成を任せていればOK
  • Contentフォルダ。MODで利用するUPKファイルは全てここに収めて置く。コンパイラはこのフォルダの中身を見る
  • Localizationフォルダ。言語ファイルを収める。日本語コードでもintフォルダに*.intとして納めれば初期言語としてオーバーライドできる。これに関してはコンパイル不要
  • Mapsフォルダ。マップデーターを収める。マップデーター実行時はマップエディターでのBuildが必要。またMOD_ManagerアプリでCompile_ScriptsとCookedが必要
  • カレントにmodinfo.iniを作成し細かいMODの設定をスクリプトで行う。多くのファイルをリプレースする場合、このファイルを編集する機会は必然多くなる。内容は人が作ったものを参考にするとよい
  • 他人の作ったMODデーターはスチームがDドライブにインストールされている場合、D:\SteamLibrary\steamapps\workshop\content の各ゲームIDの中にワークショップ単位で収められている。これをゲームのMODフォルダ内に収めればソースが再現できる
  • UE3とUE4はファイル形式そのものが違い互換性はまったくない
  • 全てのデータが揃うと「Update Steam Workshop」でパブリッシングできる。steamワークショップでは常に履歴は記録されロールバック出来る。
  • パブリッシュされるとMODフォルダのカレントにSteamWorkshop.iniが生成される。テキストファイルで開くと中にWorkshopIdが記録されている
  • フォント作成ではUE4を利用した。UE3は日本語フォント未対応(確認済み。またフォントによってはプロテクトがあるものもあるようだ)。ファイルの互換性はまったくないのでUE4でTGA形式で出力し、フォントデーターの。各プロパティを手動で地道にコピペしていく事でUE4形式からUE3に移植した(コピペは内容を少し編集すると丸ごと移し替えることが出来た。一度メモ帳か何かにペーストしてUE3が飲み込める形に書き換える。要内容観察)
  • UE3ではエディタのContentBrowserの利用が非常に重要になってくる。ここではUE3エンジンが読み込んだ全素材データーを閲覧できる。ActorClassesでは*.ucで作成した動作するクラスを閲覧でき、クラス機能(関数やプロパティ)をkismetやマップエディタ内にドラッグアンドドロップで配置できる。この辺りはunityのGameobjectsと扱いが良く似ている(重要!)おそらくコーディングで新しくクラスを作るとコンパイルしないとクラスとしてエンジンは認識しないと思われる(unityのように作ったら即認識はしないと思われる。未確認)
  • エディタのlevelタブではマップ内に配置した素材を検索閲覧できる
  • ContentBrowserのImportを利用することで自分が作成した画像や音楽、などのデーターをインポートできる。PSDファイルなども読み込めるので便利
  • 読み込んでもセーブする必要があるので注意。この時のセーブされたファイルの配置などに注意。
  • 各素材は右クリックすることで様々な機能にアクセスできることに留意。copy full name to clipboardなどは非常に重要な機能で、modinfo.iniファイルなどでMODにリプレースを指示するときに重要になってくる
  • 日本語の翻訳作業は検索機能が強力なvisualStudioがおすすめ。フォルダ内検索などでは*.ucファイルなどのテキストワードなども一括検索できるのでイベント名を利用してactorのクラスを探すなどにも利用できた。コレが出来るとできないでは作業上、大きく能率が変わるので、他の作業でも積極的にvisualstudioを利用すること。とにかくコード編集のみならずテキスト編集で高度な作業はこれでやったほうがいい。一度読み込んだ複数ファイルはプロジェクトとして保存しておくと状態を維持するので作業の再開も非常にスムーズだった。複数ファイルを横断した置換なども可能(名詞の統一などにも威力がある)

総評;UE3は古い作りというかunityより二次生成物が多いので手間がかかりめんどくさい。UE4で改善されていると思われる。実行ファイルはunityより早くて快適だが作る手間は少し多いと感じた

指数と直感の話

先日、郵便物を読んでいて興味深い数学の話があったので自分なりに記事を再検証してみることにした。
記事の内容をそのまま、ここに載せるのはリテラシーの面で問題があるので多少、問題の形を変えて考えてみる。

資料:瀬山士郎先生の数学よもやま話:連載15 ちょっとおかしな賭け
こんな賭けがある。100枚のカードがあり各カードには「WIN(勝ち)」、「LOSE(負け)」と書かれている。この100枚のカード全てを裏にして並べて置き、任意のカードを表にして「WINが出たら」現在の所持金の半分がもらえる。「LOSEが出たら」現在の所持金の半分が奪われる。このゲームを100枚のカード全部、表にするまで行う。とする。「WIN(勝ち)」のカードが61枚、「LOSE(負け)」のカードが39枚だとする。あなたは、この賭けにのりますか?


直観的に考えると、お金の出入りは半額同士なのでカードの配分を考えると自分が圧倒的に有利だと思う。
しかし、この賭けは罠だ。このゲームにのったら最期、自分の最終所持金が必ずほぼ10%になってしまう。

計算してみよう。

連続で61回勝利し、その後、連続で39回負けるとする。最初の所持金は100円とすると、式はこうなる

{ a }_{ 1 }=100\quad ,\quad { a }_{ n+1 }={ a }_{ n }+\frac { { a }_{ n } }{ 2 } \quad \left( n=1,2,3,\cdots ,60,61 \right) \\ \Rightarrow \quad { a }_{ n+1 }={ a }_{ n }\cdot \left( 1+\frac { 1 }{ 2 }  \right) \quad \Rightarrow \quad { a }_{ n+1 }={ a }_{ n }\cdot \frac { 3 }{ 2 }

漸化式と一般解の公式 { a }_{ n+1 }={ a }_{ n }r\quad \Rightarrow \quad { a }_{ n }={ a }_{ 1 }{ r }^{ n-1 }を利用して漸化式を一般式に変換すると

{ a }_{ 1 }=100\quad ,\quad { a }_{ n+1 }={ a }_{ n }\cdot \frac { 3 }{ 2 } \quad \left( n=1,2,3,\cdots ,60,61 \right) \quad \Rightarrow \quad { a }_{ 61 }=100{ \cdot \left( \frac { 3 }{ 2 }  \right)  }^{ 61+1-1 }

これで61枚目を開いた状態の所持金の値になっているので、このまま続けて

b_{ 1 }={ a }_{ 61 }\quad ,\quad b_{ n+1 }=b_{ n }-\frac { b_{ n } }{ 2 } \quad \left( n=1,2,3,\cdots ,38,39 \right) \\ \Rightarrow \quad { b }_{ n+1 }=b_{ n }\cdot \left( 1-\frac { 1 }{ 2 }  \right) \quad \Rightarrow \quad b_{ n+1 }={ b }_{ n }\cdot \frac { 1 }{ 2 } \quad \Rightarrow \quad b_{ 39 }={ a }_{ 61 }{ \cdot \left( \frac { 1 }{ 2 }  \right)  }^{ 39+1-1 }

従って100枚すべてめくった時の所持金は

100{ \left( \frac { 3 }{ 2 }  \right)  }^{ 61 }{ \left( \frac { 1 }{ 2 }  \right)  }^{ 39 }

となる。

この計算は乗算で閉じている。つまり演算項の順番、言い換えると勝ち負けの順番が自由に入れ替わっても100枚全部表にする以上、計算結果は変わらない事に注目する必要がある。
つまりどんなことをしようが、必ずこうなる。

100{ \left( \frac { 3 }{ 2 }  \right)  }^{ 61 }{ \left( \frac { 1 }{ 2 }  \right)  }^{ 39 }=10.03221824771

100円あった所持金は必ず10円になる。こういうペテンがあるのだ。
試行中の所持金の値をスプレッドシートで確認できるようにした。値が信じられないなら以下を参照

docs.google.com

さらにunity上でこのカードゲームをシミュレーションして結果を確認して置く


シャッフルしたカードのシミュレーション

3回のシミュレーション結果
CARD:WWWWLLWWWLWLLLLWLWWWLWWWWWWWLWWLLLLWWWWLWWWLWLWLLWWWLLLLWWWLLWLWLWWWWLWWWLWWWWWWWLLLLWLWWLLLWWWLLWWW money=10.03222
CARD:LWWLWWLWWWLWLWWWWWLWWWLLLWWWWWLWWLLLLLLWWWLLWLLWLWWWWLWWLWWLWLWWWLWLWLWWWWWLWWWLLWWWLLLLWWWWWWLLWLWL money=10.03222
CARD:WLWLWLWWLWWWWWLWWWLLWLWWWWLLLLLLWWLWLLLLLWWWLWWWLLWWLLWLLWWWLWLWLWWWWWWWWWWWWWLWWLWWLWWWLLWWWLWLWWLL money=10.03222

計算式は以下のようにpocketCasでも仕組みを検証できる

f:id:cqbosinko:20180830165345p:plain

この一連の問題は物事を指数に変換してみると分かりやすいと言う事を非常にシンプルに表している様な気がする、つまり...
\frac { 1 }{ 2 } ,\frac { 2 }{ 2 } ,\frac { 3 }{ 2 } この3つの数字を2の指数表示にしてみると{ 2 }^{ -1 },{ 2 }^{ 0 },{ 2 }^{ 0.5849625... }
となる。-1と0.5849625...では値的にどちらが強いか?という風に考える事も出来る。要約すると以下のように考えるとさらにシンプルになる

{ \left( \frac { 3 }{ 2 }  \right)  }^{ 61 }{ \left( \frac { 1 }{ 2 }  \right)  }^{ 39 }\quad \Rightarrow \quad { \left( { 2 }^{ 0.5849625... } \right)  }^{ 61 }{ \left( { 2 }^{ -1 } \right)  }^{ 39 }\quad \Rightarrow \quad \left( { 2 }^{ 0.5849625...\times 61 } \right) \left( { 2 }^{ -1\times 39 } \right) \quad \quad \Rightarrow \quad \left( { 2 }^{ 35.68271... } \right) \left( { 2 }^{ -39 } \right)

この右端の式は、勝敗のカードの枚数の配分が何枚なら、この賭けに乗ってもいいかの意味を単純に表している。
つまりWINのカードの枚数が、3.32乗分だけ、もう少し必要だと考えられる。
これはデシベルの考えに通じている。ここで同じ種類の2つの量の比として定義される量は無次元量である事を利用してみる。

参考資料:

2つの対数の量の比は底の値を変えても同じになる。これが物理量のレベル表現となる。関係をpocketCasの計算式で確認すると以下になる

f:id:cqbosinko:20181109104241p:plain

もう、底はなんでもいいという事なので、下の様な式を作って方程式を解くと、かならず勝てるラインが解ってくる

\frac { 1.7095\times \left( 100-n \right)  }{ n } =1\quad \Rightarrow \quad 170.95-1.7095n=n\quad \Rightarrow \quad 170.95=2.7095n\quad \Rightarrow \quad n=63.0928

まとめるとWINのカードが64枚以上、必要だと言う事になる。

f:id:cqbosinko:20181109172342p:plain

よくTVゲームで強さをレベルで表現しているが、この仕組みを利用しているのではないだろうかと最近考えている。

忘備録:フォント

日本語フォントを紹介している

fontfree.me

ライセンスフリーで高品質なフォント

  • Rounded M+

jikasei.me

  • M+ FONTS

M+ FONTS

高速道路の文字を再現しよう計画

  • 正式名称:GD-高速道路ゴシックJA-OTF (GD-HighwayGothicJA-OTF)

商用利用の場合、費用が必要
www.hogera.com