Sunday, July 14, 2013

A Logic that Urinates


It is said, in North Korea, children are taught that their loving ex-leader Kim Jong Il did not even have to urinate because he was so pure. No excrement generated in his body due to his super-human purity. As a software engineer I think that most of our code behaves also like Kim Jong Il. Our code is ultra pure so that it surpasses every contingency in general human discourse occurring due to imprecision and vagueness. For instance, the statement start_time = 3 in a computer program literally means it while in human conversation “The event starts at 3” does not imply a rigid spontaneity. In a statement like the later, we humans implicitly agree that the start time can fall within an acceptable time window centered around 3. In any society, a deviation of few seconds will be accepted. However, the program would not accept 3.0001 or 2.998. This behavior with programs generally works. If you are developing accounting software, you probably don’t want to jeopardize your program logic with vagueness in human thinking. In fact lot of practices are involved in software delivery (such as manual testing, unit testing and code quality analysis) to cut the crap introduced by humanness and make the software as pure as Kim Jong Il. However, there are cases that a programmer is left with no other option but to stretch boundaries of his thinking a little further than the psychotic notion of purity and to get along with the real world while encountering its inevitable vagueness. Following is an example from a recent programming experience of mine.

Recently we implemented an iPad navigation app for a leading Norwegian GIS (Geographic Information Systems) company. The app is intended to help people when going on boat rides by providing specialized maps. In addition to this main purpose it is bundled with lot of other useful features such as path tracking, geo-fencing, geo-coding, social media sharing, etc. Not surprisingly the app needs to determine user’s current location to enable most of its features. For this, we employed location services API that ships with iOS. It uses various sources such as GPS, access tower data and crowd-sourced location data when determining the geo-coordinates of the device location. Each of these location sources has different implications on accuracy and battery consumption. For instance, GPS is by far the most accurate method, but drains the battery faster. On the other hand, wifi iPads that amount to a significant fraction of the iPads that are currently in use, do not have GPS receivers. The only accessible location information for them comes from crowd sourced location data from wifi hot spots that agree to share their location. Inevitably these location coordinates are less reliable. One nice thing with iOS location API is that, along with every location coordinate it also provides information on how accurate (or how inaccurate) the reading can be. This is called the tolerance value. For example, when we see a location coordinate (in the form latitude – longitude) 35.45o, 4.87o with tolerance 20 meters, we know that the user’s actual location can be anywhere inside a circle of radius 20 meters centered at the point (35.45o, 4.87o). With our experiments we figured out that when GPS is used to determine the location, tolerance level is as low as 5 meters. However, with wifi iPads, the best we observed was 65 meters. To make things more complicated, even the iPads with GPS receivers, at times, can go low down in accuracy (with tolerance levels as high as several hundreds of meters). This particularly happens when the device is in the vicinity of objects like huge concrete structures or large trees that effectively blocks GPS signals.

Need to determine location accuracy mode
Experimentation clearly suggested that there are two disparate modes that an iPad can be operating at a given moment with respect to location detection; high accuracy mode and low accuracy mode. These two modes are characterized by the following behaviors.

High Accuracy Mode (HAM)
Low Accuracy Mode (LAM)
Tolerance value is low for most location readings
Tolerance value is high for most readings
Location readings are received in regular intervals (can be as frequent as once in a second)
Location readings are received less frequently (usually only few times in a minute)


When in high accuracy mode we can treat received location coordinates as the actual location. In addition we can happily ignore intermittent low accuracy readings (readings with high tolerance values – these can occur even in high accuracy mode occasionally). In contrast, the programmer has to make every attempt to use all acceptable readings (readings without crazily high tolerance, such as more than 1 km) when in low accuracy mode since only few location readings are typically received during 1 minute. Also, corrections may need to be applied (depending on the purpose) since the accuracy level is low. Because the developer has to apply two kinds of logics depending on the accuracy mode, it’s necessary to determine the mode that the device is operating at a given moment. One should also note that the mode could change with time; for instance, when a person is moving with a GPS iPad, the device can be operating in high accuracy mode mostly, but can also switch to low accuracy mode when it is close to a big building.

