Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why physicists still use Fortran (2015)

moreisdifferent.com

Post reply on HN
Print view View original

151–160 of 300 posts

Re: Why physicists still use Fortran (2015)

#151

Post by ryanpepper »

tyingq wrote: post #48
sbmassey wrote: post #43

Earlier quoted context omitted.

Unless you're passing arrays of pointers to things about, the individual elements in a C array should be contiguous.

>Unless you're passing arrays of pointers That seems to be the context from his example: for(i = 0; i I suppose the counterpoint is that he's doing it wrong. But again, maybe physicists just don't want a tool with that much flexibility.

I was taught to do it like this in C:

  double *a = malloc(sizeof(double)*nx*ny*nz);
  int id;
  for(int k = 0; k
You can do it in other ways (arrays of pointes, etc), but I think this is probably the simplest conceptually, and the memory is contiguous.

Re: Why physicists still use Fortran (2015)

#152

Post by HelloNurse »

sampo wrote: post #114
adrianN wrote: post #94

Earlier quoted context omitted.

Well, that Fortran codebase probably also was written in large parts by PhD students, not export Fortran programmers.

Fortran is a much simpler and safer language than C++. And faster to learn. Fortran is even somewhat simpler than C or Java, whereas C++ is probably the most complicated language in the known universe. So especially in the hands of non-experts, Fortran should produce less bugs.

C++ is complex. Perl is complicated.

Re: Why physicists still use Fortran (2015)

#153

Post by sidlls »

DaiPlusPlus wrote: post #145
noobermin wrote: post #124

Some of the points brought up here are in fact correct, mainly legacy, testing, and awesome compilers tuned for supercomputers. However, a lot of these "why fortran" articles (on both sides) I find are written by people who don't dabble enough on both sides of the fence, and are ignorant of what either side offers. For example, numpy implements a lot of the stuff from fortran the author listed, like broadcasting oper…

C++'s generic-programming feature still has shortcomings - I think functional-programming has more relevance to scientific computing, but C++'s functional features are "okay" but still not as capable or proven as, say, Haskell's or OCaml's - for example for tail-recursion you still depend on the compiler supporting that optimization, you can't force it or necessarily assume it will happen, with fun consequences for y…

> I think functional-programming has more relevance to scientific computing

What do you base this on?

Re: Why physicists still use Fortran (2015)

#154

Post by keithnz »

I'd be interested in some stats around this, My father was a physicist, and I did some programming work for him at a large research institute, and while there was fortran around, most of the scientists were reaching for new tools where they could.

Re: Why physicists still use Fortran (2015)

#155

Post by fnord123 »

smcdow wrote: post #50

Speaking from a government contracting point of view: Nobody is going to pay you to rewrite existing code that's already working. Nobody. The customer doesn't give a flying shit about the implementation. He'd be happy with a box of diodes as an implementation, as long as it worked and came in on time and on budget. When you're writing up your proposal for a contract or a grant, the theme should always be that you're…

People don't tend to write tests for their Fortran code so the assumption that its already working and the numbers coming out are correct is a matter of faith.

But yes, no one sees it this way.

Re: Why physicists still use Fortran (2015)

#156

Post by HelloNurse »

DaiPlusPlus wrote: post #145
noobermin wrote: post #124

Some of the points brought up here are in fact correct, mainly legacy, testing, and awesome compilers tuned for supercomputers. However, a lot of these "why fortran" articles (on both sides) I find are written by people who don't dabble enough on both sides of the fence, and are ignorant of what either side offers. For example, numpy implements a lot of the stuff from fortran the author listed, like broadcasting oper…

C++'s generic-programming feature still has shortcomings - I think functional-programming has more relevance to scientific computing, but C++'s functional features are "okay" but still not as capable or proven as, say, Haskell's or OCaml's - for example for tail-recursion you still depend on the compiler supporting that optimization, you can't force it or necessarily assume it will happen, with fun consequences for y…

For scientific computing, whether a language has very advanced or merely okay functional features is only a superficial style issue.

Regarding more important performance issues like low level control of memory layout and avoiding pointless copying and indirection, C++ and Fortran are both at the most effective end of the spectrum, while typical functional languages lie between "don't even think about it, by design" and "it might be OK but only a fool would put a project at the mercy of what optimizations a relatively unproven compiler opts to do".

Re: Why physicists still use Fortran (2015)

#157

Post by dsacco »

ptero wrote: post #150
thicknavyrain wrote: post #24

"Professors usually have this legacy code on hand (often code they wrote themselves decades ago) and pass this code on to their students. This saves their students time, and also takes uncertainty out of the debugging process." This is so true. I'm a PhD student in physics using Fortran for pretty much that reason. At the start of my PhD, in response to my supervisor telling me I should learn Fortran to modify our cu…

Yes, C++ does not buy you that much. Sure, it is a more modern language, but when used by scientists (not software engineers) the advantages are hardly earth shattering. Much of complexity is hidden (as it should be) into libraries. IMO, Python stands a better chance of breaking the Fortran's lock on physics related computing. Give it a few more years and enough numpy-based libraries might make Python a real competit…

I have to be honest with you, as someone who writes in both C++ and Python, I really do not see Python being more of a candidate than C++ for displacing Fortran.

Can you clarify why you think Python might be able to do it? For scientific computation with high performance requirements, Python is not competitive with Fortan or C++. For work that continues to happen in Fortran due to "academic inertia", my impression (and vague experience) is that researchers find the convenience of what they're accustomed to (Fortran) to be greater than the convenience of things like rapid prototyping offered by the various Python scientific computing and data analysis libraries. There is a mental overhead is switching, and I think most academics are sort of okay writing code in whatever is familiar and battle-tested if it means they can focus more on the research at hand.

In other words, I'm not saying you're wrong, but I'm not following your reasoning.

Re: Why physicists still use Fortran (2015)

#158

Post by solidsnack9000 »

noobermin wrote: post #124

Some of the points brought up here are in fact correct, mainly legacy, testing, and awesome compilers tuned for supercomputers. However, a lot of these "why fortran" articles (on both sides) I find are written by people who don't dabble enough on both sides of the fence, and are ignorant of what either side offers. For example, numpy implements a lot of the stuff from fortran the author listed, like broadcasting oper…

> ...not to mention the scipy library that contains leagues of the famous fortran codes...

This doesn't actually make Python an alternative to Fortran, though -- what it's saying is that no one writes the performant code in Python.

Re: Why physicists still use Fortran (2015)

#159

Post by vacri »

dsacco wrote: post #157
ptero wrote: post #150

Earlier quoted context omitted.

Yes, C++ does not buy you that much. Sure, it is a more modern language, but when used by scientists (not software engineers) the advantages are hardly earth shattering. Much of complexity is hidden (as it should be) into libraries. IMO, Python stands a better chance of breaking the Fortran's lock on physics related computing. Give it a few more years and enough numpy-based libraries might make Python a real competit…

I have to be honest with you, as someone who writes in both C++ and Python, I really do not see Python being more of a candidate than C++ for displacing Fortran. Can you clarify why you think Python might be able to do it? For scientific computation with high performance requirements, Python is not competitive with Fortan or C++. For work that continues to happen in Fortran due to "academic inertia", my impression (a…

In a previous discussion of this kind (I'm not in this area myself), a scientist had said that the speed of the languages is less important than iterating the algorithms, and it was a lot easier for non-developer scientists to work with python than with C++.

Re: Why physicists still use Fortran (2015)

#160

Post by mushishi »

rdiddly wrote: post #84

The paragraph on "legacy code" is a bit weak and half-hearted because it underemphasizes one of the most important arguments for using old code: it's been thoroughly debugged already. The most the author can summon on the topic is the fact that legacy code "takes uncertainty out of the debugging process." What? There is no debugging process, because that code has been debugged for 40 years and is damn near bulletproo…

I don't know about mathematical domain, so this might be off-topic but in some cases a legacy code base that works perfectly can be brittle and full of holes and bugs that never manifested themselves because the code not directly interfacing the input data is guarded by subset of possible data it should support, and many of the possible code paths have not been evaluated.

But if you try to refactor the code to, say support other feature or optimise it, you might get into nastiness that is beyond comprehension, and you cannot count on that the code is coherent or correct.

This is my experience for maintaining a legacy base that has been many years in production. It's just a pile of frozen code that nobody has properly refactored probably out of fear for breaking something. This way you end up with unreadable layers and weird technology-specific hacks that were carefully made just work, probably not understanding what the existing code actually did but cargo-culting and resulting with massive amount of code that does little.

Post reply on HN