Radeef sort – C code

// Please let me know better way to publish code in WordPress

 

// Radeef sort is useful in sorting an anthology of Ghazals, where the last word(s) of each couplet remain(s) same. Such word(s) is/are called Radeef

// Here is crude code of Radeef sort – sorting starting with last character, coming forward

// In essence, Radeef sort of an array of strings is “invert strings, sort, invert them again”

 

// Present program has many limitations. The goal is to just give an idea

// Most code here is copied from public domain – just Radeef sort idea remains original

 

// Example Input File:

/*

Geo
Duo
Jungle
Jingle
Support
By
Fantastic

*/

// after Radeef sort becomes

/*

Fantastic
Jingle
Jungle
Geo
Duo
Support
By

*/

 

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#define MAX_LINE 80

FILE * Fopen (char *name, char *mode) {
FILE *fp;
fp = fopen(name, mode);
if ( fp == NULL ) {
fprintf( stderr, “%p\tCan’t open %s\n”, fp, mode);
exit (1);
}
return fp;
}

void strings_sort (int lineCount, char names[][MAX_LINE]) {
int i, j;
char word[MAX_LINE];

for(i=0;i< lineCount;i++) {
for(j=i+1;j< lineCount;j++){
if(strcmp(names[i],names[j])>0){
strcpy(word,names[i]);
strcpy(names[i],names[j]);
strcpy(names[j],word);
}
}
}
}

int main(int argc, char *argv[])
{

FILE *inFile, *outFile;
int lineCount;
int inputError;
char word [MAX_LINE];
int i,j;

if ( argc < 3 ) {
fprintf( stderr, “usage: radeefsort inputfile outputfile\n” );
system(“PAUSE”);
return (1);
}

// read a file containing strings and store it in an array of strings
// invert strings in that array of strings

inFile = Fopen (argv[1], “r”);

lineCount = 0;
while(inputError != EOF) {
inputError = fscanf(inFile, “%s\n”, word);
lineCount++;
}
fclose(inFile);
lineCount–;
// Above iterates lineCount++ after the EOF to allow for an array
// that matches the line numbers

char names[lineCount][MAX_LINE];

inFile = Fopen (argv[1], “r”);
for(i = 0; i < lineCount; i++) {
fscanf(inFile, “%s”, names[i]);
strcpy (names[i], strrev(names[i]));
}
fclose(inFile);

// sort this array of strings
strings_sort (lineCount, names);

// invert strings in that array of strings
// output that array of strings into a file
outFile = Fopen(argv[2], “w+”);

for(i = 0; i < lineCount; i++) {
fprintf (outFile, “%s\n”, strrev(names[i]));
}
fclose (outFile);
}

As the presentation of an idea gets exact, it gets dull and bore

Background: My roots are in Hindu intellectual class. Along with many other intellectual pursuits, I also write poetry.

Today I am writing about representation of ideas and associated boredom.

Often I think that human race has got representation of ideas in reverse order.

***

Take for example the time it took to reach to prose composition.

Structurally speaking prose is simpler than poetry. There are no meters or rhymes to worry about.

Yet, earliest poetry dates back to Rig Veda but fictional prose is recent.

Why did this happen? There could be many reasons. I can think of a handful of them – and you may please add more:

  1. Exactness – In general, prose is capable of communicating ideas more exactly than a poetry. That also means prose is more “bore” than poetry. A poet can escape without detailing or leaving ambiguity. While ambiguity is pretty much a beauty of poetry, it is nearly undesirable in prose
  2. Aesthetics – Poetry, especially metered one, could be sung and accompanied by music. Prose (and a lot of modern poetry) can’t be. Thus, poetry could find more royal patronage
  3. Memorization – This one is important from civilization point of view. Our brain can recite hundreds of lines of poetry without fault, in a pseudo-familiar language. I bet even I can’t recite this one point written in prose, written by me, without fault
  4. Learning – As readers of this blog are aware, I am a human language enthusiast. My friends try to teach me their language (Telugu, Kannada, Sanskrit and Tamil) through grammatical structures. I insist on learning songs first. “Songs? Lullabies? Rhymes? You WON’T understand a thing in them! It is hard to understand a normal sentence in my language for you today!” they say. But once they agree on teaching me songs, they are amazed at the speed poetry and music combo get into my – and other by-standers’ brain

