#3602

Easy

LeetCode Problem Workspace

Hexadecimal and Hexatrigesimal Conversion

Solve Hexadecimal and Hexatrigesimal Conversion by converting n squared to base 16 and n cubed to base 36, then joining both strings.

math string

Problem Statement

You are given a positive integer n. Build a string from two separate number conversions: first take n squared and write it in base 16 using digits 0-9 and uppercase A-F, then take n cubed and write it in base 36 using digits 0-9 and uppercase A-Z.

The final answer is the direct concatenation of those two converted strings, with no separator. Since n is small, the main interview focus is implementing base conversion correctly, especially remainder handling, digit mapping, uppercase letters, and keeping the order as hexadecimal of n squared followed by hexatrigesimal of n cubed.

Examples

Example 1

Input: n = 13

Output: "A91P1"

Example 2

Input: n = 36

Output: "5101000"

Constraints

1 <= n <= 1000

Solution Approach

Compute the two target values first

Start by calculating a = n * n and b = n * n * n. Keeping the square and cube separate avoids a common mistake where candidates convert the wrong power or append results in the wrong order. For n = 13, this means converting 169 to hexadecimal and 2197 to base 36 before joining them.

Use one reusable base conversion helper

Write toBase(x, base) with a digit table like 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ. Repeatedly take x % base to get the next digit, append the mapped character, divide x by base, and reverse at the end. This exact helper works for both base 16 and base 36, so the problem stays a Math plus String implementation instead of two separate code paths.

Concatenate the converted strings

Return toBase(a, 16) + toBase(b, 36). The real trade-off here is simplicity versus over-specializing: a single helper is shorter, easier to test, and reduces digit-mapping bugs. Because n is at most 1000, performance is trivial, so correctness of conversion rules matters much more than optimization.

Complexity Analysis

Metric	Value
Time	Depends on the final approach
Space	Depends on the final approach

Let k16 be the number of digits in n squared when written in base 16, and k36 be the number of digits in n cubed when written in base 36. The conversion loop runs once per output digit, so the total time is O(k16 + k36) and the extra space is O(k16 + k36) for the built strings. Under the given constraint, both values are very small in practice.

What Interviewers Usually Probe

You notice the problem is really two base conversions glued together, not a tricky math identity.
You suggest a generic toBase(x, b) helper with a 0-9 and A-Z digit table instead of hardcoding hexadecimal and base 36 separately.
You explicitly guard against the order bug: convert n squared to hexadecimal first, then n cubed to hexatrigesimal.

Common Pitfalls or Variants

Common pitfalls

Using lowercase letters or the wrong digit table, which breaks the required uppercase output for both bases.
Forgetting to reverse the collected digits after repeated modulus and division, producing the representation backward.
Mixing up the powers or output order, such as converting n cubed to base 16 or concatenating the base 36 part first.

Follow-up variants

Return the two converted strings as separate fields instead of one concatenated result, which removes the final join but keeps the same helper.
Change the bases to another pair such as binary and base 7, which tests whether the conversion logic is truly generic.
Allow n = 0, which adds the classic edge case where toBase must return 0 instead of an empty string.

FAQ

What is the main pattern in Hexadecimal and Hexatrigesimal Conversion?

The core pattern is Math plus String: compute n squared and n cubed, then convert each value with repeated division and remainder, using the correct digit table for base 16 and base 36.

Why is a generic toBase function better here?

This problem asks for two numeral systems, but the conversion steps are identical except for the base and allowed symbols. One helper reduces branching and makes it less likely you will map digits inconsistently between hexadecimal and hexatrigesimal.

How do I handle digits above 9 in base 36?

Map values 10 through 35 to uppercase letters A through Z. A digit table string such as 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ lets you index directly by remainder.

What explains the output A91P1 when n = 13?

First, 13 squared is 169, and 169 in hexadecimal is A9. Then 13 cubed is 2197, and 2197 in base 36 is 1P1. Concatenating them gives A91P1.

Do I need to optimize beyond basic conversion loops for LeetCode 3602?

No. The constraint is small, so the important part is correct conversion and concatenation. Most wrong answers come from digit order, uppercase handling, or converting the wrong power, not from time complexity.

terminal

Solution

Solution 1: Simulation

We define a function $\textit{f}(x, k)$, which converts an integer $x$ to its string representation in base $k$. This function constructs the result string by repeatedly taking the modulus and dividing.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

class Solution:
    def concatHex36(self, n: int) -> str:
        def f(x: int, k: int) -> str:
            res = []
            while x:
                v = x % k
                if v <= 9:
                    res.append(str(v))
                else:
                    res.append(chr(ord("A") + v - 10))
                x //= k
            return "".join(res[::-1])

        x, y = n**2, n**3
        return f(x, 16) + f(y, 36)

Continue Practicing

#3556 sum of largest prime substrings #3519 count numbers with non decreasing digits #3518 smallest palindromic rearrangement ii