A bipartite graph structure for Tamil

Remark: Tamil alphabets [which are Abugida or alphasyllabary in nature] can be written as a fully connected bipartite graph G(C+V,E). Both the basic 247 letters [known to have a ring representation] and sequences involving வட மொழி letters can be written in the sequence of two sets, V – vowels [உயிர்] and C – consonants [மெய்], and edges E: C -> V forming a map from each consonant to vowel (e.g.: க் + அ -> க ) are the உயிர்மெய் எழுத்துக்கள். This is a bipartite graph. Strictly speaking we can add அயுத எழுத்து ‘ஃ’ as a disconnected node and call it a forest graph. This may be simply extended to cover the வட மொழி எழுத்துக்கள் [Sanskrit letters optionally used in Tamil]. Full alphabet set is obtained by cumulative sum of edges and vertices.

Corollary: Most other alphasyllabary, Abugida languages have a similar bipartite graph representation.

Fig. 1: A fully connected Bipartite graph K(5,3). Credit: Wikipedia.

A group structure for Tamil

We can form a group structure for Tamil alphabets in many ways; simply we may apply residue classes modulo N or symmetric group of permutations modulo N for any cardinality. However, one interesting group structure with applications is the abstraction of 247 Tamil letters written on a torus; in this essay I will attempt to describe it and show that it forms a group.

We consider the 247 Tamil letters formed by 1 ayudha letter and 12 uyir letters for 13 vowels, and 18 mei letters for 18 consonants and 216 uyirmei or conjugate letters [247 = 13 + 18 + 216]. By consider a mapping of 13 vowels to Z₁₃[residue classes modulo 13] and 18 uyirmei letters + ayutha letter to Z₁₉ [residue classes modulo 19].

Fig. 1: The Cayley table for Z13 can represent Uyir letters.

Fig. 2: The Cayley table for Z19 can represent Mei letters (with modification)

Representation

Further we may represent each uyirmei letter as a index into a 2D table formed by rows of mei letters, and columns of uyir letters. So, for example letter ‘கு = க் + ஊ’ can be written as 6 + 1*13 = 19. Uyir letters are all represented from [0-12], Mei letters are represented as multiples of 13, [13, 26, 39, .. 234] for [க், ச், … ல், வ், ழ், ள்]. Uyirmei letters form everything in between.

The general representation of a letter can be: t = a + 13*b, where a goes from [0-12] and b goes from [0-18]. This representation pegs ‘ஃ’ at the origin. In the direct product of Z13 and Z19 this will be represented as (a,b)

Letter representation in the product group: Z13 x Z19

Result

Further since we showed uyir and mei letters can be embedded into the Z13, and Z19 residue classes and we know 247 factors neatly into 2 primes 13 and 19, we may use the Chinese remainder theorem (which guarantees that given two sets of residue classes which are co-prime, we can form a residue class with a unique representation for the direct-sum [direct-product] of the underlying sets). In our case we are guaranteed that Z13 x Z19 direct sum structure forms an isomorphic group in Z247. This is the key result in this easy:

Tamil letters [247] have a direct product representation in group Z247 which is isomorphic to the direct product of Z13, Z19 as mapping the uyir and mei group representations.

Key result – Group representation for Tamil alphabets

While Chinese remainder theorem guarantees a ring structure, I don’t know the second operator which can take role of product to make the ring structure possible at this writing.

Tamil Entry via Keypad – 9XYZ30-த-மி-ழ்

Previously, My initial calculations can be revised in terms of the estimates. I will not go into further detail here; my latest estimate shows the number of realizable keyboards to be 264,250,749,803,040 or 264billion – a bit of an astronomical number.

The money questions are the following:

1. Given the astronomical size of keyboards possible is there one that is easily decodable than the other ? Yes, or no ?
2. Is there any decodable keyboard at all?
3. Is there a ‘1-800-FLOWERS‘ type of representation possible atleast for a few words in Tamil ?

Today, I was toying with some simple designs and made it into software:

Fig 1: Simple 4×3 keypad layout in iOS

One particular realization of the keyboard looks like where 20 Tamil letters are roughly mapped into 1 keypad as shown in the excel sheet below. We also see the canonical 4×3 keypad matrix in the rows 20-23 showing the 12 keypad positions where 20 letters are going to be mapped into.

Fig 2: Mapping first 20 letters of Tamil alphabet set into a 4×3 keypad.

We show how the phone number “9XYZ30477” will mean “9XYZ30-த-மி-ழ்” in this keypad.

Fig. 3: A simple realization of keypad mapping in Tamil; e.g. number “9XYZ30477” would can be advertised as ‘9XYZ30-த-மி-ழ்’.

Immediately few things are coming to our attention:

