CHUNITHM レーティング考察日和 TOP

はじめに

 この記事は随時更新対象記事です。
何の注釈もなく更新することがございますが、予めご了承ください。
(最終更新 2019/03/22)

まとめ

今現在、最新の推測をまとめた記事です。
max-eipi-chunithm-rating.hatenablog.com

経緯

これまでの推測に至る経緯をまとめた記事です。
max-eipi-chunithm-rating.hatenablog.com

雑記

R枠と直接関係のない話題をまとめた記事です。
max-eipi-chunithm-rating.hatenablog.com

Recent枠遷移の推測[経緯] その7

おさらい

前々回で削除対象の推測 ver.4 は誤りだと結論付け、前回で一転してやはり正しかったのではという見込みが立ちました。
今回の検証でそれを裏付けようというのが前回までの概略。

検証

方針

丸め無しで仮定した場合、RC枠にプレイレート6.00xxxxのプレイデータが存在するため、プレイレートがそれより大きく、6.01より小さいプレイデータを入れ、表示レートの変動を観察する

検証仮定

docs.google.com

  1. 4.0:[1007500,1010000]で1回
  2. 0で1回
  3. 6.0:(975000,975250)で1回。
    ただし、丸めなしプレイレートが、RC枠最古のプレイデータのプレイレートより大きいこと
  4. 0で1回

各過程の意図

  1. RC枠最古のプレイデータを調整するため
  2. 上記同様
  3. プレイレートの丸め有無を調べるため
  4. RC枠内の有効なプレイデータの個数を調べるため

考察

手順3において、丸め無し/有りでそれぞれの仮定で次のように変動します。
・丸め無し仮定 : 変動なし
・丸め有り仮定 : 0.15増える
実際の変動では0.15だけ上昇しており、丸め無しを仮定すれば矛盾し、丸め有りを仮定すれば一致します。
さらに、手順3終了後におけるRC枠最古のプレイデータはそれぞれ、
・丸め無し仮定 : 無効なプレイデータ
・丸め有り仮定 : 有効なプレイデータ
であることが分かっていたため、念のため手順4で0を入れることで、RC枠最古のプレイデータが有効なプレイデータであることを確認しました。

削除対象の推測 ver.4 を仮定して、改めてこれまでの検証過程を舐めてみると、実際の変動と完全一致しました。
現状この推測が一番信頼性が高いので、しばらくはこの推測をもとにフリーでプレイしてみて反例がないかをチェックします。

その前に、削除対象の推測 ver.4 の適用条件に関して便宜上置き換えたい箇所があるので、最後にそれを示します。

削除対象の推測 ver.4-1

適用条件1
最新プレイデータのプレイレートがR枠最小プレイレートより大きい
適用条件2 最新のプレイデータについて、プレイレートがR枠最小プレイレートに等しく、スコアがR枠最小スコアか1007500点のうち、大きくない方のスコア以下である
削除対象 RC枠の中で、プレイレートが最新プレイデータのプレイレート未満であるプレイデータの内、最古のプレイデータ

この適用条件2を次のように置き換え、それを 削除対象の推測 ver.5-1 とします、

削除対象の推測 ver.5-1

適用条件1
最新プレイデータのプレイレートがR枠最小プレイレートより大きい
適用条件2 最新のプレイデータについて、プレイレートがR枠最小プレイレートに等しく、譜面定数がR枠最小譜面定数より大きい
削除対象 RC枠の中で、プレイレートが最新プレイデータのプレイレート未満であるプレイデータの内、最古のプレイデータ

今後の方針

シミュレータを手元で実装したため、しばらくはある程度フリーでプレイしてみてシミュレータから得られるRC枠の変動と実際の変動を観察していく方針です。

まとめ

削除対象の推測 ver.4 は現状一番信頼性が高い推測である。
削除対象の推測 ver.4-1 の適用条件2をわかりやすくスコアから譜面定数比較に置き換え、それを削除対象の推測 ver.5 とした。

[削除対象の推測 ver.5]
削除対象の推測 ver.5-1

条件1
最新プレイデータのプレイレートがR枠最小プレイレートより大きい
条件2 最新のプレイデータについて、プレイレートがR枠最小プレイレートに等しく、譜面定数がR枠最小譜面定数より大きい
削除対象 RC枠の中で、プレイレートが最新プレイデータのプレイレート未満であるプレイデータの内、最古のプレイデータ

