Proceeding of the 3rd International Conference on Informatics and Technology, 2009

REPRESENTATION OF CONDITIONS OF PROGRAMMING STATEMENTS IN

POST-COMPILE MODIFIABLE LAYOUTS

Ram Gopal Raj

Department of Artificial Intelligence,
Faculty of Computer Science and Information Technology,
University of Malaya, 50603 Kuala Lumpur, Malaysia. Email: ramgopalraj@perdana.um.edu.my

ABSTRACT

Software development for large scale systems is often very costly. Large systems tend to have long service lives and
thus meet with ever changing operational requirements. Catering to such changes necessitates changes to the
software resulting in increased expenditure. However, allowing the conditions for conditional statements such as ‘if
statements’ by which a program operates, to be stored in a format that does not require any application changes but
only external file changes can save considerable effort, time and money. Presented here is one of the techniques,
used by our chatterbot, RONE, to allow self adaptability on multiple levels. The technique is applicable to all
programming purposes, and will enable the making of fewer application changes and hence reduce corresponding
costs, for systems with long service lives.

Keywords: SQL, Knowledge Base, Conditions, Adaptability.

1.0 INTRODUCTION

Development of software systems is often tremendously expensive work. Apart from initial development costs,
software systems may experience lifetime costs. Lifetime costs occur if a software system requires further changes or
adaptations during its time of service. A software system is called adaptable if some of its properties, which are stable
during regular use, can be changed in order to meet diversified or changing requirements, [2].

Therefore we see two options. One option being to either spend a lot of money initially and build a very
comprehensive system that will have a long service life with minimal maintenance and updating issues or build a
simple and comparatively cheap system that will subsequently need frequent and costly changes. The other option,
being to have a system that could be modified during its operational lifetime without having to restructure large
masses of source code and change various conditions or add new conditions. For example, if the program was built
with a smart updating system which requires no recompilation or reinstallation but allows changes to be made during
its uptime, it would posses a considerable degree of reusability of the system itself as opposed to reusability of only
its components. Such adaptability and reusability would result in considerable savings in terms of long term system
maintenance.

Adaptability is favorable for a number of reasons. For example, human users usually have different needs, views,
ways and preferences; and there appears to be no ‘one best way’ to accommodate all their differences. The situation
escalates when one considers groups of humans or even entire organizations. As the world we live in becomes
increasingly computerized, accommodating the different human preferences and ever changing operational
environment conditions also increases in importance. As such software adaptability is becoming practically
indispensable. Additionally, by building adaptive systems, developers can maximize their profits by accommodating
even larger market segments. Currently software development is expensive and most software systems are not
completely custom-built anymore [1].

When we look at adaptability, we need to consider a number of factors. Firstly one needs to know just how much
adaptability is required, what are the aspects of the program that need to be adaptable? Once the required or desired
degree of adaptability has been determined, one must decide how to implement those features. We believe that the
most efficient adaptations are those that are implemented by the systems themselves through interacting with users,
rather than relying on users to tell the systems how to adapt. Our experience suggests that humans tend to be more
honest about how they would like a machine to behave when the users actually interact or use the machine rather
than when they describe how they would like the machine to behave. Finally, one has to figure out how all this
adaptability is to be accommodated in the software architecture? Consideration of these factors, suggests to us that
any system that is to be adaptable must be able to store new information.

Conversational programs must have the ability to learn from their interactions with users. In order to learn, these
programs must have an adaptive knowledge base system that can be updated by the programs themselves. We
have introduced our learning program, RONE, in a previous paper, [3]. We cover in this paper, a new technique used
by RONE for storing the conditions of programming ‘if’ statements as well as loop numbers in an SQL database in
order to allow a conversational program to adapt to future conversations. While we acknowledge that our research
scope is limited to enabling our system to perform only tele-text conversations with users, it must be clarified that
RONE is a chatterbot. The idea behind its design is to allow it to adapt on its own without requiring any recompilation
or reinstallation - a technique that is usable in other programming applications.

©Informatics '09, UM 2009 RDT7 - 257

 Proceeding of the 3rd International Conference on Informatics and Technology, 2009

2.0 COMPONENTS REQUIRED FOR NEW LAYOUT

There are three components that have to be built into a system using our adaptive technique. These are:
1. The actual SQL based statements representing the conditions,
2. The queries used for retrieving the conditions and
3. The programming statements used to process those stored conditions.

The traditional 'if' statements as used in programs are converted into very general ‘if’ statements containing no direct
condition references and results, but perform based on conditions and results stored in the SQL database. The
queries are the bridge between the two other components. Of the three components above, only the SQL based
statements need to be changed in order to adjust the behavior of the ’if’ statements.

2.1 Conversion of traditional programming statements into new format

The queries involve many 'or' conditions in concert with 'not' conditions. The idea is that the 'and or' is simulated by
many 'not and's as seen in Table 1. The limitation here is that it only applies to an 'if' statement with a finite number of
conditions. This is because the 'not' must include all the conditions that are not applicable. For example, the format
for "If before = preposition or conjunction and evenevenbefore = noun or UW then present = nounPhrase" translated
into "not and" is:

"SELECT WRD,EQLS,TMS,DVDS FROM RNCODE" +

" WHERE WRD NOT LIKE '%NT" + evenevenbefore +
"%' AND EQLS NOT LIKE '%NT" + evenbefore +
"%' AND TMS NOT LIKE '%NT" + before +
"%' AND DVDS NOT LIKE '%NT" + present +
"%') AND MNS NOT LIKE '%NT" + next +
"%'

Table 1: Example of Storage Format for "or and" method

WRD EQLS TMS DVDS MNS PLS

Breakdown evenevenbefore evenbefore before present next null

Example NTinterjection # NTinterjection =noun # #
NTathean NTathean NTnoun
NTconjunction NTverb
NTpreposition NTadjective,
NTverb NTadverb
NTadjective NTquestionword
NTadverb NTpronoun
NTquestionword NTnounPhrase
NTpronoun
NTnounPhrase
Equivalent
programming If before = preposition or conjunction and evenevenbefore = noun or UW then present = nounPhrase
statement
interjection, athean, conjunction, preposition, noun, verb, adjective, adverb, questionword, pronoun,
All Possibilities
nounPhrase

The "not and" conditions in Table 1 are labeled with an "NT" to differentiate the conditions from the solutions which
are marked with a "=". Our examples involve a part of speech prediction algorithm that we implemented in RONE.
The algorithm consists of a finite number of outcomes, the eight parts of speech, as well as a finite number of
conditions since the algorithm is based on preceding words and on occasion subsequent words. Due to the adaptive
nature of RONE, the complete set of rules as listed were derived from RONE's experiences rather than determined
by us. The rules were determined by experiences of recognized word patterns and the preceding and following words
in the sentences in which the relevant words appeared. Therefore the rules themselves were in part derived by the
program, adding proof to the suitability of using our technique in adaptive programming.

3.0 IMPLEMENTATION OF NEW FORMAT

When RONE encounters an unknown or never encountered word (UW), it will use an algorithm to predict what part of
speech that word belongs to. The algorithm is based on English sentence structures. Instead of the implementation

©Informatics '09, UM 2009 RDT7 - 258

 Proceeding of the 3rd International Conference on Informatics and Technology, 2009

method of "not and" as seen in Section 2.0, we chose to use regular "or" matches for greater flexibility as well as the
suitability in matching multiple patterns since it is more flexible than the "not and" implementation.

In almost any complete sentence an unknown word is often surrounded by other words, either before or after the
unknown word (UW). The exceptions of course are punctuation marks that the system segregates as other words
since these punctuation marks often have an impact on the meaning of a sentence and the UW being at the
beginning or the end of a sentence. However it is still possible to accommodate those circumstances. The naming
conventions used are ‘present’ for the part of speech of the present word that the system is looking at, ‘before’ for the
part of speech of the word before, ‘evenbefore’ and ‘evenevenbefore’.

The following are the basic rules used in the algorithm:

If present = UW then check before.

If before = adjective or verb then present = maybe a noun or an adjective = maybeMnoun/adjective.
If the word before is a, the, or an, athean in our naming convention, i.e. before = athean, or before = preposition or
before = conjunction then present = maybeMnoun/adjective.
If before = maybeMnoun/adjective then present = noun and before = adjective.
If before = UW and present = UW, if evenbefore = conjunction then before = nounPhrase.
If before = noun then present might be a verb or maybeverb.
If before = preposition or conjunction and evenevenbefore = noun or UW then present = nounPhrase.
If before = maybe/nounProper then before and present = nounPhrase.
If before = pronoun then present might be a noun or maybenoun.
If before = questionword and/or evenbefore = interjection then present = verb.
If before = interjection then present = pronoun or noun.

The above set of algorithm rules caters for a ‘present’ word the system is looking at. However for the purpose of
processing all the ‘maybes’ that may be generated in the ‘present’ processing algorithm, when the system has moved
on to the following word, what was the ‘present’ word becomes the ‘before’ word. Thus the ‘before’ word may need to
be processed. However the algorithm for the ‘before’ word is outside the scope of this paper. Hence it is covered in
other publications and not in this paper.

The algorithm for the ‘present’ word can be implemented as a set of ‘if’, ‘else if’ and ‘else’ statements but for the
purpose of the system’s evolving and learning capability, the algorithm is stored as a combined ‘if’, ‘else if’ with
conditions stored in the knowledge base itself using the technique described in this paper.

3.1 Statement storage as part of the knowledge base

In order for the system to be able to learn on multiple levels, we have implemented the statements as part of the
system’s knowledge base. To insert the conditions into the database, SQL INSERT statements such as the one
below are used.

INSERT INTO RNCODE (WRD,EQLS,TMS,DVDS,MNS,PLS)

values ('#','#','adjective || verb','= noun','athean || pronounPossession || adjective || preposition','#')