But look at the other side of it.

Writing poetry is a non-trivial challenge. Suppose the very same idea here has to presented in meters, I can’t compose it in-between two meetings like this paragraph.

Composition of poetry is so difficult, I could compose a few hundred poems in my mother tongue, Gujarati but I have composed very few in Hindi (my second language) and none in English (my third language).

Contrast this with my prose activity. This blog is running in English, or something that resembles English. You can understand this representation without much difficulty. You will find me joking in languages that I don’t know fully – or even I don’t completely understand – Gujarati, Hindi, English, Urdu, Telugu, Sanskrit, Kannada, Punjabi, Marathi, Bengali, Farsi, …

That means, ideas are easier to communicate in prose. Exactness is higher.

***

Then take a step forward from prose to accounts and tables.

My father, who is a humorist and an essayist, and hence a master prose writer, once claimed “I don’t like writing tables and counting cells like a clerk.”

That means tables are a step farther drier than prose.

While non-fiction prose like trade agreements and treaties existed for a long time, table making activity was limited to account books and astronomy.

It was not until Renaissance and scientific revolution that accountancy, double-entry accounting systems, logarithm tables, statistics, periodic table in chemistry and astronomy catalog came into being. Later, interestingly, spreadsheets were the reason why Graphical User Interface (GUI) became so popular!

But look at the advantage of written structured records!

Tables and numbers speak so loud, it is impossible to ignore them. Rather, tables come biting you!

Take for example, my body-building activity. For progressing fast for nearly one and a half year, my weight-lifting seemed stagnated. Last month, I got an idea. I bought an attendance register for INR 30/- and wrote down all exercises I carry out against a triplet of (weight, repetitions, sets). My gym instructor was laughing at this pedantic way of taking records. But to his surprise, he realized that he kept forgetting my last benchmark weight lift 30% of time! After the introduction of the register, my progress is both – fast and assured. Just within two rounds, some of my muscles are lifting 20 kg instead of 10 kg! Tables speak VERY LOUD.