Difficulty in drawing the line between two modes
The first (and probably the toughest) challenge is to correctly figure out whether the device is operating in HAM or LAM. It doesn’t take much thinking to identify that one can use both tolerance value and location reading frequency to determine the mode. If most tolerance values are low and the device is receiving location readings in regular intervals, it should be in high accuracy mode. However, formulating the logic is not as simple as it sounds because it needs explicit manifestation of numeric boundaries between the two modes. For example, let’s say that we decide to conclude the operating mode as HAM when the best tolerance is less than 20 meters and 15 readings or more are received within a period of 30 seconds. It’s not difficult to illustrate the problem associated with this approach. Consider the following 3 cases.

Case 1: Best tolerance is 18 meters and 15 readings are received within 30 seconds.
Case 2: Best tolerance is 21 meters and 15 readings are received within 30 seconds.
Case 3: Best tolerance is 18 meters and 13 readings are received within 30 seconds.

Intuition suggests that most probably the device should have been operating in the same mode in all 3 cases. However, our previous logic with stubborn numeric boundaries results in case 1 being identified as high accuracy mode, while the other two being recognized as low accuracy. Can you see the problem here? The problem is not about using numeric boundaries (we have to do that as long as we program for a Von Neumann computer). However, the problem lies in selection of the numeric boundary. What justifies selection of 20 meters as the tolerance boundary? Similarly, how confident are we, that the frequency boundary should be 15? A sufficient probe into the problem would reveal that it’s almost impossible to develop a sound heuristic that determines these boundary values “accurately”.

Where exactly is the problem?
The problem really lies on the discrepancy between skills of humans and computers. Humans are clever in dealing with concepts than with numbers while computers are better in handling numbers. This is evident in that we could distinguish between the two modes easily when we were talking in terms of concepts (to reiterate our previous statement -> ‘If most tolerance values are low and the device is receiving location readings in regular intervals, it should be in high accuracy mode’). The moment we try to put this logic in terms of numbers, we run into chaos. This is a clear case where ‘pure logic’ leaves us in a desperate abyss. 



Fuzzy logic brings in a solution
The brilliant intellectual Lotfi Zadeh introduced Fuzzy Logic in 1973, which constitutes a beautiful solution to problems like the one articulated above. Fuzzy Logic, in its core, builds a sophisticated mathematical framework that can translate semantics expressed in vague human terms into crisp numeric form. This enables us, humans, to express our knowledge in a particular domain using a language familiar to us, but still make that knowledge solve concrete numeric problems. For example, our knowledge can be expressed like the following rules that are used to determine whether a candidate should be chosen for a job depending on his experience, education and salary expectation levels.

If Experience is High, Education level is Medium and Salary expectation is Low, then hire the guy.

If Experience is Medium, Education level is High and Salary expectation is High then do not hire the guy.

If Experience is High, Education level is Somewhat High and Salary Expectation is Very High then do not hire the guy.

Rules like above can be formed using our knowledge, experience, gut feeling, etc about the domain. The collection of rules is typically termed Fuzzy Rulebase. We feed the rulebase into a Fuzzy Logic System (FLS), which aggregates and stores this knowledge. Most notably, the FLS stores the knowledge in a numerical logic that can be processed by a computer. After that FLS is capable of answering questions like the following.

If the Experience level is 4 (out of 5), Education level is 3 and Salary Expectation is 4, should we hire the guy?

No need to mention that, the richer the rulebase is, the more accurate is the outcome.

A Little further insight into Fuzzy Logic
How does Zadeh’s new logic perform its wonders under the hood? If fuzzy logic is a complex and amazing structure, the magic brick it is built by is the concept termed possibility. Zadeh’s genius is to identify that, in human discourse, likeliness does not refer to likelihood, but to membership. Let me exercise my teaching guts to describe this in a more digestible form. When we humans are confronted with a question like “How hot is 25oC?” we do not think it like “What is the likelihood that 25oC can be considered hot?” (Do we?). We rather think it like “Up to which degree does 25oC belong to the notion ‘hot’?”. To put the same thing in different terms, it’s about “the degree of belongingness to something” but not ”the probability of being something”. You might now be thinking of giving up the idea of becoming Zadeh’s follower, but I suggest you to hold on and give it a second thought.

