Check Emirp Number in Java
Problem
An emirp is a prime number whose digits, reversed, form a different prime number — 'emirp' is 'prime' spelled backward, and palindromic primes like 11 don't count since their reverse is the same number.
Given a number, determine whether it is an emirp.
Java Program
public class EmirpCheck {
static boolean isPrime(int n) {
if (n < 2) return false;
for (int i = 2; (long) i * i <= n; i++) {
if (n % i == 0) return false;
}
return true;
}
static int reverseNumber(int n) {
int reversed = 0;
while (n > 0) {
reversed = reversed * 10 + n % 10; // shift left and append the last digit
n /= 10;
}
return reversed;
}
public static void main(String[] args) {
int n = 13;
int reversed = reverseNumber(n);
boolean isEmirp = isPrime(n) && isPrime(reversed) && reversed != n; // must differ from the original
System.out.println("Emirp number: " + isEmirp);
}
}Output
Core Logic
Checking three things at once — the number is prime, its reversal is prime, and the reversal isn't just the same number — confirms the emirp property in a single boolean expression.
- 1
reverseNumber(n)builds the digit-reversed value by repeatedly pulling off the last digit withn % 10and appending it onto a growingreversedtotal. - 2
isPrime(n)checks the original number using the standard square-root-bound trial division. - 3
isPrime(reversed)runs the same check on the reversed number. - 4
reversed != nrules out palindromic primes, whose reversal is identical to the original.
13, reversing gives 31; both 13 and 31 are prime, and 31 != 13, so the number qualifies as an emirp.Key Point: The reversed != n check is what separates an emirp from a palindromic prime — without it, a prime like 11 (whose reverse is itself) would be incorrectly reported as an emirp too.
Why: Two primality checks each cost O(√n), and reversing the digits only needs a handful of arithmetic steps, so no extra memory beyond a few variables is used.
Key Concepts
Approach 2: Using StringBuilder.reverse()
public class EmirpCheckStringBuilder {
static boolean isPrime(int n) {
if (n < 2) return false;
for (int i = 2; (long) i * i <= n; i++) {
if (n % i == 0) return false;
}
return true;
}
public static void main(String[] args) {
int n = 13;
// Reverses the digits via a String instead of arithmetic
int reversed = Integer.parseInt(new StringBuilder(String.valueOf(n)).reverse().toString());
boolean isEmirp = isPrime(n) && isPrime(reversed) && reversed != n;
System.out.println("Emirp number: " + isEmirp);
}
}
Output
Core Logic
Converting the number to a String and reversing it with the built-in StringBuilder.reverse() skips the manual digit-by-digit arithmetic entirely.
- 1
String.valueOf(n)converts the number into its digit string. - 2
new StringBuilder(...).reverse()flips the digit string's order in place. - 3
Integer.parseInt(...)converts the reversed string back into anintfor the primality check. - 4The same three-part check —
isPrime(n),isPrime(reversed), andreversed != n— confirms the emirp property exactly as before.
13, new StringBuilder("13").reverse().toString() gives "31", parsed back into the same 31 the manual version computes.Key Point: This is a matter of style, not efficiency — the StringBuilder version reads a bit more directly at the cost of allocating a small String and buffer, where the arithmetic version works with just primitives.
Why: Reversing through a String still costs only a handful of character operations, so the two O(√n) primality checks still dominate the total work.