5 ms·

> offering almost a Python like experience If you do scientific computing, the fortran experience is much better than python's. You never feel out of place.

> offering almost a Python like experience If you do scientific computing, the fortran experience is much better than python's. You never feel out of place. Multi-dimensional arrays of floats are a native type, loops are fast, and the system is extremely stable. What does python offer you? Lists, dictionaries, strings (none of which is of any use to scientific computing) and a plethora of slightly incompatible external libraries for dealing with matrices. Worse, there's no hope [0] that your algorithms based in numpy/scipy/numba/tensorflow/torch/jax will run unchanged in a decade, not to say in 50 years. [0] https://pythonspeed.com/articles/numpy-2/ https://pythonspeed.com/articles/numpy-2/

Galanwe 3y ago
Yet reality contradicts you. > What does python offer you? Lists, dictionaries, strings (none of which is of any use to scientific computing) pandas/numpy/scipy/etc, so basically you get a blas/la pack equivalent, with a R/matlab feel. > there's no hope that your algorithms [...] will run unchanged in a decade, not to say in 50 years. Very few people care about that.
- deleted 3y ago
  [deleted]
- bitcharmer 3y ago
  I have no idea why you're getting down-voted. I've worked in finance/algo-trading for 15+ years. Went through shops like Goldman Sachs, Morgan Stanley, UBS, HSBC. Quants everywhere use CPP and Python, sometimes R. I've never seen Fortran used anywhere.
  - medo-bear 3y ago
    If they use Numpy in Python they surely use Fortran under the hood. Did you work in HFT? I would be very surprised if they used Python for that, and almost equally surprised if they all dismissed Fortran as an option. Besides the things you named, quants also use Excell (of course) but probably less known is K, which is an APL type language
    - Galanwe 3y ago
      > If they use Numpy in Python they surely use Fortran under the hood. Even that is disappearing. It was common practice even 10 years ago to use MKL as backend. > Did you work in HFT? Yes, I've done (and still do) HFT and mid freq since around 15 years. > I would be very surprised if they used Python for that Surprise! Nobody would dare do any heavy computation in e.g. C++ or Fortran or Cobol. It's just too unpractical, and slow to develop. You calibrate your models in Python/pandas/... , offline on historical data, and just use the prebuilt model to make the real-time prediction in C++, which doesn't involve much more than simple linear algebra. I would estimate conservatively that 80% of quants use Python, in both HFT and mid freq. There should be some niche where they use matlab, R, kdb or stata, but that's definitely a small fraction.
      - medo-bear 3y ago
        > Even that is disappearing. It was common practice even 10 years ago to use MKL as backend. Sorry I just saw this. And what do you think MKL does?
    - bitcharmer 3y ago
      I still work in HFT yes. A sibling comment lays it out better than I could, and I'm surprised that so many people here insist on Fortran's popularity when it's clearly absent from whole industries where you guys would expect to see it. Python is very widely used for prototyping and there's nothing anyone can do about it. In production the algos would be implemented in Cpp though. I'm merely stating a fact, not here to argue about anything. Raw K is almost never used but there's a lot of Q, depending on the shop.
    - merolish 3y ago
      Live trading systems are in C++ or Java, but like others have said Python is used for day-to-day research, sometimes R if the particular quant likes it. I never saw any Fortran in my time at Bloomberg in the 2010s but allegedly there was still a lot of it running in the nether regions.
  - BeetleB 3y ago
    Although financo/algo-trading is math heavy, it does not fall into the category of scientific computing. Just as you haven't experienced Fortran, there are several areas in science that have not experienced C++/Python, and rely on Fortran.
    - Galanwe 3y ago
      > Although financo/algo-trading is math heavy, it does not fall into the category of scientific computing. Care to elaborate on why this wouldn't be the case? As far as I can see, half of my desk is ex CNRS/CERN/CEA/... , the other half is the top brightest PhDs and engineers. When I look at weather forecast models, or biological DNA white papers, I don't see much difference in terms of scientific process or category of problem than what we see in quantitative finance. It may be sad, but the truth is finance phagocytates an immense chunk of the scientific community,abd it provides. There are interesting and hard problems to solve, virtually unlimited compute resources, etc. Most top quant HF have yearly double digit million dollar infrastructure bills, compute and storage clusters rivaling or surpassing academic ones, dedicated hardware manufacturers, etc.
      - BeetleB 3y ago
        I'm not disputing that there is seriously heavy math involved - many of my fellow PhDs in physics/engineering went to finance. It's just not what people consider as "science" :-) My point is that branch of HPC developed somewhat independently of most of other science disciplines. It's also relatively newer, so it doesn't rely heavily on legacy code from the 70's/80's. Generally, newer disciplines (computational biology, modern ML, etc) don't use Fortran. Older stuff (physics, electromagnetics, most engineering, etc) are full of Fortran, and continue to be.
