Inspired by CtCI 16.8: Integer to English phrase in C++, I wrote a program to show the Japanese reading of an integer (positive, negative, or zero). The Japanese is written in Hepburn romanization to avoid encoding problems. Also, traditional Hepburn is used to avoid macrons.

Unlike English, Japanese has sound changes when two words come together. The details are given at the end of the question.

The program handles integers $n$ in the range $-2^63 le n < 2^63$.

Code

/**
 * Integer to Japanese reading
 *
 * Japanese reading is written in Hepburn Roomaji. Traditional
 * Hepburn is used to avoid the need of macrons.
 */

#include <cassert>
#include <cstdint>
#include <iostream>
#include <string>
#include <vector>

using number_t = std::int_fast64_t;

const std::vector<std::string> magnitudes = 
 "", "man", "oku", "choo", "kee",
;
const std::vector<std::string> thousands = 
 "", "sen", "nisen", "sanzen", "yonsen",
 "gosen", "rokusen", "nanasen", "hassen", "kyuusen",
;
const std::vector<std::string> hundreds = 
 "", "hyaku", "nihyaku", "sanbyaku", "yonhyaku",
 "gohyaku", "roppyaku", "nanahyaku", "happyaku", "kyuuhyaku",
;
const std::vector<std::string> tens = 
 "", "juu", "nijuu", "sanjuu", "yonjuu",
 "gojuu", "rokujuu", "nanajuu", "hachijuu", "kyuujuu",
;
const std::vector<std::string> ones = 
 "", "ichi", "ni", "san", "yon",
 "go", "roku", "nana", "hachi", "kyuu",
;

// returns 10000^n
constexpr number_t magnitude(std::size_t n)

 number_t result = 1;
 while (n--)
 result *= 10000;
 return result;


constexpr bool is_vowel(char c)

 switch (c) 
 case 'a': case 'e': case 'i': case 'o': case 'u': case 'y':
 return true;
 default:
 return false;
 


