re: Roman Numeral Converter VIEW POST


The last code test I took for an interview involved writing a calculator in Java:

    public Abacus() {
        numerals = new LinkedHashMap<String, Integer>();

        numerals.put("M", 1000);
        numerals.put("D", 500);
        numerals.put("C", 100);
        numerals.put("L", 50);
        numerals.put("X", 10);
        numerals.put("V", 5);
        numerals.put("I", 1);
     * Find the appropriate divisor for a value, which, in the equation
     * (val - val / divisor) will resolve to the threshold at or above which
     * a subtractive maneuver is necessary to convert to Roman numerals.
    private int getDivisor(int value) {
        while (value > 10) {
            value = value / 10;

        return value;

    public String convert(int arabic) {
        StringBuilder sb = new StringBuilder();

        // preserve a pointer to the last subtractable numeral
        Map.Entry<String, Integer> lastEntry = null;    

        for (Map.Entry<String, Integer> e : numerals.entrySet()) {
            if (lastEntry != null) {
                if (arabic >= 4 * e.getValue()) {
                    // we have a valid subtraction!

                    arabic -= (lastEntry.getValue() - e.getValue());
                } else {
                    // e isn't small enough for us to have a valid subtraction
                    // yet, keep going

            // basic additive calculation: as long as the number is bigger than
            // e, keep appending e
            while (arabic >= e.getValue()) {

                arabic -= e.getValue();

            if (arabic >= e.getValue() - (e.getValue() / getDivisor(e.getValue()))) {
                // the remaining number is close enough to e that we will need
                // to perform a subtractive maneuver with reversed numerals
                lastEntry = e;

        return sb.toString();


  • the mapping only includes each Roman digit once
  • the algorithm is aesthetically pleasing (even if Java isn't the kindest to it)


  • the algorithm is extremely complicated and the simpler mapping is absolutely not worth it
  • although it satisfied the battery of unit tests I was given, one of the interviewers had run an extra on it that demonstrated a bug. We all had fun picking it apart, but I don't recall what the exact problem is.

Whew man, I don’t know Java at all, so this looks really complicated to me.


The way it works is by subtracting until you can add based only on the one-to-one mapping in descending order. So if you're trying to convert 1990, it goes like this:

  1. 1990, evaluate M (1000); 1990 > 1000 so we have an M, leaving 990 for the next iteration
  2. 990 is less than 1000 so MM is wrong, but it's more than 900 (1000 - (1000 / 10)), so we set the lastEntry pointer to M and proceed
  3. Now we're evaluating C (100), but lastEntry is set. 990 > 900 which is CM, giving us MCM so far and leaving 90. I think this is where the bug is but it works in this case :)
  4. 90 > (100 - (100 / 10)) so lastEntry is now C
  5. Evaluate L (50); lastEntry is set, but the calculation to test whether L can be subtracted fails, so we proceed
  6. Evaluate X (10): the subtraction test succeeds, so 90 becomes XC and the full result is MCMXC.

Nice that’s such a cool way of thinking about it!

code of conduct - report abuse