Hi,
I am trying figure out a way to use the gsl_root_fsolver_bisection function from the gsl. I just learnt how to compile and link the library with my Fortran program, but I can figure out how to use the above function and the manual doesn’t state what sort of arguments are passed to it.
May I have a small working example ?
The manual reference page is : pg 439 section 36.8
Thanks
FYI: if you want pure Fortran root solvers like Bisection, you could also use this library:
Usually, bisection is the least efficient way to solve bracketed root finding problems, so also look at the other methods available in roots-fortran (which has many more methods of this type than GSL).
I would definitely use this if I knew how to use the fpm. Unfortunately I can’t ,yet. 
I have however bookmarked your project on Github
Also I wanna practice using the gsl to gain access to other things like the optimisation functions.
Just curious, an irrelevant question actually,
does anyone know if there is any Fortran package which is somewaht similar with GSL?
The complete range of subject areas covered by the library includes
Or, from the list above, is there some function areas only contained in GSL?
In other words, is there some function areas that we cannot find similar Fortran code?
Just curious.
I have marked @jacobwilliams post as the answer, as it seems to be a better solution.
There is also a fortran interface to GSL: GitHub - reinh-bader/fgsl: Fortran interface to the GNU Scientific Library
There is FGSL mentioned in the previous post; as far I know even if GSL is in C it doesn’t really impact the Fortran caller; the FGSL interface adds a wrapper layer, so you don’t need to explicitly import any C types (one area I’m not 100 % sure is if GSL provides any interfaces accepting callbacks and if yes, whether those require the bind(C) annotation).
For each of sub-topic in the GSL list you can find dozens of similar libraries, but scattered across various sites and from different providers (e.g. Netlib, ACM TOMS Collection, individual academic groups, individual researchers and Fortran professionals, …). The Fortran-Lang package index lists a few of these.
I bet there are dozens if not thousands of Fortran scientific routines hidden/“lost” in various university and scientific institute archives, not to mention at big organizations in the engineering & scientific fields (Petrobras, Shell, NASA, Boeing, Lockheed, (former) AT&T, Pentagon, CSIRO, …). All these engineers and experts are part of the silent majority:
In software development, the silent majority are the engineers who write the code, debug the programs, and solve the complex issues behind the scenes. They do not participate in controversial discussions about Visual Basic or Pascal — they just do their work in those languages without even knowing that there’s so much controversy surrounding their language of choice.
Without this silent majority, many projects would, in fact, grind to a halt. It is often their quiet diligence that keeps a project on track and prevents it from falling apart.
I’m not familiar enough with all of the areas to comment; the advantage of GSL I’d say is having everything in one place with a consistent programming conventions and a unified documentation. With function areas, I assume you are talking about numerical/mathematical/statistical codes; a lot of new works and algorithms are being written in MATLAB/Julia/Python/R. Machine learning (neural networks) is one of the areas which comes to mind (yes, we have neural-fortran and a few other libraries, but these very small compared to other langauges). Image manipulation is another area where I’ve used great tools in Python (scikit-image), Java (ImageJ), MATLAB (Image Processing Toolbox, Computer Vision toolbox). At a technical level, I think Fortran has a lot of features which would be useful to write image processing tools, however the fact it is rarely taught in computer-science departments (or other departments for that matter), means that other languages are favoured instead. Historically, I’d guess that astronomy was likely Fortran heavy, but I’m sure they use other languages today.
In any case, the needs and tastes of programmers vary strongly. I’ve encountered a few cases of Python users who don’t want to use SciPy as it brings in a lot of sub-dependencies and packages they may not even need, not to mention heavy tools like C and Fortran compilers. In these cases people decide to roll out their own packages which overlap with SciPy in terms of functionality but are focused on a single type of problem and more lightweight.