2016-09-01

Introduction

Programming Environment
Programming Languages
Plotting tools

Writing tools / Editing tools

Operating systems
Makefile

Programming basics

Procedure of programming
Condition of good codes

Precision and data-types

2016-09-01

Programming languages
Fortran 77, Fortran 90/95
Majority of physics codes and numerical libraries are written in Fortran.
Ansi-C
Simple and powerful

C-compilers : gcc, cc, icc,

C++
Good. Object-oriented-programming (OOP)

Compiler type

Interpreter type
Python
Easy but powerful. Free. O.K. in both Windows and Linux
Fast in script languages. Good plotting tools are included (Matplotlib). cf.) Anaconda
Matlab, Mathematica
Expensive but very powerful. Easy to use. Wonderful plotting tool included

In this course, Ansi-C will be used as an official language, but you are free to use other languages.
You are not allowed to use built-in numerical libraries of Python, Matlab, and Mathematica
except basic mathematical functions (sin, exp, log, sqrt, ).

1 excellent
2 good
3 fair
4 poor
Source : http://www.phy.ornl.gov/csep/CSEP/PL/PL.html

2016-09-01

Plotting tools
Gnuplot
Free. Linux & windows. Fast and powerful. Adequate for publication
Not easy to be familiar
Origin, SigmaPlot
Easy to use. Adequate for publication
Windows only. Expensive (But, do we have a license?)

Excel
Not recommended !!
Easy to use
Not free (GIST has (limited) license.). Windows only. NOT adequate for publication
Python
Free. Linux & windows. Easy to use
I dont know well, yet.

Matlab, Mathematica
Easy to use
Expensive (But, do we have a license?). I dont know well, yet.

Gnuplot

Entering : type-in gnuplot

Exiting : type-in quit, exit, or q
Help : type-in help or help [subject]
Examples : http://gnuplot.sourceforge.net/demo/

>> plot x
>> plot data.out u 1:2 w lp lw 2 pt 4 ps 2
>> pl data.dat u 1:2:3 w errorlines
>> se t po eps
>> se ou graph1.eps
>>
>>
>>
>>
>>
>>

se
se
se
se
se
se

xrange [0:20]
xtics 0,2,10
xlabel Temperature font Times-Roman, 30
logscale xy
size square
key left top

>> se multiplot
>> f(x) = A*x**3 + B*x + C
>> C = 2
>> fit f(x) data.1 u 1:2 via A,B,C

2016-09-01

Writing tools (for a report)

MS-Word / Powerpoint

LaTeX
Free. Very beautiful. Easy to change the format. Very convenient in citation.
Not easy to learn. (cf. overleaf.com)
HWP

Not recommended !!

Editing tools (for a text-file of a source code or a script)

vi
Free. Very fast. Installed in every linux. NOT Easy to learn and use
emacs, gedit, kwrite, kate,
Free. Easy to learn and use

Operating systems (OS)

LINUX
Free, reliable
Includes many free software (gcc, cc, g++, g77, gfortran, )
Not good in entertainment
Ubuntu : Very easy, Friendly, (Relatively) good for entertainment
CentOS : Free version of RedHat, Reliable, Not friendly
Fedora, OpenSUSE, Debian,
GUI : KDE, Gnome,
Windows
Visual C++, Boland C++,
Good GUI: Easy to learn. Too easy to learn programming

2016-09-01

Basics of Linux
Help : man (ex. > man ls)
Basic commands
ls, cp, mv, cd, rm, mkdir, rmdir, tar, gzip, which, ssh, sftp, su, passwd, alias,
cat, vi, head, tail, grep, diff,
Pipe & filter : <, >, >>, |
Import aliases
alias rm='rm -i'
alias mv='mv -i'
For bash
alias cp='cp -i'
System monitoring : whoami, free, top, w, ps, kill, df, du,

2016-09-01

Basics of Makefile
Make Makefile or makefile.

For beginners
CC = icc

Type-in make.
For exports

mv1 : mv1.o ran0.o

