Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at statalist.org.
From | Stata SpecialEdition <stata.se@gmail.com> |
To | statalist@hsphsun2.harvard.edu |
Subject | Re: st: Stata vs Fortran |
Date | Wed, 1 Sep 2010 13:22:46 +0100 |
Why I want to use the FORTRAN language does not matter. My original question (how to read STATA dta files into FORTRAN) has been answer. Professor Sergiy Radyakin provided a link to code which someone has written to do exactly this. If there was not ever any need to do this, then this code would not exist. I did not say I did not want to learn read/write in FORTRAN, but working with the binary file itself has a large number of advantages. I assume you know what they are given your credentials. Lots of love. On 9/1/10, Allan Reese (Cefas) <allan.reese@cefas.co.uk> wrote: > This discussion seems to have gone off topic, and stata.se (why hide > behind pseudonym?) has not indicated what Fortran properties Stata, > Mata, or any other language cannot replicate. I would suggest that > within any complex calculation (supercomputers, multiple processors have > been mentioned), the overhead of learning how to read a formatted Ascii > file into Fortran will be trivial. It is also likely that the data file > in Stata will contain variables not needed in the Fortran calculation. > > My credentials: my first computer language was Fortran 66, and > subsequently learned Fortran 77 among the 6 languages we covered in a > one-year computer science course. Subsequently worked on university > helpdesk with many Fortran users. > > Reasons for caution: > 1) Our Fortran compilers could build in various levels of run-time > checks (eg overflow, array bound checks). Some people who wrote the > most complicated programs would turn all the checks off, which made the > code run much faster but with far less confidence in the answers! > 2) Stata.se's reason for choosing Fortran may be the availability of > excellent and well-proven routines (eg Nag library). I would encourage > using such code. Another helpdesk caller had written his own subroutine > for numerical integration but asked for help as it was slow and > convergence was poor. His routine took 30 seconds per call; the Nag > equivalent took 0.1 seconds, had been validated as accurate, and would > detect non-convergent functions. > 3) Maybe you don't want to learn Fortran's READ statement, but how will > you get to see the results without learning WRITE? And WRITE is still > the most powerful tool for debugging your logic. > > Fortran had, and has, the advantage of being a language completely > defined by a standard, though I once looked at a program that started > with the comment, "This program is written to the Fortran standard > except we rely on accessing absolute memory addresses." > > The original query included, "Is it possible to read my STATA files in > FORTRAN? A colleague said it was impossible and I would have just save > it as an ASCII." Colleague is clearly wrong, or misquoted. > > Allan > > > > *********************************************************************************** > This email and any attachments are intended for the named recipient only. > Its unauthorised use, distribution, disclosure, storage or copying is not > permitted. If you have received it in error, please destroy all copies and > notify the sender. In messages of a non-business nature, the views and > opinions expressed are the author's own and do not necessarily reflect those > of the organisation from which it is sent. All emails may be subject to > monitoring. > *********************************************************************************** > > > * > * For searches and help try: > * http://www.stata.com/help.cgi?search > * http://www.stata.com/support/statalist/faq > * http://www.ats.ucla.edu/stat/stata/ > * * For searches and help try: * http://www.stata.com/help.cgi?search * http://www.stata.com/support/statalist/faq * http://www.ats.ucla.edu/stat/stata/