- fastneutron 3y ago
  > Very few people care about that. While it may be true that the absolute number of people involved is small compared to the wider tech industry, long-term code reproducibility is critically important for engineering-heavy industries with long-lived, high consequence physical assets. Think aerospace, nuclear, petrochemical, electrical, and other civil infrastructure. If something in the environment changes and you need to re-analyze the performance of that asset to ensure safety & reliability under the new conditions, the first thing you do is re-run the benchmark cases to verify the answers didn't change from the last time you ran it. If they did, it throws your entire basis for design into question unless you can conclusively resolve the inconsistency.
- kergonath 3y ago
  > Very few people care about that. In the general population, probably. There is quite a large overlap with people doing HPC and scientific computing in general, however.
DeathArrow 3y ago
There's also Julia.
- v9v 3y ago
  Julia (and MATLAB) have large, heavy runtimes making them non-ideal for applications where size and startup speed matter, eg. libraries, edge computing. Their dynamic nature makes them much better at exploratory programming compared to Fortran though.
  - internetter 3y ago
    But OP isn't talking about edge computing, they are talking about scientific computing. Use the right tool for the job.
- pjmlp 3y ago
  Julia might get there in confort, but still a lot of catch up to do with a compiled language designed for scientic computing, which also had to win the hearts of Assembly programmers in speed and code size, as the first high level language with an optimizing compiler (there were some failed attempts before FORTRAN).
michaelt 3y ago
> If you do scientific computing For people whose needs are "I want to write a weather forecasting simulator, it needs to simulate very efficiently, we're modelling immutable physical laws so this code will still be good in several decades" then absolutely. OTOH for people whose needs are "I need to do some ad-hoc analysis on this CSV of experimental results, I gotta rush out a paper to not get scooped but nobody's going to build on this or use it again" or "I need to do a corporate data science project to forecast demand for this upcoming superhero movie based on social media buzz" - FORTRAN probably isn't the best choice. Unless you happen to already be such a master of square pegs that you're comfortable and productive at fitting them into round holes :)
jhbadger 3y ago
It depends on what you mean by "scientific computing". I can't imagine doing scientific computing in the sense I do (using computing to analyze scientific data) without strings, lists, dictionaries, and (not that you mentioned them) data frames, which means R and Python are far better tools for doing my kind of scientific computing (yes, I know that R, and maybe Python, use libraries like BLAS underneath and those were written in Fortran).
- manx 3y ago
  https://en.wikipedia.org/wiki/Computational_science https://en.wikipedia.org/wiki/Computational_science
  - jhbadger 3y ago
    Okay, but this mentions exactly my own field of computational biology. I don't think many computational biologists are using Fortran (except indirectly through libraries like BLAS) in the 21st century.
ginko 3y ago
> What does python offer you? The main offering of python is bindings and easy glue to pretty much any data source/sink imaginable.
fastneutron 3y ago
> Lists, dictionaries, strings (none of which is of any use to scientific computing) Disagree on this one. In my experience, the computational kernels of our newer scientific & engineering codes (Fortran or C++) are almost never invoked as standalone applications, and are instead embedded within much more complex workflows that are orchestrated with a Python API or Java application. The string handling, data containers, and support for standard file formats in these higher level languages are indispensable at this level, and add negligible overhead compared to the computational expense of the main solvers. Yes, these things are more ephemeral, but they are also more interchangeable. Confining them to a higher abstraction layer lets you more cleanly decouple this stuff from the essential numerical parts of the code. The historical lack of support for these basic amenities in Fortran (and the C-family to a lesser extent) has resulted in the need to maintain innumerable ad-hoc I/O formats, home-rolled nonstandard parsers, and other bizarre, Rube Goldberg-like abuses of the language. Since the original developers of these legacy codes were scientists and engineers first, and developers second, these constructs inevitably wind up being tightly coupled to a larger, organization-spanning workflow whose input-output mapping has remained bitwise identical for three decades, and must continue to do so for just as many more. Higher-level languages like Python have greatly alleviated this nightmare, at least on a go-forward basis.

