From: Robert Myers on
Gordon Sande wrote:

> If one uses F90 the number of errors
> that the compiler can catch are pretty impressive. C does not quite
> match F77 on that.

Very tactfully stated.

Limitations on aliasing in Fortran sometimes allow the compiler to
optimize in ways that are not possible in c because the compiler can't
be sure if two sets of symbols don't refer to the same memory location.
It is also possible to use bounds checking in Fortran and not in c.

On the other side of the ledger, you would really have to abuse Fortran
to write system code in Fortran.

Robert.
From: dpb on
viper-2 wrote:
....

> Why fight the issues? Actually, I suspect that some Fortraners hack
> numerical problems in Fortran, and then interface the code with C to
> accomplish performance tweaks at low level. That might be one way to
> go?
....

In my experience/working universe I'd say for that reason the number
that do that are miniscule.

If the code is written Fortran the reason for interfacing to C will be
either for system-dependent stuff or external libraries that don't have
Fortran bindings available or similar. Oh, there's also the "management
decision" that occasionally decrees new code _shall_ be written in the
language du jour; I've run into that more than once as well (most
particularly common in a former life in DOE lab-settings years ago).

One pita-type problem is the mismatch between normal storage order in C
vis a vis Fortran...resolvable, of course, but a nuisance factor.

--
From: Gordon Sande on
On 2010-07-05 13:48:49 -0300, viper-2 <agt(a)codeartnow.com> said:

>
> A goodly variety of details are predetermined so that the programmer
>> can pay more attention to relevant issues. If you insist on fighting those
>> details then Fortran is not for you
>
> Why fight the issues? Actually, I suspect that some Fortraners hack
> numerical problems in Fortran, and then interface the code with C to
> accomplish performance tweaks at low level. That might be one way to
> go?

Not likely! Fortran compilers are more likely to generate good code
than C compilers. Fortran can be more agressive in optimizations due
to the prohibitions on aliasing as well as a client base that has
different expectations.




From: Steven Correll on
On Jul 1, 3:17 pm, Gib Bogle <g.bo...(a)auckland.no.spam.ac.nz> wrote:
> It's a bit inconvenient that an array element must be accessed as
> (*parray)[x][y], and also a bit confusing since this is not required in the case
> of the old 1-D array.
>    float (*b)[10] = malloc(10*sizeof(float));
> and
>    float *b = malloc(10*sizeof(float));
> have the same effect, but in the latter case the elements are accessed by b[i],
> while in the former by (*b)[i].

Google groups seems to have eaten my first attempt, but excuse me if
the following is a repetition:

Actually you can do the analogous thing to achieve a 2D array: just as
you can access an implicit 1D array by indexing a pointer to scalar,
you can access an implicit 2D array by indexing a pointer to a 1D
array, as shown in the example below. Neither the implicit nor
explicit 2D array declarations are new in C99, so I've also added to
this example an illustration of the feature which is new in C99,
namely the equivalent of a Fortran adjustable array:

$ cat ctest1.c
#include <stdio.h>
#include <stdlib.h>

static void
printimplicit(int xdim, int ydim, float (*implicit)[]) {
for (int x = 0; x < xdim; x += 1) {
for (int y = 0; y < ydim; y += 1) {
printf("%g ", (*implicit)[ydim * x + y]);
}
printf("\n");
}
}

static void
printexplicit(int xdim, int ydim, float (*explicit)[xdim][ydim]) {
for (int x = 0; x < xdim; x += 1) {
for (int y = 0; y < ydim; y += 1) {
printf("%g ", (*explicit)[x][y]);
}
printf("\n");
}
}

int
main(int argc, char **argv) {
int xdim = argc;
int ydim = argc + 1;
float (*implicit)[ydim] = malloc(xdim * ydim * sizeof(float));
float (*explicit)[xdim][ydim] = malloc(xdim * ydim * sizeof(float));
for (int x = 0; x < xdim; x += 1) {
for (int y = 0; y < ydim; y += 1) {
implicit[x][y] = 10 * x + y;
(*explicit)[x][y] = 10 * x + y;
}
}
printimplicit(xdim, ydim, implicit);
printexplicit(xdim, ydim, explicit);
return 0;
}

$ gcc -std=c99 ctest1.c
$ ./a.out 1 2
0 1 2 3
10 11 12 13
20 21 22 23
0 1 2 3
10 11 12 13
20 21 22 23
$

From: viper-2 on
On Jul 5, 2:01 pm, Gordon Sande <Gordon.Sa...(a)gmail.com> wrote:
>
> > Why fight the issues? Actually, I suspect that some Fortraners hack
> > numerical problems in Fortran, and then interface the code with C to
> > accomplish performance tweaks at low level. That might be one way to
> > go?
>
> Not likely! Fortran compilers are more likely to generate good code
> than C compilers. Fortran can be more agressive in optimizations due
> to the prohibitions on aliasing as well as a client base that has
> different expectations.

On Jul 5, 1:37 pm, dpb <n...(a)non.net> wrote:
>
>
> In my experience/working universe I'd say for that reason the number
> that do that are miniscule.
>

Obviously, I have a lot of catching up to do.:-)


agt

--
Freedom - no pane, all gaiGN!

Code Art Now
http://codeartnow.com
Email: agt(a)codeartnow.com