On Tuesday, September 12, 2023 at 4:23:09 PM UTC+3, Ben Bacarisse wrote:
> Michael S <already...@yahoo.com> writes:
>
> > On Tuesday, September 12, 2023 at 2:26:49 AM UTC+3, Ben Bacarisse wrote:
> >> db <dieterh...@gmail.com> writes:
> >>
> >> > On 10.09.2023 15.22, Ben Bacarisse wrote:
> >> >> db <dieterh...@gmail.com> writes:
> >> >>
> >> >>> On 09.09.2023 11.02, Mut...@dastardlyhq.com wrote:
> >> >>>> On Sat, 9 Sep 2023 10:54:33 +0200
> >> >>>> db <dieterh...@gmail.com> wrote:
> >> >>>>> but now it says that C-double doesn't exist.
> >> >>>>>
> >> >>>>> Any ideas?
> >> >>>> C++ mangles function names so that the name you give the function isn't
> >> >>>> the
> >> >>>> name the dynamic loader sees in the binary. You need to put this around whatever
> >> >>>> function you want to call from Fortran so it has C style linkage which means
> >> >>>> the name remains the same:
> >> >>>> extern "C" {
> >> >>>> void calledFromFortran()
> >> >>>> {
> >> >>>> :
> >> >>>> }
> >> >>>> }
> >> >>>>
> >> >>> Where should this go in the code? I added it at the end as is,
> >> >>> and now I get this:
> >> >>>
> >> >>> ~/ownlib90/tests> ./jbandtest
> >> >>> jband.cpp:88:1: error: expected initializer before 'extern'
> >> >>> 88 | extern "C" {
> >> >>> | ^~~~~~
> >> >>> jband.cpp:96:1: error: expected unqualified-id before '{' token
> >> >>> 96 | {
> >> >>> | ^
> >> >>> jband.cpp: In function 'void calledFromFortran()':
> >> >>> jband.cpp:350:9: error: expected primary-expression before ':' token
> >> >>> 350 | :
> >> >>> ...
> >> >> You are giving people very little to go on. There's an unknown command
> >> >> (./jbandtest) the gives some errors where only one line of code can be
> >> >> seen.
> >> >> Can you produce a cut-down version to the program that shows the same
> >> >> error -- mimimal example of the C++ and of the Fortran that should
> >> >> calls it but which fails? That would mean you could post the code.
> >> >> If that is not possible, can you link to the source so those who know
> >> >> both C++ and Fortran can take a proper look?
> >> >
> >> > I put the C++ function here: www.dieterbritz.dk/jband.cpp
> >> > After getting errors about the extern lines, whch I had
> >> > added at the end, I shifted it to near the start:
> >> >
> >> > #include <iostream>
> >> > #include <fstream>
> >> > #include <iomanip>
> >> > #include "math.h"
> >> >
> >> > using namespace std;
> >> >
> >> > extern "C" {
> >> >
> >> > void calledFromFortran()
> >> > {
> >> > :
> >> > }
> >> >
> >> > }
> >> Remove them all. You have two options. One: correct the C++. To do
> >> this put this, and only this,
> >>
> >> extern "C" {
> >> const long double iband(const long double tbar);
> >> }
> >>
> >> just after the #include lines. This is perfect (the first const is a
> >> meaningless word here and the compiler may warn you about that) but it
> >> will do.
> >>
> >> Next replace
> >>
> >> #include "math.h"
> >>
> >> with
> >>
> >> #include <math.h>
> >>
> >> I'd also remove the two unnecessary #include lines (for iomanip and
> >> fstream). All of these are "tidying up". Only the extern "C" part I
> >> gave corrects an actual mistake.
> >>
> >> The second option is the turn the code in C which links directly with
> >> Fortran. The only C++ used by the code is one "cout << " line (not a
> >> good way to report an error, but that's not important right now) and a
> >> setting for pi that is not a compile-time constant (4*atanl(1)) written
> >> in a more fussy way.
> >>
> >> To convert to C, copy the file to jband.c (rather than .cpp) and replce
> >> the declaration for pi. Given the code is littered with explicit 21
> >> digits decimals (a little more than the precision of C's usualy long
> >> double type) I would just write
> >>
> >> static const long double pi = 3.14159265358979323846L;
> >>
> >> Now replace the cout line with
> >>
> >> fputs("\nError in stredges::iband(): tbar must be > 0", stderr);
> >>
> >> This writes the message to the error stream and put only these two
> >> include lines at the top:
> >>
> >> #include <math.h>
> >> #include <stdio.h>
> >>
> >> Now the file is C code.
> >>
> >> Frankly, this is the way I'd go, since linking C is just that bit
> >> simpler than linking C++. But if the code is going to become fully
> >> fledged (and complex) C++, obviously use my first option.
> >> > I still get errors pertaining to these lines. But after adding
> >> > the -c to the two compilation lines in the script, these are
> >> > now the only errors. I think I am getting closer. The errors
> >> > are now
> >> Yes, you must compile it like this:
> >>
> >> g++ -c jband.cpp (for C++ code)
> >> gcc -c jband.c (for C code)
> >>
> >> You don't need any -o but you could add in lots of warnings like
> >>
> >> gcc -Wall -Wextra -c jband.c
> >> > jband.cpp: In function 'void calledFromFortran()':
> >> > jband.cpp:12:9: error: expected primary-expression before ':' token
> >> > 12 | :
> >> > | ^
> >> > jband.cpp: At global scope:
> >> > jband.cpp:96:1: error: expected initializer before 'extern'
> >> > 96 | extern "C" {
> >> > | ^~~~~~
> >> > jband.cpp:104:1: error: expected unqualified-id before '{' token
> >> > 104 | {
> >> > | ^
> >> > jbandtest.f90:28:14:
> >> >
> >> > 28 | FORTJBAND = JBAND (tbar)
> >> > | 1
> >> > Error: Type mismatch in argument 'tbar' at (1); passed REAL(16) to REAL(10)
> >> >
> >> > The last error will go away together with the others.
> >> Michael S has given you one way to go for that. My comments were going
> >> to be more general. You have several ways of specifying the types, and
> >> I could not tell if you really wanted all of them. In general, I would
> >> define the Fortran types from the C ones (since those are the types you
> >> need for the call and return) and leave it at that.
> >>
> >> But the big one is that the Fortran code seems to think the function is
> >> called jband, when in fact it's called iband.
> >>
> >> I went for this:
> >>
> >> module STUFF
> >> use iso_c_binding
> >> integer, parameter :: qud=real(c_long_double)
> >> end module STUFF
> >> program JBAND_TEST
> >> use STUFF; implicit none
> >> real(qud) :: tbar, curr, FORTJBAND
> >> do
> >> read *, tbar
> >> if (tbar < 0) exit
> >> curr = FORTJBAND (tbar)
> >> print '(" curr =", f10.4)', curr
> >> enddo
> >> end program JBAND_TEST
> >>
> >> function FORTJBAND (tbar)
> >> use STUFF; implicit none
> >> interface
> >> function IBAND (tbar) bind(c)
> >> use STUFF
> >> real(qud), VALUE :: tbar
> >> real(qud) :: IBAND
> >> end function iband
> >> end interface
> >
> > I think, you are taking chances here. Even if it happens to work
> > on x86-64 Linux, it can fail on some other target where calling
> > conventions for long double return value in 'C' differ from those
> > of Fortran. The method shown in one of my previous posts
> > appear more robust:
> >
> > interface
> > real(c_long_double) function IBAND (tbar) bind(c)
> > import c_long_double
> > real(c_long_double), value :: tbar
> > end function IBAND
> I think I see -- keep the C-related types in the smallest interface? I
> didn't study your example, but the OP renamed the C function and gave
> the resulting Fortran function a native Fortran type. Is that what you
> advise?
>
> The OP should have taken your Fortran and applied my C++ edits. Maybe
> they took my Fortran and it did not work on Windows. That would be a
> shame.
> >> BTW, you said the C++ was written by a C++ expert. I don't think it
> >> was!
> >
> > With no relationships to C, C++ or Fortran, I don't like the way they
> > evaluate their polynomials from numerical perspective . But I assume
> > that algorithm was copied 'as is' from 40 y.o. book so it's not a
> > fault of C++ programmer.
> I was just remarking on the C++ itself which has some 'non-expert'
> attributes.
> > Despite my disliking, their method is good enough to achieve their modest
> > specified goal for relative accuracy: of 14-15 significant digits.
> > With smarter method the same or better accuracy can be achieved using
> > standard 'double" arithmetic (IEEE-754 binary64) thus making the routine
> > portable to platforms that have no support for extended precision
> > math.
> Interesting. I don't know the function being evaluated at all.
>

I don't know it either. But I had drawn the graphs and looked at
coefficients in two ranges where precision is worst: [0.0081: 0.0158] and
[0.0158:0.0631].
A simple affine transform of the polynomial could either improve precision
of result by 4 orders of magnitude or reduce needs for precision of arithmetic
by 3 orders of magnitude while still somewhat improving the precision of result.
I'd guess, more advanced techniques can improve it further in both dimensions,
but low hanging fruits first.

> --
> Ben.