I believe that Zadeh touches the real nerve in the problem when he makes this distinction between likelihood and membership. After understanding this by heart it’s an easy ride into the rest of the theory. As the next step we can introduce a term for concepts like ‘hot’, ‘beautiful’ or ‘high’. Fuzzy logic calls them fuzzy sets. A fuzzy set is an association between a number and a possibility value (Possibility is a number between 0 and 1 – just like probability, but at the same time radically deviating from it conceptually). Following figures provide examples. First one defines the fuzzy set “LOW” when input values are given from 1 to 5. For instance, if an examiner evaluates a student’s proficiency in a subject with a number between 1 and 5, how much will each mark mean to be ‘LOW’? We know that 1 is absolutely low. Therefore we consider the possibility of mark 1 being in the fuzzy set ‘LOW’ as 1.0 (maximum possibility). Also we can agree that mark 5 cannot be considered ‘LOW’ at all. So its possibility of being ‘LOW’ is zero. Marks between these two have varying degrees of membership in the fuzzy set ‘LOW’. For example, if the examiner gives mark 4 we consider student’s proficiency to be ‘LOW’ only with a degree of 0.25. The fuzzy set ‘HIGH’ (last plot) is defined in a similar way. What about the middle one though? It’s not a fuzzy set that stands for a brand new concept, but one that stands for a modification of a previously defined concept. The modifier ‘VERY’ is applied to the concept ‘LOW’. Noting that the modifier is an intensifying modifier (one that further strengthens the concept) we square each possibility in ‘LOW’ to get possibilities in ‘VERY LOW’. Gut feeling says that membership of mark 4 in fuzzy set ‘VERY LOW’ should be less than its membership in ‘LOW’. And the numbers resemble that notion.
                         Possibility [4 is VERY LOW] = 0.25 * 0.25 = 0.0625

















It’s not difficult to grasp the idea of fuzzy variables. They are fundamentally measurements or entities that can take fuzzy sets as their values. Example fuzzy variables can be temperature, student’s proficiency, candidate’s experience and so on. After that we can combine a fuzzy variable with a fuzzy set to construct a meaningful statement like “temperature is LOW”. These can be termed atomic statements. To express it formally, an atomic statement is of the form:
                                        <fuzzy variable> is <fuzzy set>

Now we walk the next step by combining several atomic statements into a compound statement. A compound statement would look something like “Student’s math proficiency is LOW, English proficiency is HIGH and music proficiency is MEDIUM”. These types of statements are useful when making judgments based on a combination of factors. For instance, a judge panel might want to make a final decision on whether to pass a student from the exam by looking at all his subject level proficiencies. Suppose that the judge panel decides this: “If there is a student whose math proficiency is MEDIUM, english proficiency is MORE OR LESS LOW and music proficiency is HIGH we will pass him”. This is termed a fuzzy rule. More appropriately, a fuzzy rule is a compound statement followed by an action. Another rule can be: “If the student’s math proficiency is VERY LOW, English proficiency is high and music proficiency is LOW we will fail him”. If the judge panel can compile a bunch of rules of this form it can be considered to be the policy when evaluating students. In fuzzy logic vocabulary we call it a fuzzy rulebase. It is important to note that a fuzzy rulebase need not be exhaustive (meaning that it does not have to cover all possible combinations of scenarios). It is sufficient to come up with a rulebase that covers the problem domain to  a satisfactory level. Once the rulebase is fed to a fuzzy logic system it is capable of answering questions such as “If the student’s math grade is 3 (in a scale of 1 to 5), English grade is 2 and music grade is 3, should we pass him?”. This is all one needs to understand to use a fuzzy logic library. Inner workings of the theory on how it really derives the answer based on rulebase are beyond the scope of a blog post. Also I think that 90% of readers would be happy to learn that the math bullshit is going to end from here.

Application of fuzzy logic into our location detection problem
Let me repeat our problem; we receive location coordinates in iPad with varying frequencies and tolerance levels. By looking at tolerance values and location coordinate frequency, we need to determine whether the device is in high accuracy or low accuracy location detection mode at a given time. We decided to determine the location detection mode every 30 seconds. At each 30 second boundary we used location coordinate values received within the last 30 seconds to determine the mode. All location related processing for the next 30 seconds are performed with respect to this newly figured out mode. For instance, if we decide that the device is operating in high accuracy location detection mode, we assume that the device operates in the same mode until we perform the evaluation after another 30 seconds. For this, we used following two parameters as inputs in the problem.

  • Tolerance values for best two location coordinates (coordinates with lowest tolerance values) within past 30 seconds
  • Number of location coordinate values received within past 30 seconds (highest possible value is 30 as we configure the device to receive location coordinates every second. However, when in low accuracy mode, number of coordinates received within 30 seconds is way less than 30).

