# How to solve the same numerical Problem in 7 different Programming Languages **URL:** \ **Category:** Uncategorized\ **Created:** [May 25, 2022, 4:13am UTC](https://fortran-lang.discourse.group/t/how-to-solve-the-same-numerical-problem-in-7-different-programming-languages/3548 "2022-05-25T04:13:09Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![jacobwilliams](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jacobwilliams/32/10_2.png) [@jacobwilliams](https://fortran-lang.discourse.group/u/jacobwilliams)\ **Post date:** [May 25, 2022, 4:13am UTC](https://fortran-lang.discourse.group/t/how-to-solve-the-same-numerical-problem-in-7-different-programming-languages/3548/1 "2022-05-25T04:13:10Z")
> **[How to solve the same numerical Problem in 7 different Programming Languages](https://medium.com/@andreaskuhn92/how-to-solve-the-same-numerical-problem-in-7-different-programming-languages-a64daac3ed64)** > > Finding the right tool, to solve a problem, can often be a big problem by itself. In the case of programming, this translates to choosing… Most of the Fortran discussion is spent explaining how weird implicit none is. ---
**Author:** ![MarDie](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/mardie/32/54_2.png) [@MarDie](https://fortran-lang.discourse.group/u/MarDie)\ **Post date:** [May 25, 2022, 5:08am UTC](https://fortran-lang.discourse.group/t/how-to-solve-the-same-numerical-problem-in-7-different-programming-languages/3548/2 "2022-05-25T05:08:20Z")
I find it weirder to use subroutines instead of a functions. ---
**Author:** ![Carltoffel](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/carltoffel/32/1680_2.png) [@Carltoffel](https://fortran-lang.discourse.group/u/Carltoffel)\ **Post date:** [May 25, 2022, 6:45am UTC](https://fortran-lang.discourse.group/t/how-to-solve-the-same-numerical-problem-in-7-different-programming-languages/3548/3 "2022-05-25T06:45:03Z")
Well, he has a point. It is weird to have such an old feature sticking around for such a long time. IMHO, `implicit none` should be the default, at least for free form source code. ---
**Author:** ![conradoat](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/conradoat/32/1537_2.png) [@conradoat](https://fortran-lang.discourse.group/u/conradoat)\ **Post date:** [May 25, 2022, 7:33am UTC](https://fortran-lang.discourse.group/t/how-to-solve-the-same-numerical-problem-in-7-different-programming-languages/3548/4 "2022-05-25T07:33:24Z")
Totally agree. It is not a matter of simplicity. It is a matter of marketing, for situations such like that in the link. ---
**Author:** ![shahmoradi](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/shahmoradi/32/3151_2.png) [@shahmoradi](https://fortran-lang.discourse.group/u/shahmoradi)\ **Post date:** [May 25, 2022, 8:36am UTC](https://fortran-lang.discourse.group/t/how-to-solve-the-same-numerical-problem-in-7-different-programming-languages/3548/5 "2022-05-25T08:36:36Z")
The genuine disappointment for me is that people dare to advise others about topics they barely know (here, Fortran) because, in their perceived (potentially biased) view of the world, they are the epicenter of justice, fairness, and the peak of the mountain of knowledge with no room for any doubts. This problem goes beyond a simple language comparison and is endemic to all inexperienced. Also, this article seems to be a Julia marketing post. ---
**Author:** ![mecej4](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/mecej4/32/855_2.png) [@mecej4](https://fortran-lang.discourse.group/u/mecej4)\ **Post date:** [May 25, 2022, 9:00am UTC](https://fortran-lang.discourse.group/t/how-to-solve-the-same-numerical-problem-in-7-different-programming-languages/3548/6 "2022-05-25T09:00:57Z")
Ah, yes. The magazine article author who is “often wrong but never uncertain”. After running the Python,…,Perl, C++, Fortran versions, goes on to say, " I wasn’t satisfied in seeing such old languages win. There has to be some progress made in language design. So I took a second look at the Julia version, as it was the one that showed the biggest potential. Using all the tricks the C++ guys showed me, I settled on this optimized Julia version." Let us also note that the author is a graduate student and the article is one way of “having some fun” as @macneacail sometimes does. ---
**Author:** ![JohnCampbell](https://avatars.discourse-cdn.com/v4/letter/j/5daacb/32.png) [@JohnCampbell](https://fortran-lang.discourse.group/u/JohnCampbell)\ **Post date:** [May 25, 2022, 9:59am UTC](https://fortran-lang.discourse.group/t/how-to-solve-the-same-numerical-problem-in-7-different-programming-languages/3548/7 "2022-05-25T09:59:03Z")
I must be misreading the problem definition, but where is N or dt defined ? A function is much better and the initial condition can be provided as u(1). Also no discussion of accuracy with first derivitive extrapolation ? (or is that part of the solution for other languages ?) An alternative is to also use the second derivitive, with a larger dt I needed N=500 for stability and N=125 with second derivitive, assuming I interpreted the rest of the problem description. ---
**Author:** ![mecej4](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/mecej4/32/855_2.png) [@mecej4](https://fortran-lang.discourse.group/u/mecej4)\ **Post date:** [May 25, 2022, 10:42am UTC](https://fortran-lang.discourse.group/t/how-to-solve-the-same-numerical-problem-in-7-different-programming-languages/3548/8 "2022-05-25T10:42:54Z")
The analytical solution is in terms of the tanh function. ---
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [May 25, 2022, 11:10am UTC](https://fortran-lang.discourse.group/t/how-to-solve-the-same-numerical-problem-in-7-different-programming-languages/3548/9 "2022-05-25T11:10:01Z")
When reading such articles, I wonder if more people are influenced by the author’s opinions > nobody should ever use **FORTRAN** outside of existing legacy projects or the actual code. Looking at the C++ code, ```auto #include static double f(double u){ return u*(1.0-u); } void Cplusplus_logistic(int N, vector& u, double dt){ // Parameters int T = 25; double u0 = 1e-5; // Discretization u[0] = u0; for(auto i = u.begin(); i != u.end(); ++i){ *(i+1) = *i + dt*f(*i); } return (u); } ``` it took me a while to understand that `*(i+1) = *i + dt*f(*i);` sets a value of array element `u[i+1]`. I think the Fortran code is clearer, and it could be improved, as discussed above. ```auto subroutine f(u, r) implicit none real(kind(0.d0)), intent(out) :: r real(kind(0.d0)), intent(in) :: u r = u*(1.d0-u) end subroutine f subroutine fortran_logistic(N, dt, u) integer, intent(in) :: N real(kind(0.d0)), intent(in) :: dt real(kind(0.d0)), intent(out) :: u(N) integer :: i real(kind(0.d0)) :: temp u(1) = 1.d-5 do i=1, N-1 call f(u(i), temp) u(i+1) = u(i) + dt*temp end do end subroutine fortran_logistic ``` I just purchased the book [High Performance Python: Practical Performant Programming for Humans, 2nd Ed.](https://www.oreilly.com/library/view/high-performance-python/9781492055013/) by Gorelick and Ozsvald. Along with using NumPy, Cython, and calling C, they do consider using Fortran with f2py for speed. ---
**Author:** ![Aurelius\_Nero](https://avatars.discourse-cdn.com/v4/letter/a/a87d85/32.png) [@Aurelius\_Nero](https://fortran-lang.discourse.group/u/Aurelius_Nero)\ **Post date:** [May 25, 2022, 11:51am UTC](https://fortran-lang.discourse.group/t/how-to-solve-the-same-numerical-problem-in-7-different-programming-languages/3548/10 "2022-05-25T11:51:28Z")
I tried to improve his code Compiler: ifort Flags: -O3 1. I didn’t understand why he needed two subroutines 2. He also adds some overhead with the subroutine call inside a loop 3. I added some comments and spaces to make the code readable 4. I also graph the data at the end If possible, how can I improve his code further ? ```auto program simple_num_prob implicit none integer :: i integer,parameter :: tf=25,n=10000 real,allocatable :: t(:),u(:) real :: dt real(kind=8) :: t1,t2 character(len=*),parameter :: plt_file='simple_num_prob.gp' call cpu_time(t1) allocate(t(n)) allocate(u(n)) ! Assigning step value dt=real(tf)/real(n) ! Initial u value assigned u(1)=1.0E-5 ! Population of t vector do i=1,n t(i)=real(i) end do ! Calculating and populating the function vector do i=1,n-1 u(i+1) = u(i) + (dt*(u(i)*(1.0-u(i)))) end do call cpu_time(t2) print *, "Elapsed time",t2-t1 !writing to file open (unit=1,file='simple_num_prob.dat') do i=1,n write(1,*) t(i),' ',u(i) end do close(1) print *, "File written !" call cpu_time(t2) print *, "Elapsed time with writing to file",t2-t1 !deallocation deallocate(t) deallocate(u) call execute_command_line('gnuplot ' // plt_file) end program simple_num_prob ``` Gnuplot file: ```auto plot 'simple_num_prob.dat' using 1:2 pause -1 ``` ---
**Author:** ![gnikit](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/gnikit/32/1213_2.png) [@gnikit](https://fortran-lang.discourse.group/u/gnikit)\ **Post date:** [May 25, 2022, 12:14pm UTC](https://fortran-lang.discourse.group/t/how-to-solve-the-same-numerical-problem-in-7-different-programming-languages/3548/11 "2022-05-25T12:14:03Z")
> [@Beliavsky](#): > > When reading such articles, I wonder if more people are influenced by the author’s opinions > > > nobody should ever use **FORTRAN** outside of existing legacy projects Me too! I don’t see any value being added in articles by making such broad generalisations. Especially when they are followed by performance metrics that prove that very sentence false. Also, I chuckled when I read that quote. Someone should probably let the rest of the world know… ---
**Author:** ![mecej4](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/mecej4/32/855_2.png) [@mecej4](https://fortran-lang.discourse.group/u/mecej4)\ **Post date:** [May 25, 2022, 12:41pm UTC](https://fortran-lang.discourse.group/t/how-to-solve-the-same-numerical-problem-in-7-different-programming-languages/3548/12 "2022-05-25T12:41:26Z")
What’s a **void** function doing with a **return** statement? ```auto void Cplusplus_logistic(int N, vector& u, double dt){ ... return (u); } ``` ---
**Author:** ![Pap](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pap/32/1305_2.png) [@Pap](https://fortran-lang.discourse.group/u/Pap)\ **Post date:** [May 25, 2022, 1:21pm UTC](https://fortran-lang.discourse.group/t/how-to-solve-the-same-numerical-problem-in-7-different-programming-languages/3548/14 "2022-05-25T13:21:37Z")
> [@MarDie](#): > > I find it weirder to use subroutines instead of a functions. I find it weird to use functions all the time, as C does. Both subroutines and functions have their uses. The concept of a `void` “function” is not only misleading, but plain wrong from a Mathematical point of view, if you ask me. Furthermore, a function that returns two or more separate entities (by its name and by altering its arguments) is also weird - but still allowed in Fortran. If a “function” has to return multiple things, either wrap them in a derived type and return just that, or make it a subroutine. It’s way more clear and easily understood. Compilers supporting the F-standard actually issue a syntax error if a function has any `intent(out)` or `intent(inout)` arguments, recommending using a subroutine instead. > [@Carltoffel](#): > > IMHO, `implicit none` should be the default, at least for free form source code. Totally agree. Again, the F-standard makes `implicit none` obsolete since it is implied by default (it is a pity popular compilers lack `-std=F`.) However I have to tell people still bashing Fortran because of `implicit none` that backwards compatibility is the reason it exists, and I could find way weirder “features” in the programming languages they praise 24/7, be it C, C++ or, even worse, Python, Java, C#, whatever… > [@Beliavsky](#): > > When reading such articles, I wonder if more people are influenced by the author’s opinions > > > nobody should ever use **FORTRAN** outside of existing legacy projects The quoted statement is correct if and only if the author means FORTRAN and not Fortran - but I doubt he does. Most people bashing Fortran aren’t even aware of the difference, but that doesn’t stop them from having a strong opinion and hate anyway. I really hope that article would influence as less people as possible - preferably nobody. ---
**Author:** ![conradoat](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/conradoat/32/1537_2.png) [@conradoat](https://fortran-lang.discourse.group/u/conradoat)\ **Post date:** [May 25, 2022, 1:26pm UTC](https://fortran-lang.discourse.group/t/how-to-solve-the-same-numerical-problem-in-7-different-programming-languages/3548/15 "2022-05-25T13:26:23Z")
Totally agree with you. Just to add my 1 and 1/2 cents, I understand void functions in C/C++ as the analog of fortran subroutines with no intent(out) arguments. Otherwise it also seems weird to me. ---
**Author:** ![Pap](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pap/32/1305_2.png) [@Pap](https://fortran-lang.discourse.group/u/Pap)\ **Post date:** [May 25, 2022, 1:38pm UTC](https://fortran-lang.discourse.group/t/how-to-solve-the-same-numerical-problem-in-7-different-programming-languages/3548/16 "2022-05-25T13:38:46Z")
> [@shahmoradi](#): > > The genuine disappointment for me is that people dare to advise others about topics they barely know (here, Fortran) because, in their perceived (potentially biased) view of the world, they are the epicenter of justice, fairness, and the peak of the mountain of knowledge with no room for any doubts. This problem goes beyond a simple language comparison and is endemic to all inexperienced. Also, this article seems to be a Julia marketing post. Someone give me a double “like” please. Oh wait, make it triple like. Perhaps quad like. Ok, 100 like. The quoted post definitely deserves it. 😆 The author doesn’t hide under the carpet the fact “FORTRAN” is fast though… you have to grant him that. Although his sorrow for admitting Fortran is fast is more than obvious. ---
**Author:** ![MarDie](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/mardie/32/54_2.png) [@MarDie](https://fortran-lang.discourse.group/u/MarDie)\ **Post date:** [May 25, 2022, 1:56pm UTC](https://fortran-lang.discourse.group/t/how-to-solve-the-same-numerical-problem-in-7-different-programming-languages/3548/17 "2022-05-25T13:56:03Z")
> [@Pap](#): > > > [@MarDie](#): > > > > I find it weirder to use subroutines instead of a functions. > > I find it weird to use functions all the time, as C does. Both subroutines and functions have their uses. The concept of a `void` “function” is not only misleading, but plain wrong from a Mathematical point of view, if you ask me. Totally agree, both concepts are useful. My comment was directly related to the original code from [Fortran logistic · GitHub](https://gist.github.com/AndreasKuhn-ak/0fbba22c28e57ccef5eadded382a48ba#file-logostic-f90) ```auto subroutine f(u, r) implicit none real(kind(0.d0)), intent(out) :: r real(kind(0.d0)), intent(in) :: u r = u*(1.d0-u) end subroutine f subroutine fortran_logistic(N, dt, u) integer, intent(in) :: N real(kind(0.d0)), intent(in) :: dt real(kind(0.d0)), intent(out) :: u(N) integer :: i real(kind(0.d0)) :: temp u(1) = 1.d-5 do i=1, N-1 call f(u(i), temp) u(i+1) = u(i) + dt*temp end do end subroutine fortran_logistic ``` where for me the subroutine `f` should be a function: ```auto function f(u) implicit none real(kind(0.d0)) :: f real(kind(0.d0)), intent(in) :: u f = u*(1.d0-u) end function f subroutine fortran_logistic(N, dt, u) integer, intent(in) :: N real(kind(0.d0)), intent(in) :: dt real(kind(0.d0)), intent(out) :: u(N) integer :: i u(1) = 1.d-5 do i=1, N-1 u(i+1) = u(i) + dt*f(u(i)) end do end subroutine fortran_logistic ``` This reads IMHO much better and is not too different from the Python variant. I would even make `fortran_logistic` a function here because it has a single return value. ---
**Author:** ![MarDie](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/mardie/32/54_2.png) [@MarDie](https://fortran-lang.discourse.group/u/MarDie)\ **Post date:** [May 25, 2022, 2:08pm UTC](https://fortran-lang.discourse.group/t/how-to-solve-the-same-numerical-problem-in-7-different-programming-languages/3548/18 "2022-05-25T14:08:09Z")
> [@Carltoffel](#): > > Well, he has a point. It is weird to have such an old feature sticking around for such a long time. IMHO, `implicit none` should be the default, at least for free form source code. I agree. But it does not have to appear in functions/subroutines because a single `implicit none` at the module level is sufficient. ---
**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\ **Post date:** [May 25, 2022, 2:50pm UTC](https://fortran-lang.discourse.group/t/how-to-solve-the-same-numerical-problem-in-7-different-programming-languages/3548/19 "2022-05-25T14:50:32Z")
> [@Carltoffel](#): > > IMHO, `implicit none` should be the default, at least for free form source code. @Carltoffel , @Pap , @conradoat , @jacobwilliams , and all other readers who would like to see `implicit none` be the default in a future revision of the Fortran standard: Please see this thread at GitHub J3-Fortran site for language proposals: > > > Issue #90 proposes to eliminate implicit typing in Fortran. There is strong res…istance to this, there being a major concern that to "eliminate implicit typing", if pursued with any seriousness, will require a deletion of the \`IMPLICIT\` statement from the language. There is great worry some existing code would break as a result. > > Can the Fortran community then coalesce to a somewhat simpler proposal, to eliminate implicit mapping instead? > > The main aspect of such a proposal is to primarily change one sentence in the section on IMPLICIT statement to introduce the following: > "\*\*If a mapping is not specified for a letter, the default for a program unit or an interface body shall be NULL, and the default for a BLOCK construct, internal subprogram, or module subprogram is the mapping in the host scoping unit\*\*" > > Note the current Fortran standard (document 18-007r1) instead states in section 8.7 \`IMPLICIT STATEMENT\` page 114, paragraph 3, lines 32-34, "\`If a mapping is not specified for a letter, the default for a program unit or an interface body is default integer if the letter is I, J, ..., or N and default real otherwise, and the default for a BLOCK construct, internal subprogram, or module subprogram is the mapping in the host scoping unit.\`" > > This one sentence in the current standard effectively ends up achieving backward compatibility with code written from the days of FORTRAN I where "ICARUS was an integer unless specified as REAL", to paraphrase a long-standing joke with FORTRAN! > > But now almost all the code written from the days of FORTRAN 77 then has tried to avoid the fate of the legend and not drown while trying to only take flight via the explicit use of the IMPLICIT statement, \`IMPLICIT NONE\` overwhelmingly but \`IMPLICIT INTEGER(I-N), xx(A-H, O-Z)\` {xx = \`DOUBLE PRECISION\`, \`REAL\`, \`REAL\*8\`, etc.\]. This proposal intends not to affect in any adverse manner any such existing code that makes explicit use of \`IMPLICIT\` statements. > > The intended benefit of this one change is to set in motion finally a positive change where \`IMPLICIT NONE\` becomes the \*\*default\*\* in any and all program units and in all the interface bodies, gone will be the need to ensure the inclusion of \`implicit none\` in a list of explicit interfaces: > \`\`\`Fortran > interface > function foo(..) result(..) > \[import .. \] > implicit none !\<-- Per current standard, forget this and face peril > .. > end function > function bar(..) result(..) > \[import .. \] > implicit none !\<-- Per current standard, forget this and face peril > .. > end function > subroutine foobar(..) > \[import .. \] > implicit none !\<-- Per current standard, forget this and face peril > .. > end subroutine > end interface > \`\`\` > Almost every processor tries to offer a compiler option to enforce the gist of this proposal, with \`fpm\` and LFortran considering making this even the default. Why not standardize all such good intent? > > What say you all, can you support this for Fortran 202Y? Please keep in mind even with 202Y, it may be year 2040 by the time this can become practicable. Is it not time now to start giving this a serious consideration? **If you agree with suggestion, will you please consider upvoting it?** You will know things change slowly, perhaps even more so than the wheels of justice (!!), in the “world of Fortran”. Should one begin chartering a new direction now, one will see begin sighting the light at the end of the tunnel only possible a decade plus from now. Hence I personally sense a pressing need and urgency to seek support from the wider community and this is where your upvote can help gain traction and influence on a simple change like this that can commence with Fortran 202Y. ---
**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\ **Post date:** [May 25, 2022, 2:51pm UTC](https://fortran-lang.discourse.group/t/how-to-solve-the-same-numerical-problem-in-7-different-programming-languages/3548/20 "2022-05-25T14:51:51Z")
> [@MarDie](#): > > But it does not have to appear in functions/subroutines because a single `implicit none` at the module level is sufficient @MarDie , but the current situation is pernicious with `INTERFACE` blocks that are effectively stand-alone constructs uninfluenced by a host and its `IMPLICIT` mapping - please see the link in my prior post: ```fortran interface function foo(..) result(..) [import ..] implicit none !<-- Per current standard, forget this and face peril .. end function function bar(..) result(..) [import ..] implicit none !<-- Per current standard, forget this and face peril .. end function subroutine foobar(..) [import ..] implicit none !<-- Per current standard, forget this and face peril .. end subroutine end interface ``` ---
**Author:** ![jacobwilliams](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jacobwilliams/32/10_2.png) [@jacobwilliams](https://fortran-lang.discourse.group/u/jacobwilliams)\ **Post date:** [May 25, 2022, 2:53pm UTC](https://fortran-lang.discourse.group/t/how-to-solve-the-same-numerical-problem-in-7-different-programming-languages/3548/21 "2022-05-25T14:53:40Z")
Yes this is just terrible. Why oh why doesn’t the implicit none in the module apply to the interface blocks? [Next page](https://fortran-lang.discourse.group/t/how-to-solve-the-same-numerical-problem-in-7-different-programming-languages/3548.md?page=2)