0

I was just implementing an arbitrary base converter, and I had a moment of curiosity: is there a generalizable base conversion approach that works with any possible range of base inputs (excluding base 0), AND does not use an intermediate value in a more convenient base?

When writing a base conversion function, particularly one that goes from an arbitrary base to another arbitrary base, it can easily be implemented by first converting the number to decimal, and then re-converting it to the target number. You can also pretty easily bypass the intermediate value step arithmetically, provided you're in the range of base [1,10].

However, it seems to become trickier when you expand the range. Consider the following examples (primes seem like they might narrow the possible approaches a bit?):

  • base 7 to base 33
  • base -3 to base 13
  • base -16 to base 16

I didn't see much conversation about this question here, or elsewhere on Google; most either had a narrower range of bases or used an intermediate value. Any ideas?

hwbehrens
  • 25
  • 5
  • 2
    Start by showing what the number 42 (decimal) is supposed to look like in base 0 and base -3, in your opinion. That doesn't make much sense. – Igor Tandetnik Mar 14 '15 at 22:58
  • 1
    Converted to decimal? Probably to binary in a computer, right? Anyway, sure, you can convert from whatever arbitrary base to whatever arbitrary base you want. It's just that computers work in binary so that makes your life easier. – Carl Norum Mar 14 '15 at 22:58
  • It's possible, you need to define both the numbers in arbitrary base and the respective basic operations (product, division, modulus) needed to perform the base conversion. – Sigi Mar 14 '15 at 23:11
  • What the heck is base -3?! – Lightness Races in Orbit Mar 14 '15 at 23:12
  • 1
    http://en.wikipedia.org/wiki/Negative_base – Sigi Mar 14 '15 at 23:13
  • Thanks @Sigismondo, I thought that might be the case. Too bad there's not an easier way! Thankfully, I doubt it's something that you'd run into in the wild very often, if ever. – hwbehrens Mar 14 '15 at 23:20
  • Seeming unbelievable to me myself actually I wrote it time ago, I will post it eventually. However in the same scope I also used https://gmplib.org/ - in case you find it handy. – Sigi Mar 19 '15 at 11:26

2 Answers2

1

The generalized algorithm to perform a base conversion of a value V with n digits in base B to an equivalent value V' in base B' is as follows:

Let d(0),d(1),...d(n-1) be the digits of V in base B. Using a translation table, we convert these digits to a sequence of digits d'(0),d'(1),...,d'(n) where each d'(i) is the original d(i) digit, but expressed in the new base B'

Then, V' is defined by:

V' = d'(0)*B^0 + d'(1)*B^1 + d'(2)*B^2+.....+d'(n-1)*B^(n-1)

Now here's the catch (and the reason you need an intermediate value): not only all values of the above formula have to be expressed in base B', but all the operations (addition and multiplication) have to be performed using aritmetic in base B'

For example: how to convert the number V = 201 expressed in base 3 to base 2 without converting it first to base 10.

The digits of V expressed in base 3 are d(0)=1, d(1)=0, d(2)=2 Converted to base 2, d'(0)=1, d'(1)=0, d'(2)=10 The original base is 3, but the general conversion formula need it to be expressed in the target base (2), so we'll use the value B=11 Then:

V' = d'(0)*B^0 + d'(1)*B^1 + d'(2)*B^2+.....+d'(n-1)*B^(n-1)

Putting values and operating in base 2

V' = 1 + 0 + 10*(11^2) = 1 + 10*11*11 = 1 + 10010 = 10011

So, 201(3 = 10011(2

Proof: 

201(3 = 2*3^2 + 0 + 1 = 19
10011 = 1 + 2 + 16 = 19
mcleod_ideafix
  • 11,128
  • 2
  • 24
  • 32
  • Thanks for the detailed explanation. Creating arithmetic operators that work with numbers with arbitrary bases seems like it would be both (A) more work, and (B) potentially slower than just using the intermediate value, so I think I'll just stick with that method for now. – hwbehrens Mar 15 '15 at 00:25
-1

A brief word about why base-10 is the intermmediate base. Because it's familiar.

School has taught us base-10 whether we knew it or not, from kindergarden to where you now. Our our language centers around base-10, whether articulated, writtened, or compiled. The computer languages by design use base-10 for their high-level human user interface, and common parameters to run-time functions regardless of the internal representation.

Because base-10 is in our everyday lives, we don't need to think as much on the sequence of base-10 artifacts ( 0 through 9 ), leaving our minds to plan other logic for the task at hand. When I designed this alogrythm in 1982, I chose 0-9A-Z artifact list method for simplicity as a type of exponent map, making it easier to leverage the language math operations and string interface, that all center around base-10. (Hmmm that base-10 thing again.)

So if you desire to really want to make your head hurt, by re-engineering a whole new user interface by over complicating the whole process, go for it. You'll still find yourself using base-10 paramters. (Hmmm)

The first effort involved logarithm (The interface to the math function is base-10. (hmmm)). Largest_exponet_of_new_base = log(your base10 number) / log(the of base you are converting to)

Dave Cronin
  • 1
  • 2
  • The interface to the math functions are in binary. You can specify those as literals in base 8, 10, or 16 (or, using user-defined literals), any base you choose. – Martin Bonner supports Monica Nov 12 '16 at 17:19
  • @MartinBonner At the machine-level you are correct. The internal representation is binary. What you are describing, and why I referenced base-10, is is a high-level function call prior to compilation or tokenized runtime interpreter. Regardless of the pre-compiled computer language, the fundamental math interface is base-10 when coding, prior to the conversion to machine code. Other base pragmas such as base-16 (0x...) are compilation/Interpreter directives. I’ve seen this in over 15-languages that I’ve used in the last 30+ years, including various dialects of assembly. – Dave Cronin Jan 26 '19 at 07:09