We defined each of the 3 inputs to take values within a universe with 5 fuzzy sets: VERY LOW (VL), LOW (L), MEDIUM (M), HIGH (H) & VERY HIGH (VH). Then we worked out a bunch of fuzzy rules using these inputs and fuzzy sets. Rules are derived using gut feeling decisions on the domain. Following figure shows a part of the rulebase we constructed.
            



For instance, Rule No. 1 says that “If both best tolerance values are VERY HIGH and the reading count is LOW, decide location detection mode to be low accuracy mode. Rule No. 5 reads as “If the two best tolerance values are MEDIUM and VERY LOW while the reading count is MEDIUM, identify it as high accuracy mode, and so on.

At run time we determine numerical values of our 3 input parameters. An example input set can be:
                  tolerence1 = 10 meters, tolerence2 = 25 meters, reading count = 20

Using the rulebase, fuzzy logic system is capable of deriving an answer to the question “Which location detection mode the device is currently operating in?”. Our experimental results were exciting. With the aid of fuzzy logic we arrived at a sensible solution that provides accurate results to a problem that is almost unsolvable using conventional crisp logic. Our app is now in AppStore as the most popular navigation app in Norwegian market.

Saturday, May 11, 2013

My Publication in SATURN 2013 Architecture Conference



This work describes a solution to a costly problem that surfaces in software product engineering on Objective C technology stack. Particularly, it emerges when designing a software product targeting both OS X and iOS where a significant part of the functionality is common for both platforms. This brings in the question of how much code can be reused between the two implementations.

A multitude of concerns need to be probed and the solution domain can easily be a victim of combinatorial explosion. Like in many other cases, analysis in terms of design patterns can put things in perspective. Both Cocoa and Cocoa Touch (standard frameworks for application development in OS X and iOS respectively) highly encourage embracement of MVC as a design pattern. It is even a necessity for utilizing certain parts of the two frameworks. Therefore, it is wise to keep our solution inside the MVC design paradigm. Our exploration to the solution starts with a close examination of MVC and the role played by each component in the design pattern.

Controllers in both Cocoa and Cocoa Touch are responsible for managing views and responding to user actions, embracing Strategy pattern. They are tightly bound to the views they control and  therefore are hardly useful outside the context of that particular view. At the same time views and controllers in OS X (based on NSView and NSViewController respectively) are disparate from views and controllers in iOS (based on UIView and UIViewController respectively). This is mostly due to differences between the two platforms.  It inevitably confines cross-platform reusable space to model classes. On the other hand, it is not very unlikely to have certain views in the product that are supposed to appear and respond to user events in similar ways in the two platforms. Failure to exploit this cleverly in the architecture can lead to code replication causing less maintainability. It will also disrupt the homogeneity in user interface semantics of the application between the two platforms. Thereby strict adherence to traditional MVC hinders the architect from harnessing the power of this domain artifact.



Strict MVC is not the only blockade for reusing user interface semantics between OS X and iOS. There is another prominent disparity between Cocoa and Cocoa Touch in terms of the degree of support to implement Observer pattern between models and views. Cocoa supports configuring bidirectional bindings between views and models straightaway through Interface Builder (designer tool used for OS X and iOS application development) whereas Cocoa Touch does not. iOS developer has to craft a bidirectional binding solution atop framework-provided Key Value Observing and Key Value Coding patterns.

The above reasons compel the solution space for implementing generic user interface logic to stay outside of framework-provided, and hence platform-specific view and controller base classes. However, user interface logic does not naturally fit inside models in MVC too. A diligent analysis would make it clear that the need here is a cluster of classes where each one stands as an abstraction of a particular view. This relates closely to the idea of view models  in MVVM design pattern which is popular in Windows application development. In MVVM paradigm, a view model is a container for data that are shown and manipulated in a view along with behavioral logic that rules user interaction with the view.  A view model is not supposed to know about specific view instances while it is the view that hooks into the view model.



