手機回文
印象中好像在板上看過不少次相關討論了
覺得好像可以來簡易科普一下
不知道發了會不會有點掃興，不過還是簡介一下
關於算術這件事情，其實就理論而言都很理想跟直觀
但真的牽扯到實作的時候，就會衍生很多細節
先來簡單舉個例子：
假設現在要做算術運算，而你只有一張紙
上面只有10個格子，而且你只能寫下0-9
最直觀的方法就是寫下多少就是對應的十位數整數
然後此時就可以推論出一些限制：
1. 範圍為0-9999999999的整數
然後就會問說，那負的怎麼辦？
所以我們把第一格寫1表示負0表示正
於是範圍變成 -999999999～999999999
雖然可以表示負數了，但最大值也被壓縮
但可能目前實務上不太可能超出上下界
於是乎開發人員就這麼決定了表示式
而過了好幾年，數字運算上開始會有超出範圍的需求
可能就會有人提出建議
「用科學記號不就好了，國中沒畢業嗎？」
好的，於是我們改變表示式的定義：
前八碼為科學記號前面的數字，後兩碼為10的次方
比方說 1 2 3 4 5 6 7 8 9 9 表示 1.2345678 * 10^99
若是有負的需求就再讓一格，而這樣改進以後
上下界的範圍被大大提升了，感謝這位聰明的先知
其實類似的概念就是變數型態裡面的浮點數
而為什麼這麼簡單的道理人家卻不採用呢？
現在我們回來思考一個問題：
以上述例子而言，表示式是怎麼對應到值域內的？
十個格子，無論怎麼表示，都最多只能表示100億個數字
而只有整數表示是可以在範圍內全部列舉的
這也是浮點數運算一個危險的地方，精準度
對電腦運算上，(1e50+1) - (1e50) 答案可能不會是 1
通常浮點數也是拿來算個近似值而已
以算傷害的需求而言我想並不太適當
最後做個總結：
1. 數值運算有上下界是因為實作限制
2. 整數運算較具有精準性
但回歸目前的使用狀況，要能不怕超出範圍也不是不可能
定義一個變數型態，然後覆寫四則運算及比較邏輯
讓它可以動態擴張自己的記憶體大小應該就可以達成
畢竟怪的血量目前不會超出int的範疇，而是否打死也只是一個比較邏輯而已
作者:
drajan (EasoN)
2018-08-22 14:22:00好像在看我同事的code review 長篇大論一長串（讚美）
所以為什麼要用int而不用跟實際傷害顯示一樣的code
作者: hok 2018-08-22 15:22:00
嗯嗯，跟我想的差不多
他是說小字已經可以顯示超過21e，max damage卻還是用int
文組問個，為啥堅持要用int 不用long long之類的
跟資源規劃有點關係，傷害值的資料型態在非常早期就必須決定，那時無法預測傷害的範圍，為了不知多遠的將來(誰知道這遊戲活這麼久？)先把傷害值的資料型態調整成 long 甚至更大範圍，只是浪費手機的資源而已，因為即使數字很小，花費的空間都是相同的。極端一點來說，甚至有可能因為這樣的資源浪費，造成某些較低階的手機無法進行遊戲。以一個大型project來說，底層的code基本都沒什麼人想動，因為很容易搞出大問題，比較經典的例子，應該是WoW(魔獸世界)的16格包包問題，有興趣的話可以查查看。
作者:
krizarlid (Let's Go Cubs !)
2018-08-22 15:45:00自己寫個物件然後overload實作operator = =?會造成這樣的原因很簡單 code不是一個人maintain的有些東西就是牽扯太多不好改
作者:
SamFuld (山佛)
2018-08-22 15:58:00沒錯，你把我想講的全部講完了
作者:
aki1023 (秋月)
2018-08-22 16:22:00快推免得别人以為我們看不懂
作者:
wak (默艾)
2018-08-22 16:56:00應該很快就會有21億血量的怪，然後21億的防禦，再無視破防..
作者:
arsia (陳阿生)
2018-08-22 17:12:00英文系畢業表示完全看不懂
作者:
pdemonq (魯味不夠魯)
2018-08-22 17:19:00無視破防？ 傷害盾不就是了嗎？
作者:
wak (默艾)
2018-08-22 17:48:00不太一樣。防禦力是牆(低於防禦傷害為0)，傷害盾是比例弱化
好奇這種手遊都是用C實作的嗎？我學的code很多都不用自己宣告變數型態
作者:
beef68 (牛肉)
2018-08-22 19:01:00其實就是太多了難改 但這個功能應該比小字的晚吧 小字都用大數存了 max damage沒辦法很怪
整數用int真的很直覺 更何況還比long好打多了 打long還要動到無名指 超不方便 ㄎ
作者:
surimodo (好吃棉花糖)
2018-08-22 19:28:00new int[1000];
作者:
krizarlid (Let's Go Cubs !)
2018-08-22 19:46:00進位簡單啦 MCU的資料都是兩個8接一起 只是這樣寫有浪費空間的嫌疑資料沒大到需要封裝 這樣接不是很好
作者:
Bensonoc (Bensonoc)
2018-08-22 19:50:00嗯嗯跟我想得一樣
作者:
g06cj6 (闇月夜)
2018-08-22 20:19:00對於會寫出風暴這種智障技能的工程師，我是不會指望他們能把事情做得多好啦
作者:
dsa3717 (FishCA)
2018-08-22 20:19:00這是歷史共業
作者:
chigi ( )
2018-08-22 21:13:00其實有個很實際的考量，就是畫面長度在畫UI的時候，上面能夠提供寫數字的範圍是有限的，位數增加時勢必會讓字體變小或是其他狀況，導致UI效果差你看他在寫超過21e的時候並不是overflow，表示工程師有考慮超過時的狀況，評估結果後捨棄精準的數字 反正這數字只是爽這樣的UI設計理念事實上很清楚也很簡單
作者:
drajan (EasoN)
2018-08-22 21:59:00我想樓上是對的 畢竟沒有overflow
作者:
krizarlid (Let's Go Cubs !)
2018-08-23 00:06:00當然 當你的Data因原先的Container總是會有不正常行為本來就需要繼承或定義新的物件來封裝
作者: BaseGi (Gary) 2018-08-23 01:46:00
這篇好認真 推一個