2 ms·

Python itself isn't really used for scientific computing. Pythons bindings to high performance libraries, many of which use Fortran under the hood, are used for

Python itself isn't really used for scientific computing. Pythons bindings to high performance libraries, many of which use Fortran under the hood, are used for scientific computing. Combined with the ease of displaying results ala Matlab but much less of the jank, and you have an ideal general purpose sci comp environment

KeplerBoy 3y ago
Still, people leave a lot of performance on the table when using Numpy in sub-optimal ways or when the problem just doesn't translate neatly to Numpy. It's tempting to get lazy and just use a for-loop to iterate over an array sometimes and that will absolutely kill your performance.
- dataminded 3y ago
  Frequently because those performance gains aren't actually needed. We live in an age where you can cheaply and quickly scale the hardware for 99% of tasks. Tasks that are too expensive to compute inefficiently are also unlikely to be profitable enough to be doing at all.
- ska 3y ago
  There is often no real value in optimizing such code, if the computation finishes in a time that doesn’t mess with your workflow. Spending more time on it will often just take time away from something more valuable to the research.
  - KeplerBoy 3y ago
    Ahh yes, that's a good point. If you're, for example working in a Jupyter Notebook, it absolutely doesn't matter if a cell needs 3 seconds or 3 milliseconds to execute.
Lyngbakr 3y ago
Back when I worked in scientific programming, we adopted a similar approach. The heavy lifting functions we wrote in C, but they were called from R which allowed us to plot the results, etc., easily. And the libraries we used (for solving differential equations) were all old school Fortran libraries. If I were to start again today, I think I'd give Julia a look, though.
dataminded 3y ago
You can make this claim about anything that isn't direct machine instruction. End users are using python - the advantage of modern computing is that whatever happens afterwards is irrelevant.

KeplerBoy 3y ago

Still, people leave a lot of performance on the table when using Numpy in sub-optimal ways or when the problem just doesn't translate neatly to Numpy. It's tempting to get lazy and just use a for-loop to iterate over an array sometimes and that will absolutely kill your performance.

dataminded 3y ago
Frequently because those performance gains aren't actually needed. We live in an age where you can cheaply and quickly scale the hardware for 99% of tasks. Tasks that are too expensive to compute inefficiently are also unlikely to be profitable enough to be doing at all.
ska 3y ago
There is often no real value in optimizing such code, if the computation finishes in a time that doesn’t mess with your workflow. Spending more time on it will often just take time away from something more valuable to the research.
- KeplerBoy 3y ago
  Ahh yes, that's a good point. If you're, for example working in a Jupyter Notebook, it absolutely doesn't matter if a cell needs 3 seconds or 3 milliseconds to execute.

Lyngbakr 3y ago

Back when I worked in scientific programming, we adopted a similar approach. The heavy lifting functions we wrote in C, but they were called from R which allowed us to plot the results, etc., easily. And the libraries we used (for solving differential equations) were all old school Fortran libraries. If I were to start again today, I think I'd give Julia a look, though.

dataminded 3y ago

You can make this claim about anything that isn't direct machine instruction. End users are using python - the advantage of modern computing is that whatever happens afterwards is irrelevant.