1. Entering user input in the keypad is easy; we follow a simple natural language suggested representation
2. However, we have some issues in realizing this keyboard – ambiguity: Does ‘111’ in this keypad entry, with following mapping shown, mean ‘அக்கா’ or ‘கட்சி’ ?
3. The “obvious” finite ring keypad mapping fails here.

Realizations:

1. Whereas a simple keyboard realization of this scheme shows words typed of equal length like ‘அக்கா’ and ‘கட்சி’ are completely undecidable/un-decodeable. So our criteria is really the good realizable keyboard maximizes the word decidability, or minimizes word collision.
2. Ease of user input:
   Also we may want to make ease of user entry into this keyboard simpler [which the ‘obvious choice’ keyboard contains] while still maintaining the decodability.
3. We identify the mapping used above with a simple algebraic structure similar to a finite semi-group with operations of commutativity, in-group operation and identity formed by ‘ஃ’ ayutha letter. This is a interesting mapping with potential to adapt the operator for creating a full semigroup or group structure for the language.
4. Finally we discover:

The letters with the high bi-gram frequency may not be co-occurring in the same keypad square. This is an operational principle that will reduce the ambiguity of the model. We will have to balance this with other decidability criteria of user input etc.

Operating Principle – we understand this from our failed experiment.

This type of keyboard design could also equally apply for other Abugida languages – which is most Indian languages.

Tamil Entry via Keypad

One problem that seem to not draw interest from various actors in digital Tamil community seems to be the Tamil input via 4 x 3 standard Keypad.

A standard 4×3 keypad shown with digits and letters, including Japanese key entry on a vodafone device. Image credits to Wikipedia.

Problem Statement: Given a 4×3 matrix of keys in a phone keypad, how can we input the basic 13 + 18 + 12×18 = 247 letters of Tamil alphabet using this device ?

Alternate: Clearly, 247 letters have an information content of bits or roughly 8bits. So we can simply punch in 3 keys for indicating this 8bit combination and we are done. Provide a table to the user about 247 letters and their 3-numeric key map and we have solved this problem in one way.

This is not very satisfying however; we seem to put the user to more work; we would instead like to have similar entry method in Tamil just like in English (where 3 letters are grouped per telephone key). The processor for application in the phone or mainframe can decode any ambiguity of the telephone keypad mapping into meaningful words or phrases.

Ideas: We can come up with various proposals; being lazy, and the official jester of Tamil computing community, I will try and make a simple combinatorial analysis for this problem without giving a specific solution.

Details: We can consider the factors of 247 = 19 x 13 which form a matrix of all letters representing the Tamil alphabets and we can count the partitions of this matrix onto the smaller keypad matrix. Following the roman letters of English alphabet consisting of 26 letters are fit easily into the 4 x 3 matrix on average of little less than 3 letters per key, we can also adopt a similar convention.

There are many ways to fit this large 19 x 13 matrix into a 4 x 3 matrix. Using simple combinatorial analysis we may show 19 letters can be divided into 4 groups as (ignoring the assignment of letter groups to keys – ways) along the rows. Similarly, we group along columns in ways (and ignoring the 3! column permutation themselves). In all we have a total of key grouping combinations.

Clearly we have an alternate possibility of grouping the 19 x 13 matrix as a transposed matrix – i.e grouping dimension of 13 elements of Tamil alphabets into larger keypad dimension of 4, and assigning 19 elements along the fewer keypad dimension of 3. This alternative gives us

Together we have a total of 1,801,371. Thats roughly 1.8 million possibilities! Check them yourself by running this code:

	# Code for blog post: https://ezhillang.blog/2019/03/01/tamil-entry-via-keypad/
	# This code is in Public Domain.
	from math import factorial as f
	from math import log
	def comb(n, k):
	return (f(n) / f(k)) / f(n - k)
	def nck(n,k):
	return comb(float(n),float(k))
	C1 = nck(19,4)*nck(13,3)
	print "C1", C1
	C2 = nck(13,4)*nck(19,3)
	print "C2", C2
	print "Total=",C1+C2
	print "Logaritmic capacity for 247 letters = ",log(247.0)/log(2.0)
	print "Grand total", f(3)*f(4.0)*(C1+C2)

view raw tamil_keypad_mapping.py hosted with ❤ by GitHub

. The real grand total of possible designs is to include the key permutations of the grouping we have already found, thereby adding a factor of to the previous 1.8 million so we get grand total of keypad mapping designs as 259,397,424 or 259 million keyboard combinations in all!

Conclusion: How are we going to find a suitable keypad mapping? Well we may need more heuristics and more cleverness to find the keypad mappings [a few definitely exist in this 259 million possibilities, which maximize a utility function.

So that leads us to the next problem: what is the utility of mapping a Tamil letters in the keypad ? Well – we don’t know apparently, so it doesn’t exist! This also ties into the philosophical question of what is the purpose of all software if not to support use.