As a means of encapsulating generic user interface logic we experimented implementing view models to supplement the MVC design. Our architecture comprised models, views, controllers and view models . Solution constituents are as follows.
  1. Models encapsulating business logic, data logic, etc. are implemented by following the typical MVC notion. These classes are reused between OS X and iOS.
  2. View models implement the common parts of user interface. Each view model contains data shown in its intended view and user interaction behaviors. View models are also shared between the implementations for two platforms.
  3. Views in OS X implementation bind their data to corresponding view model data members. This ensures that changes in views are reflected in view models and vice versa without any glue code.
  4. Views in  iOS implementation hook into the same view models as used by OS X. They make use of user interaction logic in view models in a similar way. However, data binding with view models needs to be implemented explicitly. The glue code is implemented in controllers using Key Value Observing and Key Value Coding.
  5. In both OS X and iOS implementations controller classes are responsible for managing views. Since bidirectional bindings between views and models are configured via Interface Builder, controllers in OS X implementation are very lightweight. Controllers in iOS, on the other hand, require glue code that implements bidirectional bindings in addition to view management code.
  6. Similar to MVVM pattern, views do not directly associate with models. Any data contained in models that require being accessed by views are exposed to views through view models.



This scheme enables developers to implement common user interface logic in view models that are shared between the two implementations. In addition to the key benefit of improved code reuse, it delivers numerous other advantages too.
  • Clearly separating common user interface logic into view models enhances readability and maintainability by making it easier to distinguish between common user interface behavior and platform-specific nuances.
  • Keeping user interface logic in view models improves testability compared to keeping it in controllers because testing the later needs view mocks while the former does not.


Taking the best advantage of this design requires adherence to few disciplines.
  • Since the view models are to be shared between the implementations for two platforms it is necessary to limit the use of framework classes inside view model code only to the common ones between Cocoa and Cocoa Touch. Our use of the design in practical projects proves that this is not a prohibitive limitation since all platform-specific code usually lands in either views or controllers.
  • When there is a need for binding a view to a bunch of data members in a model object, it is advisable to expose the model object through the view model (using composition) rather than implementing proxy data members inside the view model. Later approach would generate lot of overhead to keep data members in view model and their counterparts inside model object in sync.


View models generally sound alien to Objective C world. However, our experimentation with the design explained above yielded clear evidence that view models, once employed in combination with MVC in architectures for products targeting both OS X and iOS, carry enormous potential to boost code reuse in addition to several other advantages. We tested it in a product that was developed for both Mac and iPad. We believe that it will serve as a generic design pattern for similar cases.

Wednesday, March 6, 2013

Are you stupid enough to be a leader?



What does it really take to become a leader? To be a celebrated figure like a king, president, mayor, CEO? I claim the bottom line is that the character needs to be dumb or ignorant enough to withstand the stupid duties and rituals that a regular leader has to perform. I rate stupidity above all other characteristics of a great leader. Are you skeptical? Look around and you’ll see. Don’t be judgmental though.  I got two strong examples to convince you. First one is from Hollywood, which I partly steal from one of Slavoj Zizek’s lectures. Second one (the better one) is from Sri Lanka and is entirely mine.

King’s Speech
The movie unveils the story of King George VI of Britain who assumed throne at the time of World War II. However, he had a terrific problem; a stammer. Because of that he was unable to address the nation strongly in a way that a king is supposed to. This was frustrating for the entire nation, as the British needed a strong spiritual leadership more than ever before. On one side, Hitler was attracting masses through his hypnotic speeches, while on the other side British had a king who could not utter five words in sequence.

British royal family made all attempts to cure king’s stammer. All top qualified speech therapists failed in developing his speaking abilities to a satisfactory level. Driven by frustration, the queen decides to bring her husband to an unorthodox (and unqualified) Australian therapist, Lionel Logue, who uses weird techniques to bring speaking abilities to people who struggle with it. Although he is not very well qualified for the job Lionel has achieved remarkable success with the experience in helping people who lost speech because of traumatic experiences during World War I. After diagnosing king’s problem, he makes a radical judgment. His conclusion is that King George VI is too intelligent to be a king. The king has to suppress his intelligence to cope with the stupid duties he gets as a king, and the suppression returns in subconscious to cause stammer.

Lionel sees only two options available for the king.
1     1. To be intelligent so keeping the stammer
2     2. Kill his intelligence to become stupid like other kings and gain speaking ability