The register looks very bore when compared to my prose resolution, though! :-(

My resolution is very colorful: “I hereby resolve to be able to lift my wife on my biceps and lats, do a hand-standing and carry out 20 pull-ups by Valentine’s day 2016.”

***

Let me digress a little:

Students of mathematics would associate a table with a graph, and hence a tree.

Trees were limited to genealogy in past. The next famous example in my mind is directly taxonomy of life forms.

***

Now compare the challenge of writing a prose post versus writing a table. I can probably summarize the whole post as:

Boredom, Exactness

==============

Poetry

Prose

Tables

Equations

Programming, Structured

Programming, Object Oriented

***

Let me digress a little again!

Tables usually and accounting invariably refer to “continuous and evenly flowing time”.

If you look carefully, We Hindus have often failed at keeping exact prose record of events (history) against continuously and evenly flowing time. There are genealogies and tables in our civilization but China and West can beat us by miles! Radical Islamist thinkers even derides Hindu history as “dateless history of Brahmins”. Shamefully speaking, we Hindus have more calendars and more ways of measuring time than probably the whole world put together. There are panchangas and meetis and half a dozen new years in a normal year!

Modern calendars are far from being exact or convenient or logical. However, non-receding, non-jumping nature of time (absence of vRuddhis and kShayas) and absence of ambiguity and numbers (like shukla and kRuShNa pakShas) is definitely more exact – and more bore.

***

Coming to back to the track, prose is beaten by yet another presentation – equations.

Mathematics, and hence physics and engineering has been very precise. So precise that you entrust your life to it by sleeping under a roof in the night!

The power lies in equations!

I remember one of my lessons in “History of Scientific Ideas” taught at IIT Kanpur. Being able to express geometry, rate and accumulation as equations was hailed as cornerstones in the history of science.

Then Gauss and others could express the gist of tables in form of statistical equations.

My financial adviser was observing the other day: “I don’t know how my son who is a mechanical engineering student, can stare at those equations for hours together! I often tell him to go out and get some life!”. Then he turned pages of Insurance Rate table with great interest. My father chuckled. My grandmother, a poetess, might have laughed from the heaven at both!

That is one more step to boredom and exactness, isn’t it?

***

Then I remember my mathematician neighbor in Hyderabad, Dr. C.N. Kaul. He was fascinated at computer science but didn’t exactly like programming. According to him it was detailing.

Let me drag equations to physics for an example. Aren’t Maxwell’s equations beautiful?

But what about a program simulating Maxwell’s equations?

Between (analog) equations and (digital) programs, the balance of exactness tilts back to (analog) equations.

Still, that very detailing of equations called a program, in which

  • limits to an integration (or a curl)
  • instruction to integrate (or to curl)
  • the function to integrate (or to curl) and
  • the specification of the variables on which to integrate (or to curl)

ALL appear in a single line is very dull, very bore – and VERY productive. Even machines can manipulate such boredom!

***

And at last, some of my C programming friends don’t like Object Oriented programming.

Object Oriented programming is “bore” as per them.

Yes, it is bore. It represents the computation in the language of the problem domain. It is less succinct than and looks less elegant than a small, clever program of prolog (and a nicely written mathematical equation, a nice table, this paragraph and a haiku).

But then look at the generality it addresses! If a class is defined in one way, that the end of the world for its behavior! That exactness leads to the boredom of presentation.

Correct my following understanding please:

Mathematics had to be expanded to Type Theory to solve Russel’s paradox. Object Oriented Programming has roots in Type Theory.

***

For sure in above line of arguments, a lot of claims are unsupported, unproven, biased and/or plainly wrong or misleading.

For example, someone once told me that symbolic mathematics can’t be carried out using Object Oriented Programming.

Also, I understand somewhere the narrative is probably misleading the reader that “detailed is bore” and then breaks down between prose and tables.

I request you to criticize this post with rigor and give me counter-examples.

In the meanwhile, I need to write a poem for my wife, who is angry on me for not clearly communicating our vacation plan.

No class, no program, no equation, no tables and trees, no paragraph will work instead! :-(

About delay, loss, fuzz and unfortunate events

I covered importance of testing the impact of delayed response earlier.

It is also important to test for lost responses to see how queuing up impacts the application/device under test.

Semantically confusing fields in networking data (like http://192.168.1.255 over a 255.225.255.0 LAN) should be tested to avoid gaffes and towards more secure code. Protocol fuzz testing should ideally cover such tests.

At last, there is also a possibility of events related to other protocols happening at unfortunate events. How does your system behave when route summary is happening from OSPF to BGP AND an OSPF update arrives? Testing such scenario is extremely difficult for the want of right set of tools and skills. It also unleashes combinatorial nightmare for testing. However, with careful “code baking” policy, it is possible to find strange, bad and nasty bugs before customers find them in the field.

Urgent and Important of Test Failures

Not all test failures are alike. Some should be addressed urgently and some are important to address.

Interestingly, these two sets are DISJOINT.

That is, if a test failure should be tested urgently, it is seldom important. Those that should be fixed at any cost are seldom urgent (unless the team has really slacked).

How to determine which failure falls into which category?

Naturally, easiest to fix failures must be fixed urgently before the code moves too much.

On the other hand, if a failure is long standing, obviously a feature is broken and it is important to fix it.

As if the failure signal has to pass through filters, the outcome of an high pass filter will be urgent and the outcome of a low pass filter will be important.

A bug’s Afterlife

The question is similar to a question Nachiketa asked to Yama, the god of death. “What happens to the soul after death?”

The answer is: “None cares. It is just there till someone digs out a bug to prove a point on someone.”

And that is why Quality doesn’t improve.

Even the famous state transition diagram of Bugzilla doesn’t address one crucial point – there IS an afterlife of a bug! As a matter of fact, a bug may have many afterlives.

  1. Afterlife #1: A bug filed by a support/escalation engineer, found at a customer site
    1.  The purpose of such a fix is to work at the customer site, right? So conscientious QA keeps the bug in “Resolved” or “Verified” state and marks it as “To be Verified at the Customer Site” or similar phrase. It is the duty of the support engineer dealing with the customer to actually verify and close it
    2. Fixing a bug reported from a customer is often not sufficient. It is also advised to go out and declare that a defect has been addressed. This means Documentation team has to take notice of such a bug and include it in the next version documentation. So a clone of this bug must be assigned to the Documentation team
    3. Such a clone needs to be verified too, right? Typically a QA verifies such a documentation bug and closes it
  2. Afterlife #2: A “good” bug found by anyone
    1. Depending on the nature of the bug, the scenario may turn into a valid test case. So such a bug must be cloned as an assignment to a QA engineer to convert into at least one test case
    2. Such a test case needs to be verified and closed by QA too
  3. Afterlife #3: A “good” bug that has turned into a test case
    1. A valid test case is likely to get converted into a test script. So a bug may also clone for assignment to a test automation engineer
    2. Such automation needs to be verified by QA too

Here, cloning isn’t the only option but because a bug may split multiple ways – customer support, QA, automation and documentation, it is best to clone the bug and let each department worry about its further life cycles.

This is one of the reasons I disagree with ignorant non-QA (and also ignorant QA) folks who claim: “QA’s job is to find bugs”.

What do you say?

Sources of inspiration for test cases

AFAIK, SWE maintains that tests are derived from (Marketing/System/Software) Requirement Specifications – and that is the end.

If it were so, I am sure purists of Software Engineering would agree to my observation.

I have derived meaningful test cases from at least these sources:

  1. (Marketing/System/Software) Requirement Specifications
  2. Bugs reported from the field (escalations)
  3. Questions asked in mail groups for (System Engineers/Subject Matter Experts/Beta customers)
  4. Knowledge Base articles written for Customer Support Engineers
  5. Test Automation Scripts
  6. White papers from marketing – and competitor’s marketing

Where else have you got inspiration?

Common Areas of Improvement in Test Cases

  1. Necessity (Non-triviality) – a lot of times, a test case isn’t necessary anymore. A broad use case testing may cover a lot of test cases. Delete such “small step” test cases. It will reduce testing, reporting and automation overheads
  2. Necessity (Non-redundancy) -
    1. Careless testers write such tests. “Who cares if there already exists such a test?”
    2. Similar or even identical test steps across test cases
    3. This leads to wrong estimate of efforts and increase test case maintenance work
  3. Clarity of Name -
    1. Government official type tester tend to write such tests – all the information you asked for in as unfriendly way as possible
    2. “Test case #1020234″ is NOT a good name
    3. The name must be descriptive of what is being tested or your developer will never review the test
  4. Loop Unrolling -
    1. Programmer type tester tend to write such tests – they will have “if”s and “for”s
    2. “Test the following for the Sun, the Moon and all the stars in the universe”
    3. This is BAD from test effort estimation and fault reporting. A test case failed must report a bug – and block testing
  5. Clarity of Steps -
    1. Poets type testers tend to write such tests – This inverse of “Clarity of Name” – If your words are short and sweet\ You should not test but tweet
    2. “Test the module” – is a real test case step description from a lot of test databases
    3. A lot of time, there are one-liner tests and a lot is left on the imagination of the tester
    4. Such tests create freedom of testing loaded with confusion and inability to reproduce the bug
  6. Clarity of Expected Results -
    1. Dictator type testers tend to write such tests – not telling you why
    2. “Follow all these steps” … and never ask why
    3. A test is a Boolean hypothesis – and under iron heels of the test mandate, peppered with ridicule of the person asking the question “why?”, Boolean nature of the test goes for a toss. Anything can be concluded – and confused as a result
  7. Atomicity of Result -
    1. Religious type testers tend to write such tests – trying to help your this world and next
    2. “Make sure you can download the music file, see cartoons rolling and feel the phone vibrating”
    3. When anything fails, communication about what failed becomes very confusing
  8. Presentation and Readability -
    1. Lawyers and lawmaker type testers tend to write such tests – Writers of such tests consider text as a means of exercising power on lesser mortals
    2. “Then go to the management console and click on the longest possible link. And assure that premium paid gets displayed” instead of …
    3. “Management Console: Click on the longest possible link”; “Expected Result: End user display: Message ‘Premium Paid’ gets displayed”
    4. Such tests are a pain to the tester who reads steps with a hope to
  9. Sufficiency -
    1. This type of tests are written under a manager who insists on getting certain number of tests written
    2. Such tests don’t cover the feature enough – for example, it will advise you to test that a configuration is persistent through failing over from node A to B but will not ask you to modify the configuration again and then failing over from node B to node A
    3. Such test cases are big waste of time and give false confidence in testing
  10. Generality -
    1. Historian type of testers tend to write such tests – they state that roads were built in Rome, and stop their statement there
    2. “Step 5: Load Firefox version 2.0.2″ – is this test applicable in any other Firefox?
    3. Such test cases blur the line between a generic test and a specific test. We need specific tests also to test legacy support
  11. Release Information -
    1. History challenged testers tend to write such tests – they assume because a feature is introduced today in this branch, it will magically appear in older branch
    2. “Test this feature” [Notice the absence of information on 'applicable to releases branched with or after x']
    3. When multiple parallel releases are to be tested and there is a feature absent in older tests, it skews testing effort estimate AND if an inexperienced manpower is testing it, time is wasted in an FAD bug
  12. Third Party Dependence Information -
    1. Tunneled vision testers tend to write such tests – they never know the feature they are testing is dependent on the environment, like the browser
    2. “Test this feature” [Notice the absence of information on 'will unleash a nightmare of compatibility if Firefox updates']
    3. Test Automation team needs this vital information. Tunneled vision tester miss this key part and Automation team makes fatal mistakes in designing supporting libraries
  13. Third Party Specificity Information -
    1. Jailed testers tend to write such tests – they never know the test they carry out is specific to long term assignment of an environment they have been jailed to – like an operating system or a browser
    2. “Test this feature” [Notice the absence of information 'on Chrome only']
    3. Apart from skewing test effort estimate and confusing the heck out of Automation design, this type of test cases in hands of inexperienced hands increase FAD bugs
  14. Priority -
    1. Insecure testers forget to mark a bug with appropriate priority and mark everything “smoke test” – or careless testers leave it to the default “medium” priority
    2. Statistically very high percentage of one type of priority
    3. Nothing hurts testing effort estimate more than this – too high a priority and you waste time, too low a priority and you miss bugs
  15. Placement of the Test Case in Test Database -
    1. Right brain, artistic testers tend to misplace their test cases
    2. “I wrote it right under the release x folder. Why should it be under a feature based hierarchy?” – and let me remind you, this isn’t the only way of misplacing a test case
    3. Such misplacement has two problems – it skews test effort estimation AND it increases probability of missing that test case when related regression testing needs to be carried out
  16. Independence from Other Test Cases -
    1. Such testers can tell you a story but can not tell you a joke. They have problem making a clean cut. They sure have trouble understanding why RDBMS insisted on having independent records. Such testers are also fond of brevity at the cost of confusion
    2. “After previous test case, execute the following steps”
    3. Test Cases may change, move or get deleted. Because previous test case has moved or got deleted or even changed, this test case may lose ALL its meaning
  17. Reviewer information -
    1. Testers that miss to mention reviewers are scientifically challenged. They don’t understand tremendous value peer review adds
    2. Typically reviewer information is missing or reviewer name is the same as the writer
    3. Even if the reviewer is a complete moron, questions from a different brain are worth answering
  18. Coverage -
    1. This typically an oversight over long time
    2. A product grows in features and cross-coupling of features goes unnoticed
    3. Missing coverage ends up in having bad quality