引用:
|
作者EIGHTS
轉影片都是整數沒錯啊
因為 RGB 都是整數
字元處理也都是基於 Byte
壓縮法只是多 Byte 合拼再存成 Byte，也還是整數
|
這段話可能不是很正確, 而且會造成別人觀念上的誤導
轉影片檔, 只要牽扯上破壞性壓縮, 基本上目前有用的演算法(H264/MPEG2/DivX... etc.)
一定會用到浮點運算, 這跟資料來源或是資料存放的格式無關
引用:
|
作者EIGHTS
一般用途，像我們平常做做文書
是用不到浮點運算的
|
一般用途也是會用到浮點運算的, 只是比較相對的低
引用:
|
作者EIGHTS
遊戲的話應該也不需要浮點運算
3D 處理 (除非是 3D 繪圖軟體) 也不需要太精準
因為顯示的畫面像素不會有 0.1
只要約略就好了
|
如果是單純去處理畫面的話, 當然可以利用近似或是一些技巧去避免浮點運算
但整個遊戲不見得會完全不使用浮點運算
早年DOS時代, 有些CPU沒有FPU, 所以基本上是能避則避, 但現在不見得需要這樣搞
引用:
|
作者EIGHTS
因為浮點運算一定比整數運算慢
所以程式設計師都會避開浮點運算
只要用點程式的小技巧就能很快速的處理有小數點的計算了
浮點運算除非特殊用途
不然，真的很少用到
以上有點亂的解釋不知道你能不能了解?
簡單講
基本上基於 Byte (位元組) 的運算
都是整數運算
|
浮點運算確實是比整數運算複雜, 他的電路也大了多
但按照現在CPU的架構, 大多的指令都是1個週期就完成了, 浮點數不見得會有多慢
一些計算我們確實直接用整數去計算會得到比較快速的效果, 比如說色空間轉換
雖然說係數都是有小數點的, 但取最小倍數, 配合位移指令, 直接使用整數的簡易計算
可以避免整數與浮點數資料轉換造成的額外運算需求, 確實可以得到性能上的提升
但浮點運算不會只是特殊用途, 也不會是很少用到
而整數運算跟是不是byte為基本單位似乎也不完全有正相關
就拿影像處理軟體來說好了, 一張標準的Truecolor(24bits) bitmap,
如果你要做影像柔焦效果, 裡頭應該也是直接用浮點運算會更直覺有效