削除対象の推測 ver.5-2

条件1
ver.5-1 の条件を満たさないが、最新プレイデータのスコアがR枠最小スコア以上である
条件2 ver.5-1 の条件を満たさないが、最新プレイデータのランクがSSSである
削除対象 最新のプレイデータ

削除対象の推測 ver.5-3

条件
ver.5-1、5-2 の条件を両方満たさない
削除対象 RC枠最古のプレイデータ

Recent枠遷移の推測[経緯] その6

前回のおさらい

前回はver.4が誤りであると結論付け、比較時にプレイレートが丸められていないと推測しました。
今回の検証では、その真偽を確かめていきます。

検証

方針

  • 比較時にプレイレートが丸められていないと仮定する
  • プレイレートrがRC枠の最小プレイレートr'に対してr'<r<r'+0.01となるプレイデータを入れて表示レートの変動を観察する

過程

※表記についての補足
プレイデータを譜面定数:(スコアの区間)で表します。
e.g.)
・譜面定数が4.0、スコアが1007500以上1010000以下
 ⇒4.0:[1007500,1010000]
・譜面定数が6.0、スコアが975000より大きく975250未満
 ⇒6.0:(975000,975250)
また、単に定数Pで記載している場合は、プレイレートがPとなるプレイデータを指します。

  1. 4.0:[1007500,1010000]で1回
  2. 6.0:(975000,975250)で1回
  3. 0で1回
  4. 6.0:(975000,975250)で数回
  5. 0で数回

docs.google.com

過程の補足 および 考察

§1 検証開始から丸めの誤認識に気付くまで

まず、手順1でR枠内全てのプレイデータを有効*1にします。(検証過程No.1)
次に、手順2でレートの丸めを確認するための準備をします。(検証過程No.2)

ここで、No.2のプレイにおいてどのプレイデータが削除対象になるかを考えます。

[削除対象の推測 ver.3]
削除対象の推測 ver.3-1

適用条件
最新プレイデータのプレイレートがR枠最小プレイレートより大きい
削除対象 RC枠の中で、プレイレートが最新プレイデータのプレイレート未満であるプレイデータの内、最古のプレイデータ

削除対象の推測 ver.3-1 の適用条件から、最新プレイデータのプレイレートとR枠最小プレイレートを比較します。
仮定より、比較時のプレイレートは丸められていないため、最新のプレイデータのプレイレートは6.0048、R枠の最小プレイレートは6.00になります。
(最新プレイデータのプレイレート)>(R枠の最小プレイレート)であるため、削除対象の推測 ver.3-1 の適用条件を満たします。
したがって、削除対象となるプレイデータは次を満たすものです。
RC枠の中で、プレイレートが6.00(?)未満であるプレイデータの内、最古のプレイデータ
これに当てはまるプレイデータは、前回の検証過程No.12(プレイレート0)です。
よって、No.2をプレイすると、有効なプレイデータがRC枠に11個存在することになります。
この状態で無効なプレイデータ*2を1個入れ、有効なプレイデータが1個抜けたとしても、残り10個存在するので表示レートは下がらないと予測できます。

しかし、手順3(検証過程No.3)で減少したため矛盾します。
削除対象を抽出するときの比較に関しては丸めを意識しておらず、今まで通り丸められている値を採用していました。((?)の部分)
このときの比較でも丸められていないと仮定すると、削除対象は次を満たすプレイデータになります。
RC枠の中で、プレイレートが6.0048未満であるプレイデータの内、最古のプレイデータ
これを満たすプレイデータは、前回の検証過程No.3(プレイレート6.00)になり、推測される表示レートの変動と実際の変動が一致します。

§2 そして再び ver.4 へ

比較時全般においてプレイレートが丸められていないことを確かめるべく、手順4を行います。
そうすると、予測した変動と実際の変動が一致したため、「やはり比較時全般においてプレイレートは丸められていないのだろう」と断定しかけましたが、あることに気付き踏みとどまりました。
あることとは、「ver.4でも同様に変動するのではないか?」「別に丸めは関係ないのではないか?」ということです。

