Reference no: EM132148073

ASSIGN MENT - GENETIC ALGORITHM

In this assignment, you will use your C programming skills to build a simple Genetic Algorithm.

DESCRIPTION OF THE PROGRAM -

CORE REQUIREMENTS -

REQ1: Command-line arguments

The user of your program must be able to execute it by passing in the following arguments:

./ga geneType alleleSize popSize numGen inputFile [outputFile]

The main program must verify the number of command-line arguments is as expected and ensure they can be converted to valid types and values.

REQ2: Loading the vector input data file

Your program needs to load into memory the data from the input data file specified in the command-line argument. You will need to tokenise this data before you can load it into the system. In this requirement, you can assume the specified input file is completely valid. Dealing with invalid input files is covered in a separate section of the assignment.

You will need to use the InVTable structure defined in the start-up code to store your input data. The input data is organised as a series of input vectors, one per line. The syntax of a line is:

InputVector:vector-number(vector-element1,vector-element2....vector-elementN)

REQ3: Implementing and calling function test_minfn

Function test_minfn() tests the operation of functions gene_create_rand_gene, mutate_minfn, crossover_minfn, gene_print and gene_free. function test_minfn() is only compiled and called if macro DEBUG is defined. The start-up code includes a description of the function calls necessary to implement test_minfn().

Functions mutate_minfn, crossover_minfn and gene_print also use conditional compilation, including debug statements if macro DEBUG is defined. In particular, if DEBUG is defined:

mutate_minfn will use a mutation point of chromosome index 2

crossover_minfn will use a crossover point of chromosome index 2

REQ4: Implementing and calling function test_pcbmill

Function test_pcbmill() tests the operation of functions gene_create_rand_gene, mutate_pcbmill, crossover_pcbmill, gene_print and gene_free. function test_pcbmill() is only compiled and called if macro DEBUG is defined. The start-up code includes a description of the function calls necessary to implement test_pcbmill().

Functions mutate_pcbmill, crossover_pcbmill and gene_print also use conditional compilation, including debug statements if macro DEBUG is defined. In particular, if DEBUG is defined:

mutate_pcbmill will use a mutation points of chromosome indexes 2 and 4

crossover_pcbmill will use a crossover point of chromosome indexes 2 and 4

REQ5: Conditional compilation

Functions test_minfn and test_pcbmill should only be compiled and called if the macro DEBUG has been defined. Debug statements in functions mutate_pcbmill, mutate_minfn, crossover_pcbmill and crossover_minfn should also be compiled only when the macro DEBUG has been defined. This macro should be defined when the user calls make with the argument DEBUG.

REQ6: Makefile

We should be able to compile your program using a makefile, which should be submitted along with the code of your assignment. All compile commands must include the "-ansi -Wall - pedantic" compile options. You program should compile cleanly with these options; no error or warning is acceptable even during the demo.

Your makefile must compile your program incrementally. That is, it should use object files as an intermediate form of compilation.

Your makefile should permit the defining of macro DEBUG from the command line, for use in conditional compilation of test_pcbmill() and test_minfn().

You should also include a target called "clean" that deletes unnecessary files from your working directory such as object files, executable files, core dump files etc. This directive should only be executed when the user types "make clean" at the command prompt.

REQ7: Implementing and calling pop_print_fittest

Function pop_print_fittest should be called each time a population has been evaluated and ready for reproduction. It should cause the the 'fittest' gene in the population to be displayed, along with the number of the current generation. As specified in the start-up code, the function must not be able to access any generation value outside of the function.

REQ8: Evolution of the population

The program should correctly create an appropriate initial population and 'evolve' it for a specified number of generations, where each generation is evaluated and reproduced to create the next generation, displaying details of the fittest gene of each generation as described above.

REQ9: Implementation of function pointers

The Pop_list data type has three pointers to functions:

create_rand_chrom which can be set to point to a function for creating a random chromosome. Prototypes for two such functions have been provided: create_pcbmill_chrom for creating a valid pcbmill chromosome, and create_minfn_chrom for creating a valid minfn chromosome.

