for n in range(N):
ynP1 = y + h*f(x+h/2, y + h*f(x,y)/2)
# Go to next level
x += h;
y = ynP1;
return ynP1
OR
for n in range(N):
ynP1 = y + h*f(x+h/2, y + h*f(x,y)/2)
# Go to next level
x += h;
y = ynP1;
return ynP1
The first one would not pass the linter. No indentation without an if, for etc.Indentation is scary; 2 code block that run but give different answers
one TAB too many means 0.5 versus 0.98
Code: Select allfor n in range(N): ynP1 = y + h*f(x+h/2, y + h*f(x,y)/2) # Go to next level x += h; y = ynP1; return ynP1 OR for n in range(N): ynP1 = y + h*f(x+h/2, y + h*f(x,y)/2) # Go to next level x += h; y = ynP1; return ynP1
Can we see the linter as a pre-compiler that we need to 'execute' before running?The first one would not pass the linter. No indentation without an if, for etc.Indentation is scary; 2 code block that run but give different answers
one TAB too many means 0.5 versus 0.98
I am sure you know this library: https://nlopt.readthedocs.io/en/latest/scipy.optimize is super to use.
Now why can't the C++ folk (Boost) just do the same by creating a wrapper for those original Fortran and C libraries.
Cool. I installed it from Python and ran a POC test. Looks good. Just thatI am sure you know this library: https://nlopt.readthedocs.io/en/latest/scipy.optimize is super to use.
Now why can't the C++ folk (Boost) just do the same by creating a wrapper for those original Fortran and C libraries.
I used 1. instead of 1 myself (in FORTRAN REAL*x = 1.0, x .EQ. 1 always FALSE afair), newbies might get confused. I wonder where and by whom this type checking takes place?If you check the source code on github, it expects a double as an output for the function. If not, it will throw an invalid argument error message.
Good point.Looking to source code, you can also see how to use SWIG to interface the C library to python.
If possible, I always install "packages" from source code. That's a good practise I learned working on Linux.