今、二つの互いに排他的な推測が存在します。

A 比較時全般においてプレイレートは丸められていない
B プレイレートは始めから丸められている
プレイレートがR枠の最小プレイレートに等しいときはスコア(ないしは譜面定数)と比較する

それぞれのRC枠の変動を見比べてみると、前回の検証仮定No.32がAだとRC枠に入らず、BだとRC枠に入るという違いがありました。
前回の検証過程No.32がRC枠に入っているかいないかを割り出すために手順5を行います。
すると、検証過程No.29で表示レートが下がりました。これは、Bを仮定した時の変動と一致します。
Bは削除対象の推測 ver.4-1 と同義ですから、ver.4 が誤りでない可能性が出てきました。

今後の方針

一転二転してしまいましたが、削除対象の推測 ver.4 に立ち返ります。
その上で、今度は「プレイ終了の時点でプレイレートが既に値が丸められている」ことを裏付けていきます。

まとめ

  • 前回の検証では削除対象の推測 ver.4 が誤りであると結論付けたが、考え直したところ誤りではない可能性がある
  • プレイレートの丸めについてはまだ明確ではないが、始めから丸められている可能性の方が高い

*1:『有効なプレイデータ』を、プレイレートが0より大きいプレイデータ と定義します

*2:『無効なプレイデータ』を、プレイレートが0のプレイデータ と定義します

Recent枠遷移の推測[経緯] その5

削除対象の推測 ver.4 を突き詰める

前回の検証より、削除対象の推測 ver.4 が立てられました。
ver.3からの変更点として、赤字部分が追加されています。

[削除対象の推測 ver.4]
削除対象の推測 ver.4-1

条件1
最新プレイデータのプレイレートがR枠最小プレイレートより大きい
条件2 最新のプレイデータについて、プレイレートがR枠最小プレイレートに等しく、スコアがR枠最小スコアか1007500点のうち、大きくない方のスコア以下である
削除対象 RC枠の中で、プレイレートが最新プレイデータのプレイレート未満であるプレイデータの内、最古のプレイデータ

今回はこの推測について追究していきます。

検証

検証過程は下記スプレッドシート内にあります。

検証方針

削除対象の推測 ver.4-1 の条件2が成り立つかを検証します。
RC枠={p_1,p_2,p_3, ... ,p_30} (p_nはプレイデータ) が、次の条件を満たすとします。

  • p_1からp_10は全て譜面定数が等しく、ランクがSSSである
  • p_11からp_30は全てプレイレートが0である

この時、次のようなプレイデータpを追加した時にRC枠がどのように変動するかを調べます。
p : ランクSSS未満S以上で、かつプレイレートがp_1のプレイレートに等しい

検証過程

  1. RC枠を空にする
  2. 譜面定数4.0の楽曲をランクSSSで10回プレイする
  3. プレイレート0で20回プレイする
  4. 譜面定数6.0の楽曲をスコア975000で1回プレイする
  5. プレイレート0で2回プレイする

結論

削除対象の推測 ver.4-1 の条件2は成り立たないことが判明しました。
『検証過程』シートのNo.33でレートが下がっていることを確認できると思いますが、推測に沿うならばNo.34でレートが下がっていてほしいのです。

以下そのことについて説明していきます。
説明の方針は次の通りです。

  • No.31以降のプレイでRC枠に何が入り何が抜けるのかを考える
  • この時の表示レートの変動を考える

まず、No.31のプレイが終了した時を考えてほしいのですが、この時点でRC枠はNo.2からNo.31の30曲であることは直感的にわかります。
次にNo.32をプレイした時を考えます。ver.4-1 条件2を見ると、
最新のプレイデータについて、(プレイレート)が(R枠最小プレイレート)に等しく、(スコア)が(R枠最小スコアか1007500点のうち、大きくない方のスコア)以下である
とあるので、それぞれの値を比較していきます。
(プレイレート)⇒6.0は、(R枠最小プレイレート)⇒6.0と等しく、(スコア)⇒975000点は、(R枠最小スコアと1007500点のうち、大きくない方のスコア)⇒1007500点以下であるため条件を満たします。
したがって、削除対象となるプレイデータは
RC枠の中で、プレイレートが最新プレイデータのプレイレート未満であるプレイデータの内、最古のプレイデータ
となり、それはNo.12となります。
そこから、No.33、34によってNo.2、No.3が削除されていくのが ver.4 で推測した際の結果です。
(『推測通りなら』シートも併せてご覧ください)