$(CC) -o mv1 mv1.o ran0.o -lm -ldcmt
mv1.o : mv1.c ran0.h
$(CC) -c mv1.c
ran0.o : ran0.c ran0.h
$(CC) -c ran0.c
clean :
rm -f *.o

This is a Tab, not spaces

CC = icc
CFLAGS = -lm -ldcmt
OBJS = mv1.o ran0.o
HDS = ran0.h
TARGET = mv1
.SUFFIXES : .c .o
all : $(TARGET)
$(TARGET): $(OBJS) $(HDS)
$(CC) -o $@ $(OBJS) $(CFLAGS)
clean :
rm -f $(OBJS) $(TARGET)

Procedures to solve a problem using computers

Check whether analytic solutions exist.
Even approximate solutions are helpful. (Check the condition where it is valid.)

Check previous numerical works in books, papers, or internet.

You should understand the algorithm and meaning of the work. (You should cite it.)
Plan the code
Determine the data structure.
Plan the algorithm.
Make a flow-chart and/or pseudo-code.
Type-in the code.

Debugging and test-run.

Optimization if needed. (Optimize only heavily-time-consuming routines.)

Actual run.

Analysis and discussion.

2016-09-01

Good code Definition of the good code ?

The Properties of Good Code by Christopher Diggins
I can't scientifically say what makes code "good", but my gut has a few things to say about it:
good code reflects the problem it solves

good code can be easily understood by programmers without experience in your language
good code is generally short

good code doesn't require much thinking to understand

good code has very little coupling

good code is cohesive - definitions of functions and types required are not scattered throughout
the software
good code documents any requirements for proper usage

good code makes just as much sense to you one year from now, as it does now
All of these properties I feel could be summed up simply as: "good code is reusable", and taken a
step further: "really good code is so simple it can be reused by a trained seal.".
http://archive.oreilly.com/pub/post/the_properties_of_good_code.html

What makes good code good? by Mike Jackson

Good code should...

Correct. Code must be correct and it should also be possible to demonstrate that it's correct, e.g. through provision of associated tests
or mathematical models of requirements.

Well-designed. Code should be modular with well-defined interfaces, inputs and outputs and with code and data encapsulation. It

should be elegant and no more complex than necessary. There should be minimal inter-dependencies, no hidden dependencies and limited
platform-specific dependencies. Together, these help ensure that the code is easily understandable by other developers; can promote reuse,
so reducing the need to reinvent the wheel in subsequent projects; and ensure software can be configured, adapted and extended easily.

Readable. Code should be commented and indented and use sensible naming. Comments should describe why the code is as it is,

since the code itself describes what it does and how it does it. Care should be taken that comments reflect the current code, because code
evolves through time.

Appropriate. The languages, technologies and tools should be suitable for the intended application area, and also take into account
the skills and knowledge of the current and future developers.

Robust. The code must not break anything and it should fail gracefully. Ideally, it should support configurable logging or other ways to

help users and developers identify and diagnose errors. Errors must not be swallowed by the code without a good, and commented, reason.

Efficient. Code must run in a timely way, for the specific applications area.

Available. Software should be available to those who need it! If it's not available, how will anyone be able to use it?

Usable. Software should be usable, buildable, deployable and runnable. Difficult-to-use software can discourage its uptake by users.
Software that can't be built, deployed or run is highly unusable!

Copyrighted and licenced. These protect intellectual property and let others know how they can use, modify and redistribute it.
Under revision control. The revision control should be backed up, and supported by sensible commit messages.

https://www.software.ac.uk/blog/2011-12-16-what-makes-good-code-good-digital-social-research-view

2016-09-01

Good code Definition of the good code ?

Correct (bug-free, proper algorithm, proper precision)

Fast (running time vs. coding time)

Economy of memory
* Localization of variables in time and space

Readable / Easy to debug or modify

* Comments (as friendly as possible) + documentation
* Modulization
* Consistent format (indentation, space, and blank lines)
* Proper names of variables and functions

Beautiful code

- K.Marx

Convenient input-output
* Echo
* Input-output using files
* Friendly and helpful interface
Robust and endurable
* Error-handling

