1 / 24

Fundamentals of Computational Science CISC 810

In this lecture, Dr. Rob Thacker provides an overview of C/Fortran programming, including a review of assignment 1 and the solutions. He also discusses the history and idiosyncrasies of FORTRAN, coding style, naming conventions, good practices, and the importance of commenting.

ahner
Download Presentation

Fundamentals of Computational Science CISC 810

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Fundamentals of Computational Science CISC 810 Dr Rob Thacker Dept of Physics (308A) thacker@physics

  2. Today’s Lecture • Review of assignment 1 • C/Fortran programming overview

  3. Assignment 1 solutions • Printed copies will be handed out on Oct 13 • An electronic version will not be made available

  4. Humour – more FORTRAN jokes • Joke, circa 1980 (following the standardization of FORTRAN 77): "Q: What will the scientific programming language of the year 2000 look like?” “... A: Nobody knows, but its name will be FORTRAN." • “Consistently separating words by spaces became a general custom about the tenth century A. D., and lasted until about 1957, when FORTRAN abandoned the practice." • —Sun FORTRAN Reference Manual • “FORTRAN, the infantile disorder, by now nearly 20 years old, is hopelessly inadequate for whatever computer application you have in mind today: it is now too clumsy, too risky, and too expensive to use.” • Edsger W. Dijkstra, circa 1970.

  5. A note on these programming lectures • In two lectures I can’t possibly tell you all these is to know about C/FORTRAN programming • You learn programming by doing • Sit down at a terminal and write a program • Then a more complicated program and so on… • Please be prepared to look up additional material on the web • If you have not done any programming in C/FORTRAN before don’t be intimidated • It isn’t hard (C just looks harder because of the “strange” syntax) • I’ll try and teach them together where possible, this may mean being convoluted in some places

  6. Style • When reading and writing code, you have to keep a bunch of facts straight for a short period of time • What do this function's parameters mean? • What does this loop's index refer to? • The more odds and ends readers have to keep track of, the more errors they will make • Goal of style rules is therefore to reduce the number of things the reader has to juggle mentally • The greater a difference is, the more likely we are to notice it • So every semantic difference ought to be visually distinct… • …and every difference in naming or layout ought to mean something • Most important thing is to be consistent • Anything consistent is readable after a while • Just watch kids learning to read French, Punjabi, and Korean

  7. C/FORTRAN issues • Remember: • C is case sensitive: HELP is not the same as help • FORTRAN isn’t • FORTRAN coding style is idiosyncratic • f77 standard requires you keep line lengths to 72 characters(!) • Must also start each line in the 7th column(!) • f90 repealed these issues • C is more syntatically sophisticated than FORTRAN • C requires you place a semi-colon at the end of each command line • Allows you to write very long single lines

  8. Naming • Names of files, classes, methods, variables, and other things are the most visible clue to purpose • A variable called temperature shouldn't be used to store the number of pottery shards found at a dig site • Choose names that are both meaningful and readable • current_surface_temperature_of_probe is meaningful, but not readable • cstp is easier to read, but hard to understand… • …and easy to confuse with ctsp • If you must abbreviate, be consistent • curr_ave_temp instead of current_average_temperature is OK… • …but only if no one else is using curnt_av_tmp • The smaller the scope of a name, the more compact it can be • It's OK to use i and j for indices in tightly-nested for loops • But not OK if the loop bodies are several pages long • Of course, they shouldn't be anyway… • The wider the scope of a name, the more descriptive it has to be

  9. Good practices

  10. Commenting • This is an extremely valuable part of any coding project • Don’t leave it out because you are lazy • Don’t think that your code “reads like a book” and that comments are unnecessary • Don’t ignore it because you don’t have time • Well placed and thought out comments… • Document the development of the code (in addition to any repository comments you make) • Help out from a functional perspective (you can have “To do” lists embedded within the code) • Explain code, functions and the control flow of the program

  11. /*************************************** *************************************** *** This really gets your attention *** *** use it for warning messages *** *************************************** ***************************************/ /*----> Another important message <----*/ /*************************************** * Use boxed comments at the start * * of code sections or the program * * * * Here we explain important details * * about the code and algorithm * ***************************************/ /* * A medium-level comment explaining the * next few lines of code. Can still use * * characters to **emphasize** words. */ /* This comment explains the next line */ ! *************************************** ! *************************************** ! *** This really gets your attention *** ! *** use it for warning messages *** ! *************************************** ! *************************************** ! ----> Another important message <---- ! *************************************** ! * Use boxed comments at the start * ! * of code sections or the program * ! * * ! * Here we explain important details * ! * about the code and algorithm * ! *************************************** ! ! A medium-level comment explaining the ! next few lines of code. Can still use ! * characters to **emphasize** words. ! ! This comment explains the next line Explanative comment hierarchy C FORTRAN If you use FORTRAN get into the habit of using ! for comments

  12. Good practice • At the beginning of each subroutine include a comment that describes each of the inputs • Do the same for functions • If multiple people are working on the same project add your initials to each comment • e.g. !rjt I added this code for a reason • If you borrow code from other projects make sure this is noted as well – helps others to track down bugs and gives credit where it is due

  13. Resist the temptation to be clever • Don’t worry that you don’t understand the details of the following code, the concepts should be clear • The following C example is unclear even to reasonable programmers: while (‘\n’, != *p++ = *q++); • It would have been much better to write this as while(1) { *dest_ptr = *source_ptr; if (*dest_ptr == ‘\n’) break; /* Exit loop if done */ dest_ptr++; source_ptr++; }

  14. C – either cc or gcc gcc is the GNU C compiler cc is frequently linked to gcc, but this is platform dependent the Intel C compiler is often denoted icc Usage: cc myfile.c –o myprog FORTRAN – many types f77 – usually links to FORTRAN 77 compiler f90 – usually links to FORTRAN 90 compiler gfortran – gnu fortran ifort – Intel compiler Usage: f77 myfile.f –o myprog Compiler command line names What is the difference between compilers? Speed. The Intel compilers are typically between 5 and 20% faster than the GNU compilers (but it varies).

  15. C #include <stdio.h> main() { printf(“Hello World! \n”); } Fortran program hello print *,”Hello World!” end Hello World Standard IO header New line character Indented into 7th column Semi-colon ends a statement No format is selected by * so just prints free form main is always the name of the first function to be executed. {} must enclose the code to be executed

  16. C headers • The #include forces the compiler to include the file stdio.h • It will find it by checking the linking path • Header files contain prototypes, which are abstract function definitions • stdio.h is by far the most common, however math.h contains many mathematical function definitions (log, trig etc) • Lots of headers available to, including time functions, string functions, exception handling …

  17. C int a; Can specify whether signed or unsigned Can also specify whether short (2 bytes) or long (8 bytes) float b; 4 byte floating-point double c; 8 byte floating-point FORTRAN integer a signed integer* real b floating-point* double precision c floating-point* with twice the precision real*4 4 byte floating-point real*8 8 byte floating-point complex 8 byte complex pair complex*16 16 byte complex pair Mathematical variable types *99 times out of 100, these correspond to 4 byte words for integer and real and an 8 byte word for double precision. Every now and again you may use a platform where the native words are 8 bytes

  18. C char a; a = ‘S’; Strings are created by declaring arrays of characters: e.g. char a[4]; FORTRAN character a a=“S” logical type is available but is essentially same as integer Strings are handle by a character type whose length you define e.g. character*4 a Character & non-numerical types

  19. C - example int data[3]; Indices run from 0 to 2 For multiple dimensions int data[3][2]; Fastest changing index in memory is the last one This is called Row-major order FORTRAN – example integer data(3) Indices run from 1 to 3 For multiple dimensions Integer data(3,2) Fastest changing index in memory is the first one This is called column major order Declaring Arrays This is a very important distinction!

  20. Avoid implicit variable definitions in FORTRAN • For economy, early versions of FORTRAN assumed if you did not declare a variable that • Variables beginning with i-n are assumed to be integer • Variables beginning with a-h, o-z are assumed to be real • Do NOT use this convention • If you don’t type a variable name correctly the machine creates a new variable for you – can create horrendous bugs • Add the statement “IMPLICIT NONE” to the beginning of your code • Forces you to declare all variable names • Same is true in F90 unfortunately • Thankfully C forces you to do this

  21. C int i; for (i=1; i<=10; i++) { printf(“Iteration %d\n”,i); } i++ means i=i+1 %d means print an integer Note the general loop structure for (initial statement; condition; iteration statement) { body } FORTRAN integer i do i=1,10 print*,”Iteration “,i end do Can also specify loop iteration: do i=1,10,2 Would increment in steps of 2 Loops

  22. FORTRAN 90 Array Syntax • Really useful feature for minimizing the length of vector operations • Suppose we wish to add two vectors of length 100 • Normally this would require a loop: do i=1,100 a(i)=b(i)+b(i) end do • Can replace this with a=b+c • You can also specify bounds for the operation • a(1:4)=b(1:4)+c(1:4) • Adds elements b(1)+c(1) through to b(4)+c(4)

  23. Pick a style and use it – it will pay off Comment your code – not excessively, but make sure it is clear and concise C requires you include header files Simple programs to try if you haven’t written any in C/FORTRAN before: Sum the first n numbers Sum up the values of a 2d grid of numbers where each grid entry a(i,j) is i*j Try doing this with a while loop that exits when the sum exceeds a given value Summary

  24. Next Lecture • more on C/Fortran programming

More Related