// joins two strings according to Japanese rules
void push(std::string& lhs, const std::string& rhs)

 if (lhs.back() == 'n' && is_vowel(rhs.front()))
 lhs += ''';
 lhs += rhs;


// converts nonnegative numbers less than 10000
std::string group_name(number_t number)

 assert(0 <= number && number < 10000);
 std::string result = thousands[number / 1000];
 number %= 1000;
 push(result, hundreds[number / 100]);
 number %= 100;
 push(result, tens[number / 10]);
 number %= 10;
 push(result, ones[number]);
 return result;


std::string to_Japanese(number_t number)

 if (number == 0)
 return "zero";

 std::string result;
 if (number < 0) 
 result = "mainasu";
 number = -number;
 

 number_t mag = magnitude(magnitudes.size() - 1);
 for (std::size_t i = magnitudes.size(); i-- > 0; mag /= 10000) 
 if (auto group = number / mag; group > 0) 
 push(result, group_name(group));
 push(result, magnitudes[i]);
 
 number %= mag;
 
 return result;


int main()

 for (number_t number; std::cin >> number;)
 std::cout << to_Japanese(number) << "n";

Example session

0
zero
1
ichi
2
ni
3
san
6789678967896789
rokusennanahyakuhachijuukyuuchoorokusennanahyakuhachijuukyuuokurokusennanahyakuhachijuukyuumanrokusennanahyakuhachijuukyuu
-1234567898765432
mainasusennihyakusanjuuyonchoogosenroppyakunanajuuhachiokukyuusenhappyakunanajuurokumangosen'yonhyakusanjuuni

Japanese numerals

(You can skip this part if you are familiar with Japanese.)

In the following table, red entries involve sound change.

beginarrayll
textNumber & textJapanese reading \
1 & text一 (ichi) \
2 & text二 (ni) \
3 & text三 (san) \
4 & text四 (yon) \
5 & text五 (go) \
6 & text六 (roku) \
7 & text七 (nana) \
8 & text八 (hachi) \
9 & text九 (kyuu) \
10 & text十 (juu) \
20 & text二十 (nijuu) \
30 & text三十 (sanjuu) \
40 & text四十 (yonjuu) \
50 & text五十 (gojuu) \
60 & text六十 (rokujuu) \
70 & text七十 (nanajuu) \
80 & text八十 (hachijuu) \
90 & text九十 (kyuujuu) \
100 & text百 (hyaku) \
200 & text二百 (nihyaku) \
300 & text三百 colorredtext(sanbyaku) \
400 & text四百 (yonhyaku) \
500 & text五百 (gohyaku) \
600 & text六百 colorredtext(roppyaku) \
700 & text七百 (nanahyaku) \
800 & text八百 colorredtext(happyaku) \
900 & text九百 (kyuuhyaku) \
1000 & text千 (sen) \
2000 & text二千 (nisen) \
3000 & text三千 colorredtext(sanzen) \
4000 & text四千 (yonsen) \
5000 & text五千 (gosen) \
6000 & text六千 (rokusen) \
7000 & text七千 (nanasen) \
8000 & text八千 colorredtext(hassen) \
9000 & text九千 (kyuusen) \
endarray

Larger numbers are considered the sums of smaller numbers. For example:

beginarrayccccccc
2019 & = & 2000 & + & 10 & + & 9 \
text二千十九 (nisenjuukyuu) & &
text二千 (nisen) & &
text十 (juu) & &
text九 (kyuu)
endarray

The missing hundred place is simply ignored.

Four digits are considered a group, unlike English, where three digits are a group. The group markers are:

beginarrayccc
10^4 & 10^8 & 10^12 & 10^16 \
text万 (man) & text億 (oku) & text兆 (choo) & text京 (kee)
endarray

For example, $1,2345,6789$ is read as 一億二千三百四十五万六千七百八十九 (ichioku nisensanbyakuyonjuugoman rokusennanahyakuhachijuukyuu). (The spaces are for ease of recognition only.) Note that 一 (ichi) is required before these group markers, unlike 十 (juu), 百 (hyaku), and 千 (sen).

0 is ゼロ (zero).

A negative integer $-n$ is read as マイナス (mainasu) followed by its absolute value $n$. For example, -5 is read as マイナス五 (mainasugo), because 5 is read as 五 (go).

When two syllables are joined, if the first syllable ends with "n" and the second starts with one of "aeiouy", then a separator ' is added between. For example, 1001 is 千一 (sen'ichi) and 1004 is 千四 (sen'yon).

The push function may invoke undefined behavior. When you create a new std::string, I don't think it is guaranteed to be null-terminated since that would incur a runtime cost for no benefit other than C compatibility. Only after calling c_str() the terminating null character is there. Because the string is really empty, calling back() accesses an out-of-bounds element.

You claim that your code works for $-2^63$ but you didn't add that number as a test case. I would expect it to not work since -(-2**63) is still negative.

Besides these two issues, your code reads well and is easy to understand. Adding the additional documentation was a very good idea for everyone not fluent in Japanese.

Your magnitudes should be chou and kei (as in the supercomputer, as an aside). Also, to_Japanese() would be better named to_romaji(). As an exercise, you could try to_Japanese(number, KANJI|HIRAGANA|ROMAJI) also.

Furthermore, it's icchou, not ichichou, and ikkei, not ichikei.

I think it would be better to generate the 漢字 versions of the numbers, as it's more useful in general. Make a separate class responsible for romanization (or phonetic conversion in general so it can support kana).

Using kanji also allows for somewhat trivially adding support for formal numbers (大字), which is kind of cool/useful.

I would also recommend adding support for breaking up the romaji sequences as reading very large numbers in romaji with no spaces is not at all fun. It could be an optional flag. A natural place to add spaces would be between magnitudes at least, or maybe between all of the various groupings you've already put together (ones, tens, hundreds, etc.).

As for using romaji to avoid encoding issues, I recommending biting the bullet and learning how to support Unicode correctly as it will be extremely useful.

I know in that in English that each word would be separate where the program is printing the all of the numbers merged together. Is this the actual functionality in Japanese?

Since the code might be useful in many places it might be better of the translation code as in a class.

Use of Vertical Space

Generally code is easier to read and maintain when only one value is on a line. This would apply to the initialization of the vectors and the switch statement in the function is_vowel(). For maintenance reasons it is much easier to insert a line where it needs to be than it is to add a value to a comma separated list.

is_vowel function

There would be less code if the vowels were in a std::map rather than a switch statement. Here are discussions on stack overflow and software engineering.

This portion of the answer has been modified to remove the statement that there might be a performance improvement using std::map. If map used a simple index into an array that might be true, however it is not a simple index into an array.

Assert
Assert statements are generally used for debugging purposes and terminate the program. Assert statements may be removed when the code is compiled without debugging as well. I don't expect to see asserts in production level code because it implies that the code is not yet debugged.