押さえるべきポイントは、「No.32をプレイしたらRC枠にプレイレートが0でないプレイデータは一体どれだけあるのだろうか」という点です。
推測では、No.32をプレイするとそのようなプレイデータは、RC枠に11個入ることがわかります。(『推測通りなら』シートのE列を見てください)
その状態で1個抜けたとしても、残りは10個あります。プレイレートは全て6.0で統一されているので表示レートに変化はないはずです。
更に1個抜けるとどうなるでしょう。残りは9個となり、R枠のサイズ(10個)より1個少なくなります。ここでようやく表示レートが下がるのです。

しかし、検証結果より、1個抜けた時点で表示レートが下がってしまっているので矛盾します。
したがって削除対象の推測 ver.4-1 の条件2は成り立たないことが実証されました。

考察

ver.4-1 の条件2が成り立たないことが証明されたので、再び振り出し(ver.3)に戻ってしまいました。
他の比較要素として譜面定数も考えましたが、結局それもスコアと比較するのにほぼ同義であるため無意味です。
実際、「RC枠の最小譜面定数より大きい」という条件を仮定したとしても、結果は今回の検証過程より矛盾することが導けます。

ここで、「RC枠の最小譜面定数以下である」時は考慮しなくていいの?という疑問があるかもしれないので少し補足します。
等しい時は、削除対象は最新のプレイデータであることが検証済みです。
また、小さい場合に関してですが、譜面定数を比較して小さいということは、譜面を比較すると(レベルデザイン上の思想として)簡単であるということを意味するので、「同じレベルでRC枠が変化しないのだから、それより低いレベルによってRC枠が変化するのは考えにくい」という思想のもと省略しています。(ただし、必要に応じて検証はします)

話しは変わりますが、OPについていくつか検証をしました。
【雑記】OVER POWERとプレイレートの関連性について - CHUNITHM レーティング考察日和
【雑記】OP算出中の丸めについて - CHUNITHM レーティング考察日和
その中で次のような推測を立てています。

OP算出時に用いる拡張プレイレートは、

  • Sランク未満 ⇒ 小数第3位以下を切り捨てている
  • Sランク以上 ⇒ 小数第5位以下を切り捨てている(あるいは切り捨てられていない)

上記を基に、「もしかしたら比較時はプレイレートを切り捨てていないのではないか」という考えが浮かび上がりました。
その考えを軸に振り出しに戻ってみる、即ち ver.3 に立ち戻って改めて ver.4 推測時の検証を舐めてみると、(スコアを記録していないため細かいプレイレートを算出できていないのですが)十分にあり得ることがわかりました。
よって、今後の方針でも取り上げますが、プレイレートの丸めについて追究するべきだと考えています。

今後の方針

比較時のプレイレートの丸めについて調べます。

  • 今回の検証を終えた状態から、(4.0,1007500)を入れてR枠を一旦元に戻す
  • 譜面定数が6.0かつスコアsが 975000<s<975250 となるようにプレイする
    (切り捨てなしプレイレートpが 6.00<p<6.01 となるようにプレイする)

まとめ

  • 削除対象の推測 ver.4-1 の条件2が正しいかどうか検証し、正しくないことが判明した
  • プレイレートを比較する際の、プレイレートの丸めについて調べていく

【雑記】OP算出中の丸めについて

OVER POWER算出時におけるプレイレートの丸めについて

 OVER POWER(以後OP)の算出には、SSS以上の時も値が変化するプレイレートを用います。便宜上、このプレイレートのことをここでは拡張プレイレートとでも仮称しましょう。
 「そもそもプレイレートってなんだよ」という方は、次を御覧ください。
max-eipi-chunithm-rating.hatenablog.com

 通常のプレイレートは小数第3位以下を切り捨てていることが広く知られています。
 では、OP算出時に用いられる拡張プレイレートは、一体小数第何位まで有効なのかを調べるべく、とある方からデータを頂きました。
 次のスプレッドシートはそのデータを解析するために作成したものです。
