Fortran Vs C, C++, C#
in [Fortran]
|
Prev: practice online trading. platinum online trading. online trading worldwide. online trading which is best
Next: variant data type
From: Robert Myers on 5 Jul 2010 13:08 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 5 Jul 2010 13:37 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 5 Jul 2010 14:01 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 5 Jul 2010 14:55 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 6 Jul 2010 08:46
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 |