Another Fortran idiosyncracy bites me on the bum

I thought I'd have this program done by the end of the afternoon. So I start to write a function to calculate a nice simple Gaussian function. No NaNs and +Infs to contend with here, I thought. How wrong I was.
This time, I was finding that the intrinsic function exp(x) returned zero for x less than around -0.1E3. After some bashing, my compiler was sweet enough to tell me:

Result of EXP underflows its kind

Apparently, Fortran is not content with just "exp". It also has "dexp" and "cexp" for double-precision and complex floating point numbers respectively. So, dexp(x) it is then. But be careful how you define x, or you will get a shouty like this:

Type of argument 'x' in call to 'dexp' at (1) should be REAL(8), not REAL(4)

So one should try dexp(-0.1D3) (note the letter D!) rather than exp(-0.1E3), which will return zero, possibly grumbling in the process.

NaN, +Inf, -Inf, horrid things...

This is the answer.
Based on such, I have a sample function to detect a +Inf:

function ispinf(x)
! function to detect if x is +Inf
integer :: ispinf
double precision :: x

!local variables
integer :: IPInf
real :: PInf
data IPInf/B'01111111100000000000000000000000'/ ! +Infinity
PInf = transfer(IPinf,Pinf)

if (x.eq.PInf) then
ispinf = 1
else
ispinf = 0
endif

end function ispinf

...in which I pacify the fussy NAG routine

As usual, this is of interest to probably no-one but me, but I have just found the bug in my program.
I am trying to call NAG routine G05MZF which generates random integers from a probability distribution supplied by you. I have found routines give unexpected answers if you don't pass them variables of the correct type, so I was careful about this. The error I was getting at run-time was this:

At line 106 of file /scratch/zohair/FLL3A21DF/fll3a21df/source/g/g05mzfn.f
Fortran runtime error: Missing initial left parenthesis in format

I have had errors like this before which have been due to the reference vector (which contains the CDF) being too small, but this wasn't the case here. Instead, it turned out to be angry about being passed what it considered to be a non-normalized PDF. For example, passing a PDF which was 307 entries long with each entry set to 1.0D0/307.0D0 (ie. a flat distribution) worked fine. However, setting each entry to the actual value, 0.32573290D-02 was not accurately normalised enough, and it threw a hissy fit.

So the moral of the story is:
If you think you've normalized your PDF, the NAG library knows better. Expressed in code, this is:
P = P/sum(P)

In other news, I find it incredible how easy it is to destroy my code. Simply compiling program.f90 to the output file program.f90 will replace my code with executable junk. Surely they should have idiot-proofed this?

*********************************

Edit: 20th March 2008

Actually there's more to it than this. Firstly, the bizarre and unhelpful error is due to using gcc version 4.1.2 rather than the recommended version 4.2 which I don't yet have. If you use version 4.3, the error is more helpful, and gives you the value of IFAIL and results in a NAG hard failure telling you the deviation of the probability sum from unity. There are other issues too, but using the right compiler is helpful!

Installing a .sty file!

At last, I succeed in one thing!
I needed bbding.sty, so I downloaded the whole zip from CTAN. It included the .ins and .dtx files. I stuck it in a local temporary place and followed the instructions on this handy page.
I ran latex on the .ins file and then on the .dtx file. I then moved the whole folder and everything in it to my local texmf tree:

/usr/local/share/texmf/tex/latex/

into a folder of the same name, ie. bbding. Next, as a superuser I ran:
texhash
and we all lived happily ever after.

Merging PDF files

Assisted by this page, I managed to create a handy pdf file from the six .jpg files of sheet music I'd been sent. First I opened them in showFoto and printed them to six .pdf files, and then merged them on the linux command-line thus:
gs -dNOPAUSE -sDEVICE=pdfwrite -sOUTPUTFILE=Merged.pdf -dBATCH 1.pdf 2.pdf 3.pdf 3.pdf
etcetera, etcetera, etcetera...

Keyboard shortcuts for kwrite

As usual, this will be of very little interest to anyone but me, but it's actually made my day. I have accidentally discovered the keyboard shortcuts useful for editing fortran code in kwrite.

Ctrl+I - indents
Ctrl+Shift+I - un-indents
Ctrl + D - comments out code (by ! marks)
Ctrl + Shift + D - un-comments code

How exciting my day is today. I actually could have looked this up in the kwrite menu, so I am stupid too!

File I/O in Fortran 95

Can a "unit" be re-used after disconnecting from a previous file?
I believe the answer is yes! Two different units are only needed when trying to access two files at the same time. Once a file has been disconnected, one can re-use the number. Hoorah!