果然翁 ![]() | 我覺得有可能是 壓縮時資料碼變的較小 解壓縮時資料碼變大 但是執行時有另一種『狀態』使資料碼變的更大 但是這個大小並不會影響速度,反而會增加執行速度 有可能是因為這樣的關係讓CPU更好了解 相對的就要浪費掉可能好幾倍的容量 你想表達的是這個嗎? |
回覆 |
--帳號停用中-- | 回覆: 【?】有這種程式嗎 翻了一下5年前自己的發言 這裡http://www.pczone.com.tw/vbb3/post/502241/24/ 已經有網友部 分理解到我的意思了 我現在比較清楚自己的概念 重新再說明一下 X86CPU不是有很多單元組成嗎?也有很多特殊的加速用指令集 假設每個指令集都特化出來變成前端的解碼單元 這樣一道程式碼就可以在每個前端的解碼單元上因為長度不同 而被視為不同的程式碼 之後進入運算的時候 一樣使用特化的處理流程 最後將總合的結果 由一個特殊單元整合 再將結果呈現出來 例如 觸摸在燃燒的火這樣一個景象 對於眼睛來說是看到紅光的訊息 對於手上的神經得到的是燙的訊息 總和運算後 得到的是 看到與感受到的畫面 又假如一個圖形程式碼 物理運算單元處理物理特性的部分 多邊型運算單元處理多邊型的部分 著色單元處理著色部分 .....etc 然後整合輸出變成一個具有真實感的物件 以上 謝謝 |
回覆 |
混吃等死 ![]() | 回覆: 【?】有這種程式嗎 抱歉,我不是學生物的 不過我想我應該了解你的意思了 不過不知道您的用途是什麼呢? 這並不是所謂的解壓縮還是壓縮的概念 我覺得只是自訂型別概念跟使用者介面+邏輯的概念而已 另外,電腦算數字不是想像的那樣 就是用這種12345(ANSI: 31 32 33 35)這樣算給你看 舉例: 我是這樣實做身分證字號儲存 例如A100000001佔10byte 身分證字號前面第一碼英文只有26個,第二碼不是1就是2 換句話說只需要26x2=52的範圍即可 所以我們只須取一個十位數來儲存 第3碼~第9碼的數字就照抄,第10碼是檢查號,我覺得有沒有記下來都沒差 轉為數字的話假定是11,000,0000 (16進位表示: 41 90 AB 00) 使用int型別就好,這樣只需要佔4byte 這樣就可以降低資料庫的負擔,扔前端處理 不指省空間,查詢又快速,尤其資料量很大 4byte去資料庫撈資料絕對比10byte來的快速 (ps:就SQL來講,身分證字號一般都會作為唯一鍵甚至主鍵 主鍵(PK)佔位元組數越少,以及使用固定位元組數的型別,越能夠降低撈資料時對資料庫的負擔,與提高效能) 而且對電腦而言,處理數字會比字串來的快很多 就好像一般在紀錄日期,都是紀錄下該時間距離某個時間點的秒數 而不是紀錄下一大串有的沒的 (人類或許要算個老半天才會知道是哪個時間點,但電腦並不是) 一定要英文字來做DNA的代號嗎? 何不用數字來取代會比較方便? 例如: ATTTTGGGCCCTTTGGAAATTTCCGGG 122223334445554411122244333 超過long型別長度了,那就用雙long型別吧,雙long總計只佔16byte 簡單來講就是分兩串數字 1222233344455,54411122244333(16進位表示:00 00 01 1C 92 C8 C9 C7,00 00 31 7C 93 9C FA ED) 一開始就不要有一定要「人類容易理解的文字」的想法來寫程式 老實說這樣做該程式員會死的很慘 反正這些是給電腦看的 計算出結果以後 前方顯示用的UI在另行轉換給人看就好了 另外不過不知道你是不是有這樣的想法 1222233344455,54411122244333 上面有兩串數字,第一串會一直變動 但第二串"幾乎"是固定的幾組? 如果是的話,後面直接做個範本,搭配null(空值)使用即可 例如: num1 = 1222233344455 num2 = null num2TemplateID = 2 num2TemplateID使用byte型別 簡而言之只需要浩8byte+1byte的空間 或是 num1 = 1222233344455 num2 = 54411122244333 num2TemplateID = null 另PS: byte=位元組 共佔1byte 範圍:0~255 short=短整數 共佔2byte 範圍:0 ~ 65535 int=整數 共佔4byte 範圍:0 ~ 4294967295 long=長整數 共佔8byte 範圍: 0 ~ 18446744073709551615 不同程式語言可能名字不太一樣,但是都大同小異 請參考XD 此篇文章於 2008-04-18 08:59 AM 被 sfilc 編輯。. |
回覆 |
戦零絶唱中 ![]() | 回覆: 【?】有這種程式嗎 如果小弟沒弄錯的話,purk兄的概念應該是在說"廣展似運算法"。 從一個關鍵,再發展出另一個結果出來,最後統結所有的結果。 就以例子來說,小弟當初是想查PS2的主機規格,之後不知道為什麼變成了調查Xbox360、Wii、DreamCast、Nintendo64、NDS、PSP... 的規格起來,最後再統一所有的規格來做比較。 這個過程大概就是這樣。由一個小小的開始-> 然後演變成了大量的搜索量(運算)-> 最後統一全部規格成為精簡的比較表。 說到這類的程式,自己覺得 Google 類的搜索方式很相似這樣的概念。 以一般比較單純的搜索器,例如我輸入 "pczone bsd lenbo",系統就會認為這些都是整句關鍵詞,除非有標題是這樣寫,不然會出現找不到結果。 如果用Google搜索的話,它就會很聰明的將關鍵詞分成三份 "pczone"、"bsd"、"lenbo"。 而同時又會出現不同的結果如 "pczone" 又有 "pczone" 的結果,"bsd" 下也有關 "bsd" 的結果,"lenbo" 又有關 "lenbo" 的回文之類的結果。 這只是舉例,不要問小弟為什麼要用 lenbo。 XD 先不談運算,使用這樣概念的好處是電腦可以更"智能化",它可以有像人類想法那樣從一種東西自我做出了很多想像、判斷出很多有關的可能性。 如果套用在程式上的話,主程式碼可以非常小或精簡,它本身只需要具備些基本的"關鍵",然後電腦就會根據那些關鍵"自我想像",並將我們要的結果展現出來。 這在程式開發上,跟調用 API 的想法類似。不過調用 API 的概念是 "沒有的東西就是沒有",系統沒有提供,除非自己開發,不然它不會自動生出來。 說到壞處的話,以現今技術來說,根據用途,運算需求量大小也不同,且主系統也需要有大量的"基本樣本"提供來做判斷。 用在關鍵字上,就像 Google 那樣做出並行運算處理器,然後具備了大量的關鍵詞做索引,基本上就可以做到這樣的"智能化"。 聽說 Windows 7(暫稱) 也會加入類似的功能。不過如果用在繪圖上、影音上,恐怕還有一段路要走。 成功的話,到時影片不再是以 frame by frame 壓縮了。而是可以 real time rendering 且也可以很順暢的播放出來。 以上只是小弟提出自己的個人看法,雖然說了很多廢話。 此篇文章於 2008-04-18 12:10 PM 被 warzero 編輯。. |
回覆 |
會員 ![]() | 回覆: 【?】有這種程式嗎 人說的應該是人工智慧中的基因演算法吧 上學期教AI時有教到 |
回覆 |
會員 ![]() | 回覆: 【?】有這種程式嗎 不是不可能,但是purk兄的想法還不成熟。 首先要把一段碼依據不同的方法讀取來做不同功能性的利用,就會讓編譯器和程式設計者白花很多腦筋。壓縮程式之所以慢不是沒原因的。與其浪費心力時間去製造出那樣的碼,目前的軟硬體本身早就有類似的功能,prefetch、SIMD 等等,不是沒人用,只不過是個人電腦的程式太雜了,可能程式已經在用但你不知道而已,或是程式設計者根本還在用老方法寫程式,所以使用者老覺得性能不彰。 另外,很多時候程式慢是另有原因,不得不等。 最後,其實這樣的程式現在也不是沒有,但是也不是每個程式都適合這樣寫,資料型態影響很大。 |
回覆 |
什麼都不會O____Q ![]() | 回覆: 【?】有這種程式嗎 差不太多的程式碼吧...現在硬碟的價格越來越便宜,1G也在8,9塊錢了(硬碟),比起請一堆設計師來寫,可能讓使用者少個1,2GB可用會比較實在 |
回覆 |
散人 ![]() | 回覆: 【?】有這種程式嗎 電腦最大的問題在於他只認識0跟1,而人類試圖將不是0跟1的思考運作, 想辦法讓他接近0跟1。我想只能做為參考,而不能當成結論,最後依舊需 要人腦做最後判斷吧。至於各種演算法則,不過是加速這些資訊運算的手 段,讓結果能夠更逼近或是更像人類的思考,但是應該還是無法取代人吧。 依據許多的研究顯示,人類的記憶容量似乎是沒有上限的,但是硬體的裝 置,皆有此限制。因為這種限制,就會侷限很多的想法,大概要靠時間與 新的理論慢慢克服吧。不是做不到,可能是相關週邊的輔助條件尚未到位。 |
回覆 |
高級會員 | 回覆: 【?】有這種程式嗎 我相信這種分析DNA 的程式是有的 但都是基因工程的實驗室內部在用,不會提供給他人使用。 如果想要這種專業程式就要請人設計 ! 不過可以搜尋看看~ 也許有人分享出來 此篇文章於 2008-04-21 11:54 PM 被 jazzblue 編輯。. |
回覆 |
Watch Dog | 回覆: 【?】有這種程式嗎 山賊來試著解讀 purk 君的想法: purk 君的想法可能是這樣: 同一筆記錄資料, 當從不同位置讀取時, 代表意義與所需執行動作就不同, 因此可以單拿一筆資料, 同時分別給不同定址偏移量的程序器解讀執行, 完成所需動作, 舉例如下: 譬如某編碼代表字分別為 A 與 B, 若某一筆資料, 其內容是 AB , 則從左邊第一個位置為起始點讀取, 其對映狀態編碼就是 AB, 我們稱為動作 1, 若是從左邊第二個位置為起始點來讀取, 其對映狀態編碼就是 BA, 我們稱為動作二, 其它依此類推; 因此可以分別由不同起始位址偏移量的程序器來執行操作不同的動作.. 譬如當某一程式檔案的內容是: 資料內容 ABAAABBA 儲放位址 01234567 對程序器 0 來說, 位址偏移量為 0, 程式碼內容及執行動作順序為 AB AA AB BA 對程序器 1 來說, 因為位址偏移量為 1, 假如程序器 1 的結構與程序器 0 相同, 那麼對它來說, 資料內容, 程式碼內容及執行動作順序變為 資料內容 BAAABBAA 儲放位址 01234567 BA AA BB AA 以上是以兩個字為程式碼的運算執行單元, 也就是說只有四種狀態動作 AA, AB, BA, BB, 而檔案長度限制在 8 個字 .. 若用四個字為運算執行單元, 也就是說有 16 種狀態動作, 那對程序器 0 與 1 來說, 就變成: 程序器 0 執行的程式碼 ABAA ABBA 程序器 1 執行的程式碼 BAAA BBAA 倘若 purk 君的想法是這樣, 理論上是可以用一個檔案, 來代表不同意涵; 之前炒作過一陣子的 "聖經密碼", 就是用這種手法, 運用不同的起始位置, 不同的區間(可使用固定區間或是以某方程式來代表, 譬如 y=y+3y), 將最終挑選出來的字組集合循序來組合, 若能組成有意義的文句, 便將之視為某個預言, 若無意義則捨棄, 因此改變不同的起始位置與區間, 可以獲得不同的預言; 理論上可以運用主觀的操作手法, 獲得主事者想要的預言; 這種方法, 也可以反向運用, 成為加密的手段.. |
回覆 |
XML | RSS 2.0 | RSS |
本論壇所有文章僅代表留言者個人意見,並不代表本站之立場,討論區以「即時留言」方式運作,故無法完全監察所有即時留言,若您發現文章可能有異議,請 email :[email protected] 處理。