in reply to Re: SSN's possible new Y2K problem?
in thread SSN's possible new Y2K problem?

I seriously doubt they would go to hex. Base 36 perhaps, but certainly not base 16. The work required to go from decimal to base 16 is the same as to base 36, but the latter provides far more unique values.

BTW, base 36 = [A-Z0-9]

Its nice to think that perhaps they might even go to base 62 or base 64, but the likelyhood of error mistaking a lowercase letter for an uppercase one (or vice-versa) makes me think that that is even less likely than hex.

Yves / DeMerphq
---
Software Engineering is Programming when you can't. -- E. W. Dijkstra (RIP)

Replies are listed 'Best First'.
Re: Re: Re: SSN's possible new Y2K problem?
by seattlejohn (Deacon) on Aug 16, 2002 at 23:08 UTC
    Now I'm getting waaay OT, but I have to admit I've sometimes wondered if using base 36 for identifiers is such a great idea, because it's so easy to visually confuse 1 (one) with I (India) and 0 (zero) with O (Oscar). And if your letters could occur in either uc or lc form, the lower-case l (lima) is a problem too. That leaves us with 33 characters, just one above the nice round 2**5, so I've occasionally been tempted to argue for base-32 identifiers consisting of [0-9A-HJKMNP-Y]. Of course, the encode/decode logic would probably be a lot less efficient than base-36 ;-)
[reply]
[d/l]

In Section Meditations