|
||
|
Major Member
 加入日期: Feb 2003
文章: 198
|
引用:
重疊和借用，我覺的是一樣意思耶  指正就沒價值嗎？指正的過程也是一種分享，不是嗎？ 我沒有主動的心意，但我不希望以訛傳訛。 我認為老師教錯一個東西，可能有30個學生學錯，影響是很大的。 只要是以"理"為準來戰，沒什麼不好阿，又不是人身攻擊。 真理越辨越明(?) 緩和氣氛變打迷糊帳，你要學術討論還是要聊天？ 早說嘛，聊天那就恕我不奉陪，反正無中生有也是可以的。 引用:
我很肯定阿，一個錯的例子不是爛例子嗎？所以那句我根本不想回了。 1.2 + 1.3，直接做，不要再加其他處理，起碼在我知道的語言裡，不會是叫整數加法。 assembly, c, c#, perl, java。 有貶低嗎？不懂的就不要亂講不是基本嗎？ 可以猜測、懷疑，那就不要用肯定句。 請問您是覺的我哪幾句貶低您？ 就我看到的程度是那樣，您還是沒回我您用什麼語言， 因為我在想是不是語法習慣的不一樣，造成 psudo code 的溝通困難。 我幹嘛要了解你其他方面，你講的話就代表了你的人的一部份。 我幹嘛要了解全部的東西，我知道我在說的這個東西就好了。 當然我也很可能有錯，那就指出來也很好阿。 引用:
照這種講法，幹嘛分整數還浮點運算，反正全部都是 Byte 運算。 "最後紀錄的還是像素的資料" 不對喔。保證沒有 pixel 資料，因為壓縮都以 block 為單位，object 還在夢裡。 所以我就覺的您是無中生有。 DCT/DWT -> quantization -> motion estimation -> run length coding 這是大概的流程。 反正你想講，先把這些基本搞清楚他們在做什麼事吧，不然你怎麼知道用什麼運算。 |
||||||||||
2009-02-07, 03:48 PM
#31
|
|
|
Junior Member
  加入日期: Jan 2007
