【結果発表‼︎】《第3回前哨戦》チップ予想レース♪
検索ワード「チップレース201701」
いつもお世話になっております、wzjmです。
第3回前哨戦は、1/14 0:15をもって終了いたしました。
ここからは、第3回前哨戦の結果発表となります。
まずは、最終結果は以下のようになりました!!
一番上が、今回のチップ予想レースの結果です。
フリータンクにINされた運営事務局宛のチップは、770MBでした。
賞品配分は以下のようになりました!!
はるかかなた様、優勝おめでとうございます‼︎
拍手‼︎ ☆*:.｡. o(≧▽≦)o .｡.:*☆
そして、入賞されましたるみぞう様、かえで先輩、asika18様、ベルりん様、おめでとうございます！
賞品は既にお贈りしております。1/16までに受け取ってくださいませ。
6位以下を含めた全結果は下記のようになっております。
結果発表は以上となります。
...が、1/23からはいよいよ本戦の1月度フリータンク予想レースが開催されます!! こちらもぜひご参加ください!!
...そして、1月度フリータンク予想レースのスポンサー様もまだまだ募集中です‼︎
次回の前哨戦は、現在は未定となっています。もし、第4回前哨戦を開催する際は、改めて告知をしたいと思っております。
以上、wzjmでしたm(_ _)m
78 件のコメント
コメントするには、ログインまたはメンバー登録（無料）が必要です。
少し遅いですが、あけましておめでとうございますm(_ _)m
前哨戦は私wzjm所有のパケットで行います。
今回の前哨戦は12月度フリータンク予想レースで補填を賜った分7,500MBが賞品総量です。
正式には、1月度フリータンク予想レースのスポンサー様募集はこの前哨戦後を予定しております。...が、せっかくのお申し出ですので、1月度フリータンク予想レースのスポンサー様として、330MBのチップBKGKで承りました(o^^o)
今年もよろしくお願い申し上げますm(_ _)m
定期的に企画をUpして戴き有り難うございます。
予想を考えようとしたのですが、ルールを見ていて理解できず、確認したいことがあります。
予想する容量は、「1月13日一日だけの“日量”」でしょうか。
それとも、「1月13日までの“累計”」でしょうか。
解読力が低くてすいません。明示戴けると嬉しいです。
>4Lavie様わかりづらい文章で申し訳ございませんm(_ _)m
上の図の吹き出し部分が今回予想していただく部分です。
本文も修正・加筆させていただきました。
説明有り難うございます。
予想開始しますw。
本年もよろしくお願いいたします。
いつも大外れですが、トップバッターで予想いたします。
②1/13運営事務局宛へのチップ容量：1,700MB
よろしくお願いします。
シンプルに、1/14にフリータンクにINされる運営事務局宛のチップ容量のみにさせていただきました。
これから予想をしようとお考えの皆様、申し訳ございませんm(_ _)m
そして、「ナイス！」アンケートをこれから行います。
...という方は、↓こちらに「ナイス！」
...という方は、↓こちらに「ナイス！」容量は枯渇しても、制度は存続するように、運営さんが工夫してくれることを期待しています。
パケット交換スレッドで待機している間に、過去の運営事務局のフリータンク投入実績を調べてみました。その結果、投入は0時15分だね、と言うこと以外何も解りませんでした。(;｡;)
『最後はカンで』990MBと予想します。
よろしくお願いします。
運営事務局宛てのチップがINされるのは0:15ですか。
参考にさせて頂きますm(_ _)m
こういった予想スレに参加するのは初めてですが、よろしくお願いします。
お気に入りにも登録しました。
「1/14にフリータンクにINされる運営事務局宛のチップ容量」は1,280MBでお願いします。
スレを紹介していただいたついでに厚かましく宣伝させていただきますが、
現在mineoの通信速度を集計するスレを作って日々集計し、結果をアップしています。
ユーザーの実環境ではどの程度の通信速度があるかを見てわかるスレを目指しています。
ご興味がありましたらぜひ一度ご覧ください。
気軽に測定結果をアップしていただけるととても嬉しいです。
https://king.mineo.jp/my/Tokos/reports/11452
それでは失礼します。
2,220MB
当てる気？参加する事に意義がar....
よろしくお願いします^^
観察しても確率は上がらないと考えるのでヤマカンで、
2,500MB
(^o^)
全然想像出来なくて、数日悩んでいました(笑)
3500MBで よろしくお願いします(^-^)
1,560 MBで
お願いします(o゜◇゜)ゝ
あと、フリータンクの枯渇ですが、どのような条件で判定するのでしょうか？
フリータンクは常にIN,OUTされているので、一瞬でも残容量が0MBになったという場合でも、タイミングによっては見過ごしてしまう可能性があります。
例えば、
・残容量0MBの瞬間が一度でも確認された場合。
・残容量が1000MB未満の状態が一度でも確認された場合。（一発で0MBにできる状態）
・1日の終わり（マイネなうのグラフに現れる数字）が、1000MB未満で終わったとき
などの条件があるような気がするのですが、どうでしょうか？
1,230MBでお願いします(^^)
枯渇の定義ですね。
そもそも「枯渇」の意味は、Google先生いわく、
①ひあがって水（マイネ王ではパケット）がなくなること
②尽き果てて、なくなること
とのことです。
ですので、①の意味通りと解釈しますと、フリータンクが０MBとなる瞬間が拝めれば、「枯渇した」と言えます。
ベルりん様が仰るように、その瞬間は拝めないかもしれません。しかし、マイネなう掲載の、INとOUTの容量は1時間ごとの更新の仕様になっていますので、ここでIN=OUTになっていれば、「枯渇した」と言えます。
あくまでも、私個人的な感覚ですが...σ(^_^;)
やはり、そうですよね。
>マイネなう掲載の、INとOUTの容量は1時間ごとの更新の仕様になっていますので、ここでIN=OUTになっていれば、「枯渇した」と言えます。
マイネなうの表示がIN=OUTとなるためには1時間ごとの更新のタイミングでちょうど0MBとなっていないといけないので、0MBの瞬間を拝むより難しいかなと思います。
私の知る方法だと、残容量が0MB近くなったら、随時フリータンクを確認して、０MBとなる瞬間を見るか、残容量が1000MB以下になっていたら、IN.OUTの履歴をたどって0MBになっていたかを検証するしかないのかなと思っていますが、どうでしょう？（その場合、証拠はスクリーンショット？）
ただ、残容量が1000MB以下となってから、残容量ぴったりに引き出す人がいなければ、実質枯渇状態であったとしても、0MBになる瞬間というのはない場合もあるかもしれません。
ほとんどの人がOUTが1000MBということなので、1000MB以上になってからOUTするという行動をとる可能性もあります。また、心理的に残容量ぴったり引き出して0MBにするのに抵抗がある人がいるかもしれません。
#あえてOUTして枯渇させてみるという意見の人もみたことあるのでその人ならOUTするのでしょうけど。
例えば、一定時間1000MB以下になる状態が続いて実質枯渇しているという状態だったとしても、0MBになる瞬間がなかったら、どう判断するでしょうか？
4280MB
枯渇のイメージですが、
まず、平均的に一時間当たりまたは一日あたり何人が引き出しているのでしょうか？
平均的な引出し人数✕1000MB≒フリータンク残量
で良いかと考えます。
1/10 9:33現在の予想分布です。降順で示しています。
>C62-48様>>まず、平均的に一時間当たりまたは一日あたり何人が引き出しているのでしょうか？
10月度からの表ですが、こんな感じです。単位はGBで、1GB=1,000MBとして、10MB以下は四捨五入しております。
これは表示として 0MB の瞬間をキャッチ出来るかという問題だけでなく、
・800MB の残量しかない場合に 1,000MB 引出しの操作があった場合にシステムがどのように反応するか？ という設定（プログラミング）にも関連します。
＊可能性(1) 800MB の引出しを許す。
＊可能性(2) 引出しを許可せず要求を失効させる。
＊可能性(3) 引出しを許可しないで、タンクの残容量が 1,000MB 以上になるまで引出しを待機させる。
＊可能性(4) この引出しを許可しないが次の 800MB 以下の引出しを先に実行する。 etc. etc. ・・・
つまり、システムの詳細を知らないとこの議論は先に進めないと考えます。 (^_-)-☆
1日の引き出し人数ですが、日によってかなり違いがあり、特に21日と月末には、多くの人がOUTするので、
平均的な引出し人数✕1000MB≒フリータンク残量
では判断難しいところです。
特に月末近くの底になる近辺では、1日のなかで、INとOUTが拮抗しているので、午前0時の残容量から上記の式で計算しようとしても、平均的な人数がわからないですし、OUTの人数だけでく、INの容量を予測しないといけません。
> 呑気呆亭さん
さすがに、残容量がマイナスになることはなく、引き出し容量が残容量以下となるチェックは入っていると思いますが、実際にやってみないとわかりませんね。でも仮にマイナスがあるとすれば、0MB以下で枯渇ということはできると思います。
問題は、画面の表示時には、残容量が1000MB以上あって、1000MB引き出そうとしたときにはすでに他の人が引き出して、1000MB以下になっていて引き出しに失敗した場合などでしょうかね。その場合、実質枯渇ではあるのですが、一度失敗してあきらめて引き出さなかったら、0MBにはなりません。
まぁ、細かいことは抜きにして、グラフの形から0MBにぶつかった感じになれば、0MBの瞬間がわからなくても枯渇したということは言えるかもしれません。
ただ、心理的な影響もあって、グラフのそこも0MBすれすれの状態でなだらかになり、かつ、0MBの瞬間も拝めなかったら、枯渇したのかぎりぎり持ちこたえたのか、判断の分かれるところですね。
なので私としては、
・残容量が1000MB未満の状態が一度でも確認された場合。（一発で0MBにできる状態）
であれば、枯渇したといってもよいのかなと思うのですが。
これ位のアバウトで充分でしょう。 (^^)/~~~
『枯渇の定義』について、横から参加させてください。１．Outの傾向について
たまたま消し忘れた、2016年12月30日午前0時から12時までのログを見返したたところ、549件のOutが有りました。
その内506件(92.2%)が1,000MBの引出でした。ですので、荒っぽい前提としては、Outは1,000MBと仮定しても大きな齟齬は無いと思います。
２．Outで容量がマイナスになる時のフリータンクの動作について
呑気呆亭さんが仰るように、色々な動作が考えられます。
可能性(5)として、そのまま引出しを許可し続けて、翌日(何時からかは解りませんが)
運営の『凍結宣言』を持って引出しを止める。つまり、容量がマイナスになることも考えられます。
『引き出せないけどなぜだ～～』で、Q&Aや掲示板、問い合わせが“祭り”になる事を
運営が予想すれば、ですけど。。。
３．枯渇定義の提案
以上を踏まえて、この様な定義は如何でしょうか？
CaseⅠ：容量がマイナスになった場合→始めてマイナス値を得たタイミング
CaseⅡ：容量が1,000MB前後に張り付いた場合→始めて1,000MB以下になったタイミング