Conversion Algorithms in TheAlgorithms/Python

The iterative and recursive approaches to binary conversion both extract remainders of division by 2, but the recursive version makes the structure of the algorithm explicit as a function definition. The base case returns '0' or '1' when the input is 0 or 1, because single-bit numbers are already in binary. The recursive case uses divmod(decimal, 2) to obtain both the quotient and the remainder in one call, then concatenates the recursive result for the quotient with the string form of the remainder. The concatenation order is critical: the quotient's bits are more significant, so they appear on the left. This mirrors the iterative version's left-prepend pattern but expresses it through the call stack. The doctest shows 1000 in decimal producing '1111101000', and the function also accepts string inputs by wrapping with int(), which the string doctest verifies.

Hexadecimal conversion introduces a complication that binary does not have: digits above 9 require letter characters. One approach is conditional arithmetic, checking whether the remainder is above 9 and adding an offset to produce the ASCII code for a letter. This file uses a cleaner alternative: a module-level dictionary that maps each integer from 0 to 15 directly to its one-character string. The conversion function (lines 24-74) then only needs to call divmod(decimal, 16) repeatedly and look up values[remainder], building the hex string from the remainders right to left. The doctest confirms 255 produces '0xff', 4096 produces '0x1000', and -256 produces '-0x100'. The final assertion in the doctest, decimal_to_hexadecimal(-256) == hex(-256), verifies the output matches Python's built-in hex function.

Converting a binary string to decimal requires computing the positional value of each digit. The naive approach computes 2 to the power of each position and multiplies by the digit, which requires knowing the string length upfront. Horner's method avoids the power computation by accumulating left to right: start with 0, multiply by 2, add the current digit, repeat. The final result equals the positional sum because multiplying by 2 at each step effectively shifts all previously accumulated bits one position left, exactly what positional notation requires. The loop decimal_number = 2 * decimal_number + int(char) is the entire algorithm. The function strips whitespace before parsing, handles a leading minus sign, and validates that all characters are binary digits before the loop, raising informative errors for empty strings and non-binary input. The doctest confirms "101" produces 5 and "-11101" produces -29.

Roman numeral encoding looks complex because of subtractive combinations like IV for 4 and CM for 900, but encoding all thirteen of them explicitly in the ROMAN lookup table collapses the special-case logic entirely. The table is sorted in descending order. int_to_roman iterates the table and applies divmod(number, arabic): the quotient tells how many times the symbol repeats, and the remainder becomes the new number. Because the table starts at 1000 and descends, each divmod greedily extracts as much of the largest remaining denomination as possible. The doctest verifies 3999, the largest valid Roman numeral. The reverse direction, roman_to_int, uses a look-ahead: when the current symbol's value is less than the next symbol's value, the pair is a subtractive combination and the code adds the difference and advances by two positions.

Temperature conversion is the canonical example of an affine transformation: it is not enough to multiply by a constant because the two scales have different zero points. Celsius and Fahrenheit both measure the same physical temperature, but 0 degrees Celsius corresponds to 32 degrees Fahrenheit, not 0. The formula celsius * 9 / 5 + 32 applies both a scale factor (9/5, accounting for the different degree sizes) and an offset (32, accounting for the different zero points). The doctest documents the known equivalence at -40 degrees, the one temperature where Celsius and Fahrenheit are equal: celsius_to_fahrenheit(-40.0) returns -40.0. The ndigits parameter controls rounding and defaults to 2, so 273.354 returns 524.04 by default. The file contains analogous functions for all common scale pairs including Celsius-Kelvin and Celsius-Rankine.

Supporting conversions between eight length units would require 56 separate conversion factors if every pair were stored explicitly. The pivot-factor design avoids this by normalizing through a single base unit. Each entry in METRIC_CONVERSION is a FromTo named tuple with two fields: from_factor converts the source unit to meters, and to_factor converts meters to the target unit. Any conversion then costs two multiplications: multiply the input by METRIC_CONVERSION[from].from_factor to reach meters, then multiply by METRIC_CONVERSION[to].to_factor to reach the destination. Adding a new unit requires only one new table entry rather than updating all existing entries. The TYPE_CONVERSION dict above it normalizes name variants (singular, plural, abbreviation) to canonical abbreviations, so "miles", "mile", and "mi" all resolve to "mi" before the lookup.