華爾街的數學(4) 52進制-0+1-萬維博客-萬維讀者網（電腦版）

設萬維讀者為首頁

萬維讀者網 -- 全球華人的精神家園

廣告服務

聯繫我們

關於萬維

首　頁

新　聞

視　頻

博　客

論　壇

分類廣告

購　物




0+1
有感而發, 可多可少
		https://blog.creaders.net/u/2664/ > 複製 > 收藏本頁

網絡日誌正文

		華爾街的數學(4) 52進制	2009-08-28 17:39:41

公司購買了一批新的房貸數據, 貸款編號用6個英文字母, 大小寫可以區分. 公司為方便今後管理, 決定採用現有的數據系統. 現有的系統可以容納10個符號, 但無法區分大小寫. 對於那些管數據的同事來說, 這實在是太難了. 他們於是找到我, 問能不能幫幫忙, 一頓飯的酬勞. 我一看就覺得沒問題. 提出先吃飯, 他們同意了.一行四人在華爾街附近找了家中檔的西餐館, 菜單上許多東西恐怕用中文寫我都看不懂, 他們就爭先恐後地幫我解釋.

菜點好後, 還沒上來, 我已經就有主意了. 小寫a-z用.0-25表示, 大寫A-Z用 26-51 表示, 每逢52進一位, 所以原來的編號就成了52進制的6位數. 然後我把它轉換成10進制的10位數. 52的 6 次方是多少, 我沒帶計算器自然不知道, 但粗粗估一下和10的10次方相當接近.

飽餐一頓之後, 回公司後一坐下, 我用計算器按了一下, 不好, 52的6次方是19打頭的11位數. 飯已經吃了, 不做出來不好交代. 還好,沒多久我就想出來了. 後面9 位用數字, 前面兩位用英文字母 A-T, 正好代表0-19.

當我把這十多年前的傑作寫出來, 正在得意, 網友HPC指出實際上有更簡單的解法. 6位英文字母儘管已不能辨認大小寫, 還是照樣保留, 另外用一個6位數的二進制數(0或1)來代表6個字母的大小寫. 再把這個數轉換成10進制的數, 最大為63,加在這6個英文字母前邊, 就可唯一地表達原來的房貸編號. 這個方法從許多方面來說, 都優於我的方法:

(1) 最大程度地保留了原來的信息, 增加了可讀性.

(2) 只用了8位.

(3) 轉換和逆轉換過程中, 計算工作量都大大減少.

注:最後一段, 已根據HPC的評論重寫. 寫這個系列, 還能學到新的東西, 是完全沒有預料到的, 真可謂種瓜得豆. 謝謝HPC, 謝謝諸位閱讀.


			文章評論

作者：前提與假設

留言時間：2009-08-29 15:26:01

看ＳＢ賣弄智力，想打人啊。

你的機器雖然不能表示小寫字母，但是可以用～！＠＃＄％＾＆＊（）＿＋｛｝｜：＂＜＞？｀－＝［］＼；＇，．／代替啊。

你數數，比26個字母還多。

ＰＨＤ，永久腦袋損壞啊

我最看不起那些在白人面前有智力優越感的人。

你也不想想，真正的較高智力的白人會願意與我們這些亡國奴一起工作領一樣的薪水？


	回復 \| 0 評論前需要先登錄或者註冊哦發表

作者：西岸

留言時間：2009-08-29 11:01:01

看到五味有不少人捧場，看來不是涉及拱豬的問題，所以進來看一哈。但不太理解為什麼弄得這麼複雜，因為這是個簡單的數據結構問題，屬於COMPUTER SCIENCE本科的基本問題，而且是很簡單的問題。只能說你的那些同事不是幹這行的。

如果沒理解錯，問題是用十位字符串結構表示26個字母代表的6位字符串，能區分大小寫。而原有的數據結構不能區分大小寫。

首先ASCII碼有大小寫之分，如果應用系統不區分，只能是有前端處理（為了方便檢索的輸入）。簡單的也是最可靠的處理方法就是BYPASS這個處理功能，等於簡化軟件。這是所有系統設計首先會考慮的。

如果不能減軟件功能，只能像你這裡說的那樣用數據替代方法表示，那就是不能減但可以加轉換功能的概念。那麼用六位原有的自帶有大小寫區別的符號串，不需要任何改動，在後面加一位大小位置寫識別符即可，即總共需要7位。一位字符的識別符有8個BIT，可以表示8個位置的大小寫（因為不涉及顯示問題），用MASKS可以很方便地區分。

但這等於在數據輸入後進入數據結構前有個轉換功能，數據取出後輸出前有個逆轉換功能（你的用數字進制的方法也是同理），從系統設計角度講都不是最優更不是最簡單的方法。另外這種設計還要考慮與其他以前的數據兼容的問題，雖然並不複雜，但畢竟是多一道手續。

這是軟件本科生檔次的問題，但如果問題理解錯了，算我沒說。


	回復 \| 0 評論前需要先登錄或者註冊哦發表

作者：0+1

留言時間：2009-08-29 09:28:18

Mr. HPC: I read again and get your idea. It seems better than mine. Thanks.


	回復 \| 0 評論前需要先登錄或者註冊哦發表

作者：0+1

留言時間：2009-08-29 09:23:26

Mr. HPC: Yes, there must be many solutions, actually infinity theoretically. I just pick one easiest for me and for them. To be hornest, I am not familiar the technique you introduce. The story was about 12 years old now and I may not spend time to learn now. Thanks forread and comment.


	回復 \| 0 評論前需要先登錄或者註冊哦發表

作者：HPC

留言時間：2009-08-29 09:15:54

some corrections for my previous comments:

00010101 should be 0x15. so the mortgage numbers should be 0015ABCDEF 0015abcdef or 0035ABCDEF 0035abcdef


	回復 \| 0 評論前需要先登錄或者註冊哦發表

作者：HPC

留言時間：2009-08-29 08:54:41

If I understand correctly, in fact, your problem is that the mortgage number's upper/lower case information disappears if the mortgage number is stored in your current system as-is.

For example, original mortgage number "aBcDeF" and "ABcDeF" will appear the same as "ABCDEF" or "abcdef" (depends on the upper/lower case conversion logic in your system) if these two original mortgage numbers are stored in your current system's database.

To solve the problem, you can use two Hex numbers to carry the upper/lower case information to make the mortgage number unique in your current system.

Let's still use "aBcDeF" as an example. If you use binary bit value '1' to represent upper case, '0' to represent lower case, binary 00010101 (the highest two bits do not matter) carries to upper/lower case information for mortgage number "aBcDeF". 00010101 is Ox16. So the mortgage number can be encoded as "0016ABCDEF" (ten characters) or "0016abcdef" (depends on the upper/lower case conversion logic in your system) to be stored in your current system. Obviously the "ABcDeF" can be encoded as "0036ABCDEF" or "0036abcdef".

This solution is far more simpler. It provides an intuitive mapping between the new mortgage number to the original number which is very important for reconsoliation.

Probably Phds always make things over-complicated.