クイズ

１ターンです💝

>> ひろちゃんよ さん

中途半端な書き方をして申し訳ないです。
「クリア目標歩数」ではなく「初期設定歩数」です。

730歩

722歩でお願いします。
ありがとうございました。

655歩👓✨
…ぐらい😅

520歩でお願いします😊

おはようゆるゆる～😆🎵🎵
777歩🌷

999歩👣

ありがとうございました☻✨

Ticket to the moonさん、おはようございます😃
20歩でよろしくお願いします🐞♪(❛ᴗ❛人) ♪happy ♪🍀

Ticket to the moonさん♬
おはようございます😊
　
700歩で設定！
　
よろしくお願いします🎃

ハロウィン🎃の季節なので
333歩の設定にします。

Ticket to the moonさん

こんにちは～
クイズ 参加させてくださ～い🙋

【 999 歩 】にしてみます！

よろしくお願いします🙇

「699」でお願いします。

閑では無いけれどつい検証しようとしてしまったのですが皆さん1ターンでクリア？
初期体力は730ターンでお願いします(^^;)

７２２歩
２か月前にTicket to the moonさんがほぼおっしゃっていた通りで、ゲームエンジンUnityのMathf.Round()関数は偶数丸め（銀行丸め）を行っているみたいですね
表計算で偶数丸め（銀行丸め）しましたけど、絞り込むのに苦労しました🥴

---
当たった人には、
１番目：100MB
２番目： 80MB
３番目： 60MB
４番目： 40MB
５番目以降：20MB
進呈いたします。
---
の予定でしたが、少し増やそうと思います。
ふと見ると、挑戦者の方が多い。検証した方がいらっしゃるってことですが、「2歩毎に王冠でクリックを強いられる」そんな環境で長距離を歩かせてしまったので、
---
１番目：200MB
２番目：150MB
ニアピン１等賞：100MB
ニアピン：50MB
---
に変更いたします。さらに、参加賞をチップ１個から3個に増量しました。

>> yossy_44 さん

ニアピン１等賞、100MBを進呈させていただきます。

>> spbn さん

まさか、722歩も歩いて調査するとは、思いませんでした。当たり１番目、200MBです！！！

>> B-Labyrinth さん

ニアピン賞50MBです。

>> Herb tea さん

答えは722歩でした。
ご参加、ありがとうございました。

>> ゲリオン さん

ニアピン賞の50MBです。
ありがとうございました。

>> ねぼまぼ さん

答えは722歩でした。
ありがとうございました。

>> 🍀vivi🍀 さん

722歩なので、「かなり違う」ってレベルです。
ありがとうございました。

>> つぼちん さん

パチンコですね。ありがとうございました。

>> Katze さん

残念、722歩でした。
ありがとうございました。

>> 弥哉 さん

ニアピン賞のタワシ５個です。
ありがとうございました。

>> noel さん

ニアピン１等賞なので、100MB進呈させていただきます。
ありがとうございました。

>> むぃ さん

当たり２番目！150MBをプレゼントいたします。
UnityのScrptがC#らしいのですが、C#では銀行丸めが採用されています。たぶん、GUI部品がC#で作られていて、今回の現象に繋がったんだと思います。

ランキングとチップありがとうございました😊

10%の10倍のつもりが9%しか歩いてないから
1割足りないんですよね💦
コメントした後気づいて失敗したと思いました😅

私は確か、26ターンぐらい歩きました。
700前後だとは思ったのですが、思ったより多かった。
タワシ5個ありがとうございます。

>> Ticket to the moon さん

おはようございます😊

正解発表と参加賞を
ありがとうございました🙇

大ハズレでした😅

≫ 入賞の皆さん

すごいですね～
おめでとうございます😊👏👏👏

>> むぃ さん

この件に関してですが、銀行丸めなんて銀行にやらせとけばエエことやと思います。銀行に関しては、銀行丸めは有効です。でも、他の用途に関しては、銀行丸めって邪魔でしかない場合が多いです。
C#で銀行丸めをデフォルトにしたって、MSのプログラマーは絶望的にセンスが無いと思います。

【合計した時の誤差が減るって言ってるけど】
「2.5, 4.5, 2.5, 0.5」だと、合計は10なのに丸めてから合計すると四捨五入でも銀行丸めでも8なので、改善されない。
4個でなく大量の要素の場合には、確率的に誤差が減るので、銀行の場合には有効。
そもそも、丸めてから合計するって考え方が間違えてる。合計する必要性があるなら、合計してから丸めるべき。
銀行の場合には、口座毎に丸めてから合計するので、有効。

【小数点1桁までしか意味を為さない】
0.5を判定する場合ですが、2進数で
xxxx.011111111111後ろどこまでも1
xxxx.100000000000後ろどこまでも0
xxxx.1後ろのどこかで最低1個の1がある
と、上は小数点以下は0.5以下、真ん中が0.5丁度、下は0.5より上って保証があります。四捨五入も銀行丸めも話は簡単です。
小数点2桁目で、数学的(と言うよりも数値演算的)に破綻します。
「0.05」は2進数で無限少数になります。1/3は10進数で0.3333と無限少数で3進数なら0.1と有限になりますが、同様に0.05は2進数では無限小数です。0.05であるかどうかを厳密に判定するなら、メモリを埋め尽くすまで精度を上げても無理です。
銀行の場合、小数点1桁目の話なので、有効です。

元々、銀行用に設計されたSQLなら銀行丸めを採用する意義はあると思います。汎用言語に銀行丸めなんて百害あって一利なしです。
このぐらい軽く考えただけでわかる話なのに、曲がりなりにも超大手ITが仕出かすのは、、、、、