@john.uhden wrote:
The objective is to create a function that returns a string from an integer based on 1=A, 26=Z, 27=AA, 52=AZ, 53=AAA, etc.
....
You're going to end up with huge strings of A's, and only the last character running through the rest of the letters. Shouldn't 53 be BA, through 78 = BZ, 79 = CA through 104 = CZ, etc.? That would be [close to] "straight" base-26 counting, though without using the numerical characters as they do in hexadecimal. But actually it would be base-26 + 1, because the single characters A through Z would represent 0 through 25 (one less than the base), just as in base 10 the single characters are 0 through 9. Then the next number after that (the base value itself) is the first with two characters, and in the first two-character number the second character is 0.]
Under that scenario, I have a base-10-to-hexadecimal converter [developed for dealing with entity handles] that I tried to adjust, and I got it to compensate for the lowest "digit" in the series ["A"] representing 1, rather than 0 as it does in base-10 [or base-2, or base-anything under usual mathematical practice]. I forced it to actually work with the given number minus 1. But it gets complicated when you get into multiple characters, and the compensation has to be "tweaked" for the second character in a different way. It works as far as 675 [which is 26 squared minus 1] -- that's "YZ". But it's a "forced" compensation that would need to compensate in a "differenter" way as you get up into higher numbers. For 676 [which is 26 squared, and as the next number after "YZ" one would want to be "ZA"] it fails -- it gives "A@A". It goes into 3 digits there [the middle one is the character just before "A" in the (ascii) code numbers], because the square of the base number [again, under any standard base-whatever system] always kicks into 3 digits -- the square itself in numerical-character systems is always represented by 100 within its own system.
I think if you want something that will work up into thousands, you may have to settle for A representing 0, not 1. 1 would be B, 25 would be Z, 26 would be BA [equivalent to 10 in any other base -- the base number itself is always represented by 10 in numerical-character systems]. If you can use it that way, I think I can provide a converter pretty easily, with a different [and simpler] adjustment of the hexadecimal version, and it would work consistently up into the gazillions, without any forced compensations.
And besides, if A is 1, and all the characters are letters from 1 to 26, what do you do if the number you want to convert into such a string is zero? You have no character for that. You could have Z be 0, so A through Z represent 1 through 0 in the same way as the purely numerical sequence 1234567890, but that's really out of sequence. 26 would be AZ, but at least that's consistent with the base number always being the first with two characters, equivalent to its being represented by 10 in any numerical-character system. 26 squared would be AZZ, etc.
Another possibility that would be easy to work out would be to use 0 with its typical meaning, and A through only Y for 1 through 25. 26 would be A0, 26 squared would be A00, etc. Or if you want to include Z, make it a base-27 system, where 26 would still be Z, 27 would be A0, 28 would be AA, etc.
The converter I was monkeying with is at home, and I'll look into it further this evening or this weekend.
One major complication is that in any numerical base-whatever system, at the point of shifting from one character to two characters, the two characters are not the same as each other ["10"], but in what you're talking about, they are the same ["AA"]. And similarly at every shift to the next-higher number of characters. I was able to force correction for that with two-digit numbers, but the correction has to be different once it shifts to three characters -- I think the correction itself has to "shift over" and leave the previously-corrected place un-corrected, or something like that.
I think I have a notion how that might be done in a way that will translate through any number of characters, but it will have to wait until I can get into that file again -- I have the source hexadecimal one where I am now, but I don't want to redo all the monkeying I already did, try to recall the things I tried that didn't work, etc. If you want to try messing with it, you can get it here.
That (Number2Alpha) function seems to do just what the doctor ordered -- amazing what recursive operations can do. It's a lot shorter than what I was working on, though mine was coming from something originally for a more generic conversion, that could also take 0 and negative integers [which (Number2Alpha) won't convert correctly], but I assume those are not part of the picture here.
Thanks John. Boats are too expensive though, unless you live to work on them. My father loved working on his boat.
AARP is after me too.