Galanwe 3y ago

Yet reality contradicts you. > What does python offer you? Lists, dictionaries, strings (none of which is of any use to scientific computing) pandas/numpy/scipy/etc, so basically you get a blas/la pack equivalent, with a R/matlab feel. > there's no hope that your algorithms [...] will run unchanged in a decade, not to say in 50 years. Very few people care about that.

deleted 3y ago
[deleted]
bitcharmer 3y ago
I have no idea why you're getting down-voted. I've worked in finance/algo-trading for 15+ years. Went through shops like Goldman Sachs, Morgan Stanley, UBS, HSBC. Quants everywhere use CPP and Python, sometimes R. I've never seen Fortran used anywhere.
- medo-bear 3y ago
  If they use Numpy in Python they surely use Fortran under the hood. Did you work in HFT? I would be very surprised if they used Python for that, and almost equally surprised if they all dismissed Fortran as an option. Besides the things you named, quants also use Excell (of course) but probably less known is K, which is an APL type language
  - Galanwe 3y ago
    > If they use Numpy in Python they surely use Fortran under the hood. Even that is disappearing. It was common practice even 10 years ago to use MKL as backend. > Did you work in HFT? Yes, I've done (and still do) HFT and mid freq since around 15 years. > I would be very surprised if they used Python for that Surprise! Nobody would dare do any heavy computation in e.g. C++ or Fortran or Cobol. It's just too unpractical, and slow to develop. You calibrate your models in Python/pandas/... , offline on historical data, and just use the prebuilt model to make the real-time prediction in C++, which doesn't involve much more than simple linear algebra. I would estimate conservatively that 80% of quants use Python, in both HFT and mid freq. There should be some niche where they use matlab, R, kdb or stata, but that's definitely a small fraction.
    - medo-bear 3y ago
      > Even that is disappearing. It was common practice even 10 years ago to use MKL as backend. Sorry I just saw this. And what do you think MKL does?
  - bitcharmer 3y ago
    I still work in HFT yes. A sibling comment lays it out better than I could, and I'm surprised that so many people here insist on Fortran's popularity when it's clearly absent from whole industries where you guys would expect to see it. Python is very widely used for prototyping and there's nothing anyone can do about it. In production the algos would be implemented in Cpp though. I'm merely stating a fact, not here to argue about anything. Raw K is almost never used but there's a lot of Q, depending on the shop.
  - merolish 3y ago
    Live trading systems are in C++ or Java, but like others have said Python is used for day-to-day research, sometimes R if the particular quant likes it. I never saw any Fortran in my time at Bloomberg in the 2010s but allegedly there was still a lot of it running in the nether regions.
- BeetleB 3y ago
  Although financo/algo-trading is math heavy, it does not fall into the category of scientific computing. Just as you haven't experienced Fortran, there are several areas in science that have not experienced C++/Python, and rely on Fortran.
  - Galanwe 3y ago
    > Although financo/algo-trading is math heavy, it does not fall into the category of scientific computing. Care to elaborate on why this wouldn't be the case? As far as I can see, half of my desk is ex CNRS/CERN/CEA/... , the other half is the top brightest PhDs and engineers. When I look at weather forecast models, or biological DNA white papers, I don't see much difference in terms of scientific process or category of problem than what we see in quantitative finance. It may be sad, but the truth is finance phagocytates an immense chunk of the scientific community,abd it provides. There are interesting and hard problems to solve, virtually unlimited compute resources, etc. Most top quant HF have yearly double digit million dollar infrastructure bills, compute and storage clusters rivaling or surpassing academic ones, dedicated hardware manufacturers, etc.
    - BeetleB 3y ago
      I'm not disputing that there is seriously heavy math involved - many of my fellow PhDs in physics/engineering went to finance. It's just not what people consider as "science" :-) My point is that branch of HPC developed somewhat independently of most of other science disciplines. It's also relatively newer, so it doesn't rely heavily on legacy code from the 70's/80's. Generally, newer disciplines (computational biology, modern ML, etc) don't use Fortran. Older stuff (physics, electromagnetics, most engineering, etc) are full of Fortran, and continue to be.