Hitler had already invaded France and from the Eastern front had penetrated Russia to a great deal. It was a time to worry about the future of entire Europe; not about a single person’s intellectual fidelity. So Lionel decides to go ahead with the second option. Through a series of utterly stupid exercises he manages to slowly make the king blunt. In a seen towards the end of the movie, Lionel sits on king’s seat in Westminster Abbey. The king loses his cool and yells Lionel to get out of it, to be asked back “Why?”. King responds asserting that the seat belongs only to him by the divine law of British monarchy. This brings a grim into Lionel’s face as he learns that the king is now stupid enough to believe on that crap. His therapy is apparently successful. King starts to speak relatively well and you know the result of World War II.  

Subha & Yasa
This is a classic from Sri Lankan history. It’s about a king (Yasa) and his lookalike Subha (security guard in the palace). To fool ministers and the rest of the elite, Subha and Yasa used to exchange their costumes and thereby the identity. Then they made fun watching high ranked guys greeting the security guard in the guise of king. On one day Subha decided to exploit this joke and insisted that he is the real king. When the stupid (real) king opposed he ordered him being killed. This is the version in “Mahavansaya” (mainstream book that narrates Sri Lankan history) and is only good enough as bead time reading for children (isn’t it?). However, the renowned Sinhala author Simon Nawagattegama came up with a beautiful interpretation in his stage drama named “Subha & Yasa”. Here is his version (more accurately, my interpretation on his version).

Yasalalakathissa (Yasa in short) is not happy about the crown he inherited. His problem is same as that of King George VI; he is too intelligent to be a king. He precisely knows that ministers are lying to him and the entire palace is a mega-fake built for his gaze. It annoys him when ‘vandibhattayas’ are singing ‘prashasthi’ (In Sri Lanka vandibhattayas are people who sing to the king songs that admire him, to make a living. These songs are called prashasthi. This is a tradition in the country from ancient times and is still practiced today). Yasa wants to get out of this mess and live a free life. However, leaving the crown is not that easy. People would recognize him and would bring him back to the palace. He spares his day and night thinking about a way out.

One day king Yasa hears a conversation happening in the palace garden. It is between a bunch of people engaged in garden work. The king secretly comes closer to be surprised that one guy among them looks exactly like him. By listening to the conversation he learns that the guy’s name is Subha. He is telling a story to his friends. It’s about his angelic wife and the wonderful life he is sharing with her. The woman is totally devoted to Subha and does everything to make him happy. She cooks best food in the world and never badmouths him. Above all she never cheats him. Subha ascribes every bit of happiness in his life to her. She brings meaning to his life.

Listening to this, Yasa gets surprised for the second time. Having lived with dozens of women in the palace he exactly knows that every woman is dishonest and deceitful. With a little bit of jealous towards the guy who enjoys a precious gift in life that the king himself doesn’t possess, Yasa decides to check it. The king manages to find Subha’s whereabouts and visits his home while being dressed like him when the wife is alone. The wife welcomes the man who is ostensibly her husband. She makes him sit comfortably, treats him with delicious food, pampers him with a gentle massage and so on. Yasa now turns really envious about Subha. He was true; this woman is an angel.

When the woman’s love drama intensifies Yasa starts feeling guilty. He yells: “Lady, stop! I’m not your husband. I’m the king of this country”. The next moment…………………king is shocked to see that the woman is not shocked. She whispers: “My lord, from the very first moment I knew it. You shook my feelings with your adorable body. I’m mesmerized by your greatness. I’m all yours”.  Loving a king is more beneficial than loving a peasant, isn’t it? Women are generally more materialistic than men.
Being an intelligent guy, Yasa quickly switches his thinking channel from right brain to left brain. His immediate analysis puts him in pleasure due to two reasons.
1. His judgment about women still holds true
2. He has just found an idiot who is suitable for kingship. Subha, who bases his entire life on this dishonest woman, should be a great candidate to be the king.
After this, Yasa himself becomes the mastermind of a conspiracy to deceive the entire nation to believe Subha as the king. Subha is crowned and Yasa finds the free life he ever wanted.


Dear reader, have I convinced you enough on my initial assertion? Are you already a leader? Then, congratulations. More importantly, what about those of you who are not leaders yet? You don’t need to worry, because not being a leader indicates that you still got brains. Now you confront two options. Like in King’s Speech make yourself stupid enough so that you qualify as a leader. Alternatively you can decide to continue to be intelligent, like in Subha & Yasa, while ruining all the chances of being a leader.