文章: 800
|
什麼是浮點運算？很簡單，只要你有對浮點數的資料型態（float、double）作運算，這樣就是浮點運算。浮點運算可以用硬體（x87、sse等）去作也可以用軟體去作。
為甚麼會需要浮點運算，因為我們常常需要作實數運算，而浮點運算是計算機處理實數運算的一個較有效率但是有損精確度的作法（相反的作法就是大數運算）。或者從儲存的觀點來看，浮點數是計算機儲存實數的一個較有效率（固定空間）但是有損精確度的格式。 所以只要你的處理過程會需要實數運算，那就幾乎都會用浮點運算。跟你什麼pixel處理前處理後都是byte沒有關係。（而且大部分的影像影片壓縮格式都不是以pixel為單位） 不過影像影片壓縮的設計的確可能會故意把它作成允許完全以整數運算完成，以節省硬體實做成本。 其實樓主一開始提的問題很有趣，有受過計算機科學完整訓練的人大概都不會搞混，但是要解釋起來也不是簡單三言兩語說得清楚。 |
||
|
2009-02-07, 05:19 PM
#32
|
|
|
Senior Member
加入日期: Oct 2006
文章: 1,384
|
不過我的問題還沒找到答案呢
像資料檢索、DB的SQL各種operation 程式會寫是會寫 不過不知道他是算浮點還是整數運算 撈到浮點樹型態的欄位並且拿它來做運算、查詢就會用到CPU的FPU嗎? 小弟 對硬體的概念都來自於報章雜誌 wiki 可以說完全沒概念Orz 知道這個要幹麻呢? 1.純粹好奇 2.最終目標是想知道哪些用途用那種平台(AMD or Intel)會比較好 像是之前k8架構，我只知道因為他的3組複雜Decoder對於需要用到大量高精度浮點的科學運算有很大的幫助...如果我要matlab模擬些什麼的時候就會用k8之類的 此文章於 2009-02-07 06:14 PM 被 lobben 編輯. |
|
2009-02-07, 06:11 PM
#33
|
|
|
*停權中*
加入日期: Jan 2008
文章: 1,281
|
引用:
一、指正當然有價值，但沒人是完人，就像你也不知道 MMX 只有整數運算，我想你也不喜歡因為這樣就被人說你「沒寫過程式或不知道就不要亂講」吧？總之我認為對一位熱心分享者不該太過嚴厲。 二、這裏只是業餘討論區，又不是專業課堂，我看會對這類問題有興趣的就我們幾個人罷了，那會有多大影響  三、我與 EIGHTS 及 lobben 聊天是有啦，但我可沒「無中生有」吧？如果你一定要正經八百，好，那就通通算我錯好了，我錯在不該找大家聊天，我在此跟你陪不是，這樣行不行？ |
|
|
2009-02-07, 07:29 PM
#34
|
|
|
Major Member
加入日期: Jan 2005 您的住址: 台北市
文章: 166
|
先說好 我是路人學生
沒啥寫程式 平常除了潛水還是潛水 前幾天才發了篇很害羞馬上被指正錯誤的文章 自我介紹完畢 ========================================================= 我個人一路文章讀下來 最讓我覺得奇怪的大概就是eights在第八篇回復的那些 畢竟之前在看動畫(大學生嘛)總是會用到ffdshow 裡面無論是xaren所提的YUV轉RGB(正好有篇文章提到色彩錯誤問題 有去查了查) 又好比resize的時候用的Lanczos(似乎有程式也叫這名字?) 亦或是單純處理電視和電腦在顯示上的 TV -> PC或反向的轉換(亮度 彩度) 我實在不大覺得有人會用整數幹這種東西 p.s.當然轉檔我是沒在轉的 所以拿這和轉檔一起討論有點怪 畢竟播放和轉檔好像也不能混一起 其他怪怪的地方還滿多的 好比假設SSE 這類的SIMD指令就不能算在整數或浮點運算之中的話 讓人的感覺就是[一個人是人 兩個人阿 對不起 你們不是人]的感覺(比喻太爛別扁我) BYTE -> BYTE我也不大知道要怎樣理解他所寫的 畢竟無論整數或浮點數在電腦裡面通常也都是n個byte在儲存 好像也很少看到儲存或讀取時不是以byte為單位的(IA-32部分都直接跳過的 所以指令長度有沒定在n個byte上不知) 整體來說我是覺得xaren確實(似乎?)指正了很多怪異之處(當然我不是教授 不是專業人士) 以口氣來論 則無論 xaren 或是 eights都有怒氣值接近滿檔的趨勢 其他就不多說了.... ========================================================== 至於lobben的部份 就讓我來當一下大濕 假如有錯的話....因為我是大濕 所以有錯也很合理 麻煩鞭小力一點(但是有錯就請指正) 單以我對資料庫應用的理解來說(哈哈 其實我不會用 也沒寫過) 關鍵字搜尋應該是用矩陣來做吻合 所以想來是整數 假設資料儲存和排序上 在資料不斷進出 而且有一定筆數的話 我想應該會考慮雜湊來免除平衡樹的旋轉等操作 而雜湊函數除了避免碰撞之外最重要的就是易於計算 而易於計算這點就很明顯不會拿浮點數來煩自己了 就算是以浮點數儲存的資料 假設只是單純的比大小 或單純和0比大小(等於這種東西很難說) IEEE754標準使得可以用整數的方式來幹(WIKI中英好像描述不大一樣 我課本和英文版的一樣) 所以我想在資料庫運用上應該是以整數為主啦 大概! P.S.相等的部份假設直接用整數的方法幹 由於有+-0 非標準數存在 所以應該還是會回到浮點數形式 AMD和Intel誰硬體比較強的話 由於現在cpu越來越複雜 兩公司在指令上分歧更是越來越大 軟體的影響力不亞於硬體 加上在一兩年內就能看到sse5大戰 avx(沒打錯吧 羞) 所以等到時候再討論也不遲 不過假設兩者硬體能力相當的話想來也是Intel贏(雖然個人比較喜歡雙a) 畢竟Intel還有大家會拿來用的編譯器(像ffdshow有gcc版(不小心差點打成ggc)和icl版) AMD假如有出對自己CPU最佳化的編譯器的話麻煩通知ㄧ下孤陋寡聞的我 ========================================================== 雖然可能沒啥用....不過還是看書去 |
|
2009-02-08, 12:03 AM
#35
|
|
|
Major Member
加入日期: Feb 2003
文章: 198
|
引用:
所以MMX的部份我沒用很肯定的語氣。 "「沒寫過程式或不知道就不要亂講」" 不喜歡就不要這樣做。 我被人這樣講當然會不爽，可是別人有理的話，那我只能自己吞，自作孽。 我一直問他用什麼語言的原因不是認為他沒寫過程式什麼的， 而是想和他用共同語言溝通。 主要是 EIGHTS 太扯了。 正常人有部份搞錯或怎樣的很正常，他是讓我完全不知道該怎麼講。 最重要的是又一付很肯定的樣子。 勿以惡小而為之。 就算看到的人少，那還是有。 聊天歸聊天，像妹正不正大家可以各說各話。 但這種東西要討論就沒有糢糊的空間。 |
|
|
2009-02-08, 12:57 AM
#36
|
|
|
Golden Member
加入日期: Feb 2004 您的住址: 從來處來
文章: 2,765
|
引用:
雖然進去是整數資料，最後儲存結果也是整數資料，但運算過程卻是浮點運算。 理由很簡單，因為色彩轉換和值域轉換函數本身就是必須使用浮點運算。例如 DCT, 需要算 consine 值，怎麼可能用整數去算，那不是算出一堆誤差？ 至於利用整數去模擬小數做 DCT 運算完全沒必要，因為會更慢。 簡言之，對影像壓縮的 DCT 而言，是經過整數（原始資料） -> 浮點數（運算過程） -> 整數（結果資料）的轉換，你說對了結果，但過程卻錯了。 看一下 DCT 的公式，你就知道為什麼必須使用浮點數運算了。 http://en.wikipedia.org/wiki/Discrete_cosine_transform |
|
|
2009-02-08, 01:58 AM
#37
|
|
|
Power Member
加入日期: May 2000 您的住址: Taiwan
文章: 697
|
引用:
這段話可能不是很正確, 而且會造成別人觀念上的誤導 轉影片檔, 只要牽扯上破壞性壓縮, 基本上目前有用的演算法(H264/MPEG2/DivX... etc.) 一定會用到浮點運算, 這跟資料來源或是資料存放的格式無關 引用:
一般用途也是會用到浮點運算的, 只是比較相對的低 引用:
如果是單純去處理畫面的話, 當然可以利用近似或是一些技巧去避免浮點運算 但整個遊戲不見得會完全不使用浮點運算 早年DOS時代, 有些CPU沒有FPU, 所以基本上是能避則避, 但現在不見得需要這樣搞 引用:
浮點運算確實是比整數運算複雜, 他的電路也大了多 但按照現在CPU的架構, 大多的指令都是1個週期就完成了, 浮點數不見得會有多慢 一些計算我們確實直接用整數去計算會得到比較快速的效果, 比如說色空間轉換 雖然說係數都是有小數點的, 但取最小倍數, 配合位移指令, 直接使用整數的簡易計算 可以避免整數與浮點數資料轉換造成的額外運算需求, 確實可以得到性能上的提升 但浮點運算不會只是特殊用途, 也不會是很少用到 而整數運算跟是不是byte為基本單位似乎也不完全有正相關 就拿影像處理軟體來說好了, 一張標準的Truecolor(24bits) bitmap, 如果你要做影像柔焦效果, 裡頭應該也是直接用浮點運算會更直覺有效 |
||||
|
2009-02-08, 02:00 AM
#38
|
|
|
Power Member
加入日期: May 2000 您的住址: Taiwan
文章: 697
|
引用:
這點我必須澄清一下, RGB轉YUV, 有快速演算法可以取代浮點運算 減少資料相互轉換可以得到較好的效能 現在SuperPI使用的演算法, 是分解有理數化法(DRM法)... 他必須要自行去處理數值運算 |
|
|
2009-02-08, 02:13 AM
#39
|
|
|
Senior Member
加入日期: Oct 2006
文章: 1,384
|
引用:
http://ushiro.jp/program/pi/cdrmrmnj.htm 原始碼太長了 XD 沒仔細看 但中間運算的副程式大多宣告了一堆double參數 所以是偏浮點數運算居多?? 而這裡的倍精度實數應該是指double float而非long int吧? 那Pentium 4在x87指令運算極弱的情況下為什麼可以在super pi 不被k8幹掉呢... (純好奇) 此文章於 2009-02-08 02:33 AM 被 lobben 編輯. |
|
|
2009-02-08, 02:30 AM
#40
|
|