fastneutron 3y ago
> Very few people care about that. While it may be true that the absolute number of people involved is small compared to the wider tech industry, long-term code reproducibility is critically important for engineering-heavy industries with long-lived, high consequence physical assets. Think aerospace, nuclear, petrochemical, electrical, and other civil infrastructure. If something in the environment changes and you need to re-analyze the performance of that asset to ensure safety & reliability under the new conditions, the first thing you do is re-run the benchmark cases to verify the answers didn't change from the last time you ran it. If they did, it throws your entire basis for design into question unless you can conclusively resolve the inconsistency.
kergonath 3y ago
> Very few people care about that. In the general population, probably. There is quite a large overlap with people doing HPC and scientific computing in general, however.

DeathArrow 3y ago

There's also Julia.

v9v 3y ago
Julia (and MATLAB) have large, heavy runtimes making them non-ideal for applications where size and startup speed matter, eg. libraries, edge computing. Their dynamic nature makes them much better at exploratory programming compared to Fortran though.
- internetter 3y ago
  But OP isn't talking about edge computing, they are talking about scientific computing. Use the right tool for the job.
pjmlp 3y ago
Julia might get there in confort, but still a lot of catch up to do with a compiled language designed for scientic computing, which also had to win the hearts of Assembly programmers in speed and code size, as the first high level language with an optimizing compiler (there were some failed attempts before FORTRAN).

michaelt 3y ago

> If you do scientific computing For people whose needs are "I want to write a weather forecasting simulator, it needs to simulate very efficiently, we're modelling immutable physical laws so this code will still be good in several decades" then absolutely. OTOH for people whose needs are "I need to do some ad-hoc analysis on this CSV of experimental results, I gotta rush out a paper to not get scooped but nobody's going to build on this or use it again" or "I need to do a corporate data science project to forecast demand for this upcoming superhero movie based on social media buzz" - FORTRAN probably isn't the best choice. Unless you happen to already be such a master of square pegs that you're comfortable and productive at fitting them into round holes :)

jhbadger 3y ago

It depends on what you mean by "scientific computing". I can't imagine doing scientific computing in the sense I do (using computing to analyze scientific data) without strings, lists, dictionaries, and (not that you mentioned them) data frames, which means R and Python are far better tools for doing my kind of scientific computing (yes, I know that R, and maybe Python, use libraries like BLAS underneath and those were written in Fortran).

manx 3y ago
https://en.wikipedia.org/wiki/Computational_science https://en.wikipedia.org/wiki/Computational_science
- jhbadger 3y ago
  Okay, but this mentions exactly my own field of computational biology. I don't think many computational biologists are using Fortran (except indirectly through libraries like BLAS) in the 21st century.

ginko 3y ago

> What does python offer you? The main offering of python is bindings and easy glue to pretty much any data source/sink imaginable.

fastneutron 3y ago

> Lists, dictionaries, strings (none of which is of any use to scientific computing) Disagree on this one. In my experience, the computational kernels of our newer scientific & engineering codes (Fortran or C++) are almost never invoked as standalone applications, and are instead embedded within much more complex workflows that are orchestrated with a Python API or Java application. The string handling, data containers, and support for standard file formats in these higher level languages are indispensable at this level, and add negligible overhead compared to the computational expense of the main solvers. Yes, these things are more ephemeral, but they are also more interchangeable. Confining them to a higher abstraction layer lets you more cleanly decouple this stuff from the essential numerical parts of the code. The historical lack of support for these basic amenities in Fortran (and the C-family to a lesser extent) has resulted in the need to maintain innumerable ad-hoc I/O formats, home-rolled nonstandard parsers, and other bizarre, Rube Goldberg-like abuses of the language. Since the original developers of these legacy codes were scientists and engineers first, and developers second, these constructs inevitably wind up being tightly coupled to a larger, organization-spanning workflow whose input-output mapping has remained bitwise identical for three decades, and must continue to do so for just as many more. Higher-level languages like Python have greatly alleviated this nightmare, at least on a go-forward basis.