Can someone (specially HHs') please tell me if at all any banks out there use Fortran (90 and later) for developing quantitative models.Btw I am a PhD student (Dec'07) at a top midwest school and have been thinking of breaking into quantitative finance. Math (PDEs/SDEs) is no problem for me but it seems that all jobs available specify 5 years of C++ as a minimum and the only computer language I am solid in is Fortran 90 (I do a lot of HPC work for solving sparse systems arising from FD/FE and spectral methods) which apparently also is the preferred HPC language in my major.Its just that I find Fortran very easy for doing/implementing math unlike C++ which seems to be a terribly complex language for doing numerics but then thats just me.Also I also found this link a while back...http://www.nag.co.uk/IndustryArticles/S ... dfSpecific bank/group names using Fortran would be appreciated. -Thank You

Fortran is pretty rare, 90, RatFor, or whatever,As for "5 years of C++", take that with a pinch of salt, most newbie PhDs are essentially incompetent at C++, as you say it's complex, and their feeble young minds have the sort of fear best compared to medieval peasants witnessing a comet. Far above their heads...Either one can program, or one can not. What you have to do is stop burning witches, and read 3-4 quite hard books.The NAG article is entertainment, not reality.NAGS PR people are shit, and you can quote me on this, indeed I have explained their failings to NAG directly.This article is insultingly stupid, the lies, inaccuracies and half truths are pitiful.

QuoteIts just that I find Fortran very easy for doing/implementing math unlike C++ which seems to be a terribly complex language for doing numerics but then thats just me.Fortran (Formula Translation) is a domain-specific language and was created for maths. C++ on the other hand is a flexible systems programming language and you have to do more to use it in a Fortran way. I have managed to tame C++ in this respect by using it in a multi-paradigm programming environment. So one must learn C++ well in order to create robust software. Half-measures lead to frustration.QuoteI am solid in is Fortran 90 (I do a lot of HPC work for solving sparse systems arising from FD/FE and spectral methods) which apparently also is the preferred HPC language in my major.C++ is the standard and you don't hear much about Fortarn. All new HPC applications are in C++ these days. Why not C++ in your university? It would be a career-enhancer.However, people who program in Fortran tend to be handy at developing apps once they make the step to C++ because they have learned MODULAR PROGRAMMING, something that is vital for maintainable s/w.Fortran instils translatable s/w engineering habits and work practices.QuoteWhat you have to do is stop burning witches, and read 3-4 quite hard books.Take the bull by its C++ horns, same idea, yes?

I am with Dominic on this one. Having been a Fortran programmer in the past and C++ at this moment, I found the article to be quite incomplete and indeed a more balanced approach would have been more appropriate. An editor should have read the article beforehand.I liked Fortran but I have not looked at it since 1990. It will be difficult to convince people to learn it (e.g. see my remark on new appllications in MPI).I do however, realise that it zillions of useful libraries. Wish C++ had them.(P.S. the remark about JAVA GUIs is very strange; AWT and Swing are very slow in our past experience...)

QuoteHowever, people who program in Fortran tend to be handy at developing apps once they make the step to C++ because they have learned MODULAR PROGRAMMING, something that is vital for maintainable s/w.One can do modular programming using Fortran 90/95 which supports most OOP concepts. Features like dynamic memory, modules, user defined data types (even ADT's), pointers etc. combined with some real cool intrinsics for array operations (which compilers can easily parallelize) make Fortran (90 and later) the easiest and most efficient language for numerics.QuoteI liked Fortran but I have not looked at it since 1990Things have changed. Using some of above concepts a standard LAPACK call for computing SVD in F95 can now be...call gesvd(a, s [,u] [,vt] [,ww] [,job] [,info]) Note that everything in square brackets is optional In F77 you would have used one of these...call sgesvd(jobu, jobvt, m, n, a, lda, s, u, ldu, vt, ldvt, work, lwork, info)call dgesvd(jobu, jobvt, m, n, a, lda, s, u, ldu, vt, ldvt, work, lwork, info)call cgesvd(jobu, jobvt, m, n, a, lda, s, u, ldu, vt, ldvt, work, lwork, rwork,info)call zgesvd(jobu, jobvt, m, n, a, lda, s, u, ldu, vt, ldvt, work, lwork, rwork,info)Anyways I better go and borrow a copy of Stroustrup.

QuoteAnyways I better go and borrow a copy of Stroustrup. Good idea. An even better one is always have a copy on your desk for reference. Quotecall sgesvd(jobu, jobvt, m, n, a, lda, s, u, ldu, vt, ldvt, work, lwork, info)This is flat and difficult-to-maintain code; there are too many parameters. using OO we can draw a clean distinction between member data, parameter data and WORK data (latter is private in C++) The magic number 7, plus or minus 2

QuoteOriginally posted by: CuchulainnQuoteAnyways I better go and borrow a copy of Stroustrup. Good idea. An even better one is always have a copy on your desk for reference. Quotecall sgesvd(jobu, jobvt, m, n, a, lda, s, u, ldu, vt, ldvt, work, lwork, info)This is flat and difficult-to-maintain code; there are too many parameters. using OO we can draw a clean distinction between member data, parameter data and WORK data (latter is private in C++) Upside; that function call hasn't changed appreciably since the 1970s, and when you try to compile it your compiler might say something incredibly cool, like "punched card rejected." Downside; the same. There doesn't seem to be a decent way of calling Lapack from C++ (though the equivalent in Python is u = svd(y)), or anything particularly Lapack-like for C++. How do you guys do SVD in your most excellent language? Write your own?I've seen one hedge fund asked for Fortran expertise. Old physicists, no doubt. Probably the reason more don't use it is Fortran's lack of other kinds of portable libraries, like those for networks and UI's. And because most banks use C++.