docs.google.com
 シートの見方

  • (A列,B列,C列)=(譜面定数,スコア,ランプ補正)より、(D,E,F)=(拡張プレイレート,素点,OP)が算出されます。素点とは拡張プレイレートとランプ補正の和のことです。
  • G列を初期状態(上6曲がプレイ済み)として、1曲目、2曲目、3曲目…とプレイしていったときに、表示OPが一体どのように変動しているかが下に示されています。
  • 21行目(合計)は各列のOPの総和を、22行目(合計[.##])は21行目の値を、実機で表示されている桁数に合わせるために小数第3位以下を切り捨てた値です。

 ここでは、OP=(素点をセルB2で定義している値を基準に切り捨てた値)x5 という計算式でOPを算出しています。
 B2の値が0.01であれば小数第3位以下を切り捨て、0.001なら第4位以下、0.0001なら第5位以下と言った具合に素点を切り捨てています。
 試しにこの値を0.001にする(=小数第4位以下切り捨てにする)と、22行目と23行目の値が全く一致しませんでした。
 次に、0.0001にする(=小数第5位以下を切り捨てにする)と、22行目と23行目が完全に一致しました。

考察

 先述の調査結果から、拡張プレイレートは少なくとも小数第4位まで有効なのではないかと推測しました。
 あるいは、素点の時点で小数第5位以下に値を持たないことから、切り捨てすら行われていないのではないかと見ることもできます。
 また、過去の検証から、Sランク未満では拡張プレイレートは小数第3位以下を切り捨てているという推測を立てています。
 これらをまとめて、OP算出時に使用される拡張プレイレートの丸めについて次のように推測しました。

OP算出時に用いる拡張プレイレートは、

  • Sランク未満 ⇒ 小数第3位以下を切り捨てている
  • Sランク以上 ⇒ 小数第5位以下を切り捨てている(あるいは切り捨てられていない)

【雑記】OVER POWERとプレイレートの関連性について

概要

※2018/03/22更新 ボーダープレイレート表に誤りがあったため修正しました。

OVER POWER について

 CHUNITHM STAR PLUS で『OVER POWER』(以後OP)という機能が追加されました。この機能はレート、エンブレムに次ぐ腕前の指標となる機能です。
 OPはフォルダー別に数値として表示されますが、1曲単位で曲別OPが算出され、フォルダー内の曲別OPの総和がそのフォルダーにおけるOPとなります。

曲別OPについて

 算出方法は次の記事中にあります。
OVER POWERと定数調査 - HackMD

(定数 + スコア補正 + AJ/FC/AJC補正) * 5 = 曲別OP

 式に「定数 + スコア補正」とありますが、これはプレイレート算出を派生させたものになります。違いは、SSS以上においても値が変化するということです。
 曲別OP算出時におけるボーダープレイレートは次のようになります。
f:id:MAX_eipi:20180322235225p:plain

気になった点

 B枠やR枠の算出、RC枠削除対象の決定等に参照されるプレイレートは、常に小数第3位以下を切り捨てた値を使用していました。
 一方で、小数第3位以下を切り捨てたプレイレートを用いて曲別OPを算出すると、ゲーム上で表示されている値と異なることがあります。

 試しに、譜面定数 7.7 の楽曲で曲別OPとプレイレートについて検証してみました。

 この検証過程を見て3つのことがわかります。

  1. Sランク未満であれば、「OP変動(D列)」が「小数第3位以下を切り捨てたプレイレートから算出される曲別OP(E列)」と一致する
  2. Sランク以上では上記が一致しなくなる
  3. Sランク以上では、「OP変動(D列)」が「丸められていないプレイレートから算出される曲別OPの小数第3位以下を切り捨てた値(F列)」と一致する

 このことから、Sランク未満ではプレイレートの小数第3以下は切り捨てられ、Sランク以上だとプレイレートは丸めらない(あるいは、有効数字が増えている)のではないかと考えられます。

 逆説的ですが、これが元々のプレイレート算出にも関わることだとしたら、B枠やR枠の算出、RC枠削除対象の推測等に少なからず影響があります。プレイレートの丸めについてはさらに調査を進める必要がありそうです。

【雑記】目次

はじめに

 この記事は随時更新対象記事です。
何の注釈もなく更新することがございますが、予めご了承ください。