mutate_gene which can be set to point to a function for mutating a gene. Prototypes for two such functions have been provided: mutate_pcbmill for mutating a pcbmill gene, and mutate_minfn for mutating a minfn gene.

crossover_genes which can be set to point to a function for performing crossover on two genes. Prototypes for two such functions have been provided: crossover_pcbmill for performing crossover on pcbmill genes, and crossover_minfn for performing crossover on minfn genes.

evaluate_fn which can be set to point to a function for evaluating the raw fitness of a gene. Prototypes for two such functions have been provided: eval_pcbmill for evaluating a pcbmill gene, and eval_minfn for evaluating a minfn gene.

Your program should appropriately set and use these functions pointers.

REQ10: Validating the input file

In the previous requirements, it was assumed that the input vector data file that you have loaded into memory were valid and contained no error. However, in real life this is not necessarily the case and you will be required to detect errors that may arise from reading a corrupt or invalid data file.

REQ11: Producing the output file

If command-line argument outputFile is provided, a file with the same name as the argument should be created/truncated to zero length and all output directed to the file.

REQ12: Memory leaks and abuses

The start-up code requires the use of dynamic memory allocation. Therefore, you will need to check that your program does not contain memory leaks. Use the following valgrind command to check for memory leaks on problem minfn with a population 20 run for 50 generations and submit the report in a text file named Requirement11a.txt along with the rest of the files in your project.

REQ13: Abstract Data Types

In this assignment, you are implementing three Abstract Data Types; gene, population and InVTable. A number of function prototypes for gene have been provided, but the interface for the population and the InVTable are largely for you to develop. For this requirement, you will need to propose a list of interface functions for the population and InVTable ADTs and implement these. All references to these types should be via these interface functions.

REQ14: General requirements

You must read and follow the "Buffer Handling", "Input Validation" and "Coding Conventions and Practices" requirements written in the "General Requirements" section of this specification.

REQ15: Demo

A demonstration is required for this assignment in order to show your progress. This will occur in your scheduled lab classes on the Unix machines used in this course. Demonstrations will be very brief, and you must be ready to demonstrate your work in a two-minute period when it is your turn. You must also have already uploaded your files to the assignment 2 submission link as proof of your work.

As part of the assignment demo, the tutor may ask you random questions about your source code. You may be asked to open your source files and explain the operation of a randomly picked section. In the event that you will not be able to answer the questions, we will have to make sure that you are the genuine author of the program.

Input validation will not be assessed during demonstrations, so you are advised to incorporate these only after you have implemented the demonstration requirements. Coding conventions and practices too will not be scrutinised, but it is recommended that you adhere to such requirements at all times.

During the demonstration you will be marked for implementing the requirements REQ3, REQ4 and REQ5 which should be completed and functional.

GENERAL REQUIREMENTS -

GR1: Buffer handling

Your program must not suffer from buffer overflow if input is larger than expected.

GR2: Coding conventions and practices

Marks are awarded for good coding conventions/practices such as:

Completing the header comment sections in each source file included in the submission. Avoiding global variables. If you still do not know what global variables are, do not assume. Ask the teaching team about it. Avoiding goto statements.

Consistent use of spaces or tabs for indentation. Either consistently use tabs or three spaces for indentation. Be careful not to mix tabs and spaces. Each "block" of code should be indented one level.

Keeping line lengths of code to a reasonable maximum such that they fit into 80 columns.

Appropriate commenting to explain non-trivial sections of the code. Writing header descriptions for all functions.

Appropriate identifier names.

Avoiding magic numbers (remember, it is not only about numbers). Avoiding platform specific code with system().

General code readability.

GR3: Functional abstraction

We encourage the use of functional abstraction throughout your code. This is considered to be a good practice when developing software with multiple benefits. Abstracting code into separate functions reduces the possibility of bugs in your project, simplifies programming logic and make the debugging less complicated. We will look for some evidence of functional abstraction throughout your code.

As a rule, if you notice that you have the same or very similar block of code in two different locations of your source, you can abstract this into a separate function. Another easy rule is that you should not have functions with more than approximately 50 lines of code. If you have noticeably longer functions, you are expected to break that function into multiple logical parts and create new functions accordingly.

Attachment:- Assignemnt File.rar