华尔街的数学(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, 谢谢诸位阅读.

浏览(2933)

(0)

发表评论


			文章评论

作者：前提与假设

留言时间：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.