Each table in the knowledge base has six columns that are used as a filter for what a particular word could represent
or mean. The six columns are WRD, EQLS, TMS, DVDS, MNS and PLS. The intention here is not to produce a
regular relational database, using standard database design rules and practices such as normalization, but to use the
tuples and rows in a unique manner that will allow the knowledge base to grow at the program’s disposal and yet
continue to be manageable, meaningful and usable. Therefore, normalization or database design diagrams are not
used or presented in this description of RONE.

The conditions and solutions are stored in our standard knowledge base layout shown in Table 2.

Essentially we use each subsequent row as a step by step ‘if’ and ‘else if’ format. The code loops the same SQL
statement repeatedly through the table row by row until all the lines have been gone through. The SQL statement we
used for the system is as follows:

"SELECT WRD,EQLS,TMS,DVDS FROM RNCODE" +

" WHERE codeNum =" + (countRules+1) +
" AND (WRD LIKE '%" + evenevenbefore +
"%' OR EQLS LIKE '%" + evenbefore +
"%' OR TMS LIKE '%" + before +
"%' OR DVDS LIKE '%" + present +
"%') AND MNS NOT LIKE '%" + next +
"%'"

©Informatics '09, UM 2009 RDT7 - 259

 Proceeding of the 3rd International Conference on Informatics and Technology, 2009

In this case RNCODE is the table’s name and countRules is the counter for the loop used to match the row in the
table. The statement retrieves the appropriate condition from the knowledge base for an answer to be found. The
answer or change is marked with a ‘=’. Of course the statement is only used if a word is UW or NO-MATCH.

Table 2: Example of Storage Format for "or" method

WRD EQLS TMS DVDS MNS PLS

Breakdown evenevenbefore evenbefore before present next null

Condition && Condition || Precondition =
Markers
condition 2 condition 2 ANSWER
athean ||
Adjective ||
Example # # = noun pronounPossession || #
verb
adjective || preposition
If ((before = adjective || before = verb) && (next != athean && next != pronounPossession && next !=
Equivalent adjective && next != preposition)
programming {
statement present = noun;
}

The output from the database is then processed with the algorithm in the flowchart shown in Fig. 1 below.

Fig. 1: Flowchart for Outcome Processing Algorithm

Output processing is used to extract the answer to the result from the database. Our method uses the "=" character
to mark the answers.

©Informatics '09, UM 2009 RDT7 - 260

 Proceeding of the 3rd International Conference on Informatics and Technology, 2009

3.2 Usage of technique in RONE

The technique presented in this paper was implemented in RONE. The screenshot in Fig. 2 shows and example of
the outcome of the processing of the sentence "Writing a conference paper is a complicated process". As can be
seen, initially RONE finds no matches for which part of speech the words "writing", "conference", "paper" and
"complicated" belong to. The result of the processing is that "writing" is a verb, "conference" is a noun, "paper" is a
noun and "complicated" is part of a noun phrase.

Fig. 2: Sentence part of speech screenshot

4.0 DISCUSSION AND CONCLUSION

In the example given in Fig. 2, the word "Complicated" is often an adjective and not a noun phrase but that is a
limitation of the unknown word processing algorithm, which will eventually be overcome as RONE encounters more
and more sentences. However we wish to point out that the words "complicated process" can be taken as a noun
phrase so the outcome of the processing is not erroneous, but simply a possible interpretation. As far as an adaptive
alternative to the traditional programming condition statements, the technique for condition statement representation
presented in this paper is sound.

There are many methods utilized by RONE in conversing with users and learning from those conversations. Most of
these methods are designed to allow RONE to adapt to future conversations by self-expansion of his knowledge
base. These other methods will be the focus of future publications.

REFERENCES

1. Ackermann, D. and Ulich, E., “The Chances of Individualization in Human-Computer Interaction and its
Consequences,” in Psychological Issues of Human Computer Interaction in the Work Place, M. Frese, E. Ulich,
and W. Dzida, Eds.: Elsevier Science Publishers B.V. (North-Holland), 1987, pp. 131-145.

2. Henderson, A. and Kyng, M., “There's No Place Like Home: Continuing Design in Use,” in Design At Work, J.
Greenbaum and M. Kyng, Eds. Hillsdale, New Jersey: Lawrence Erlbaum Associates, Publishers, 1991, pp.
219-240.

3. R.G. Raj (2008), Using SQL databases as a viable memory system for a learning AI entity, 3rd International
Conference on Postgraduate Education (ICPE-3’2008), Penang, Malaysia, (Paper ID: BRC 160)

BIOGRAPHY

Ram Gopal Raj is a PhD. Candidate at the University of Malaya. His ongoing project involves development of a self-
learning, self-adapting program named RONE that utilizes its unique capabilities to perform tele-text conversations
with users. Ram’s research areas include knowledge representation and natural language processing. He has written
some other papers related to RONE.

©Informatics '09, UM 2009 RDT7 - 261