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
Monday, 10 March 2008
Wednesday, 27 February 2008
...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:
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!
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
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!
Friday, 8 February 2008
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:
texhash
and we all lived happily ever after.
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.
Wednesday, 16 January 2008
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...
gs -dNOPAUSE -sDEVICE=pdfwrite -sOUTPUTFILE=Merged.pdf -dBATCH 1.pdf 2.pdf 3.pdf 3.pdf
etcetera, etcetera, etcetera...
Tuesday, 15 January 2008
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!
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!
Monday, 14 January 2008
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!
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!
Tuesday, 8 January 2008
I can't even remember how to compile!
My previous programs which don't require linking to a NAG library seem to compile thus:
gfortran -m32 program.f90 -o program
If they do require linkage, I compile like this:
gfortran -m32 program.f90 /opt/NAG/fll3a21dfl/lib/libnag_nag.a -o program
Silly me. Won't forget that now, will I?
gfortran -m32 program.f90 -o program
If they do require linkage, I compile like this:
gfortran -m32 program.f90 /opt/NAG/fll3a21dfl/lib/libnag_nag.a -o program
Silly me. Won't forget that now, will I?
Subscribe to:
Posts (Atom)