Flexible, extensible, and reusable

How expensive is an operation on a CPU?

addition, subtraction, comparison (1)
abs (2)

multiplication (4)

division and modulus (10)

exp (50)

sqrt (??)

sin, cos, tan (60)

asin, acos, atan (80)

pow (100)

https://streamcomputing.eu/blog/2012-07-16/how-expensive-is-an-operation-on-a-cpu/
Exact operation time depends heavily on the CPU, compiler, or the situations.

The real problem is that programmers have spent far too much time worrying about
efficiency in the wrong places and at the wrong times; premature optimization is the
root of all evil (or at least most of it) in programming.
-- Donald Knuth

2016-09-01

Data-type, accuracy, and round-off error

Only two things are infinite, the universe and

Fixed point
human stupidity, and I'm not sure about the former.
-- Albert Einstein
char : 4-bit, [ 128, +127 ]
int : 16-bit, [ 32768, +32767 ] (?)
long : 32-bit, [ 2147483648, +2147483647 ] (?)
Floating point
float : 16-bit, [ range : ~E(+/)38 , precision : 6 decimal places ]
double : 32-bit, [ range : ~E(+/)308 , precision : 15 decimal places ]
long double : 64-bit, [ range : ~E(+/)4932 , precision : 18 decimal places]
The actual range and precision depends on your computer.

Which data-type should be chosen?

#include <stdio.h>
#include <float.h>

int main()
{
printf("Storage size for float : %d \n", sizeof(float));
printf("Minimum float positive value: %E\n", FLT_MIN );
printf("Maximum float positive value: %E\n", FLT_MAX );
printf("Precision value: %d\n", FLT_DIG );
}

Make them consistent.

By default, use int & double.

return 0;

Cautions
Data-type conversion

(int)+(int) (int) ; (int)(int) (int) ; (int)*(int) (int)

(int)/(int) (int) (e.g., 6/5 = 1 , 1/2 = 0)

(int)/(float) (float) (e.g., 6/5. = 1.2 , 1/2. = 0.5)

Underflow & overflow

lim

= ?

Round-off error

Loss of significance

==
.

True or False ?
. < .

Subtraction of nearly equal numbers (e.g.

True or False ?
.

2016-09-01

Can we believe computer?

Kepler conjecture

: No arrangement of equally sized spheres filling space

has a greater average density than that of the cubic
close packing.

Proved using computers by T. Hales and S. Ferguson in 1998

Referees of Annals of mathematics concluded 99% certain in 2002

Flyspeck project (2004~2014) announced formal proof.

Four-color theorem

: No more than four colors are required to color

the regions of the map so that no two adjacent
regions have the same color.

Three colors are not enough : Proved.

Five colors are enough : Proved.

Four colors are enough : Proved using computers (K. Appel and W. Haken in 1976)
Can we accept it to be proved? Some still disagree.

Sources of error
Algorithm level
Coding level

Numerical libraries
Compiler level
OS level

Hardware level

cf. Pentium bug : http://www.trnicely.net/pentbug/bugmail1.html

Discovered in 1994 by Professor T. R. Nicely

(824633702441.0)*(1/824633702441.0) = 0.999999996274709702
Same problem for 824633702418 <= x <= 824633702449

Same problem in compiled code, an Quattro Pro, an Excel,

and even the Windows calculator

Same problem for Dell P90, a Gateway P90, a Micron P60, an Insight P60,
and a Packard-Bell P60

10

2016-09-01

Homework #1
[15 pt] Find the minimum and maximum positive value in float, double, and long double in
your computer and compiler.

[15 pt] Find the maximum value in char, int, and long in your computer and compiler.

[70 pt] (a) Write a program that calculates the two solutions of the equation
using the following formula.
=

+ =

For = .
, =
, and = .
, find the two solutions and check whether it is true
or not by substituting the solutions into the equation. Repeat this for three kinds of variable-types:
float, double, and long-double.
(b) Repeat (a) using the following alternative formula.
=

(c) Compare your results of (a) and (b). Explain why. Write a program that gives correct
solutions for a quadratic equation in any case.

11