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 1 Jul 2010 13:14 Lynn McGuire wrote: > > Actually, the most programmed platform nowadays is in the mobile > devices, notably the smart phones, which are mostly the ARM cpu. > http://en.wikipedia.org/wiki/ARM_architecture > http://www.arm.com/about/newsroom/19720.php > The ARM cpu is a RISC architecture and has it's own assembler > language that is not x86 compatible. > I had made the naive assumption that someone asking about Fortran was not programming a smart phone. Conceivably, there are DSP people out there who might be interested in Fortan and programming something other than x86. If you're interested in speed, no matter the context, I stand by my comments. As to describing an "architecture" (as opposed to the ISA) as "RISC," I think we are living on different planets. Robert.
From: Steven Correll on 1 Jul 2010 13:44 > glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > I believe that C99 has variable dimension automatic arrays. > I haven't tried them yet. > Ron Shepard <ron-shep...(a)nospam.comcast.net> wrote: > Can you allocate these multidimensional arrays with malloc() (or > some other library routine) in the same routine that they are used? Below is an example of a dynamically allocated C99 2D variable length array using gcc. (As I wrote it, I realized that I ought to remember to be more grateful for the ability to write something like "print *, parray" in Fortran.) Note that once you have created such an array, if you want to pass it as an actual argument to another function, you the programmer must pass the bounds along with the array. In Fortran terms, C99 added adjustable arrays to the assumed-size arrays which it inherited from K&R C, but still does not provide assumed-shape or deferred-shape arrays. In compiler-implementation terms, a C99 pointer to a variable length array is still a simple memory address, not a dope vector containing information about the array bounds. #include <stdio.h> #include <stdlib.h> int main(int argc, char **argv) { int xdim = argc; int ydim = argc + 1; float (*parray)[xdim][ydim] = malloc(xdim * ydim * sizeof(float)); for (int x = 0; x < xdim; x += 1) { for (int y = 0; y < ydim; y += 1) { (*parray)[x][y] = 10 * x + y; } } for (int x = 0; x < xdim; x += 1) { for (int y = 0; y < ydim; y += 1) { printf("%g ", (*parray)[x][y]); } printf("\n"); } return 0; } $ gcc ctest.c -std=c99 $ ./a.out 0 1 $ ./a.out 1 0 1 2 10 11 12 $ ./a.out 1 2 0 1 2 3 10 11 12 13 20 21 22 23
From: Louis Krupp on 1 Jul 2010 13:55 On 7/1/2010 7:26 AM, robin wrote: > "glen herrmannsfeldt"<gah(a)ugcs.caltech.edu> wrote in message news:i0grfv$ije$2(a)speranza.aioe.org... > | Lynn McGuire<lmc(a)winsim.com> wrote: > | (snip) > | > |> 48 bit char pointer and 32 bit integer pointer, nasty ! > | > |> When we ported our fortran to the IBM mainframe from the Univac 1108 > |> in 1975, we ran into a major problem. All of the machines that we > |> had supported to that date were 36 bits or more using 6 bit bytes. > |> So, our hollerith had 6HABCDEF all over the place. We had to > |> change that to 4HABCD plus 2HEF. It was a major effort to change. > | > | Some might have instead used REAL*8 (or DOUBLE PRECISION). > | It is convenient of S/360 not to normalize data on load > | store operations. > > The S/360 has nothing to do with the topic. > In any case, INTEGER would have provided an appropriate > choice. > > Not if you want to store an eight-byte string in one variable; then you need double precision. Burroughs Large Systems also didn't normalize floating point data under at least certain circumstances. Many years ago, I ported a 3-D perspective plot package, PUREJOY, from CDC (6600?) to a B6700. Early plots had weird spikes which came from the meta-data (for lack of a better term) that the CDC code put in the low-order three or so bits of coordinates. The CDC apparently normalized these variables so the low-order bits didn't change the value much, but the B6700 FORTRAN code had to be told to force normalization somehow (the instruction set included a NRML operator or something, but I don't recall how I did this in FORTRAN) before diddling with the low-order bits. Louis
From: glen herrmannsfeldt on 1 Jul 2010 14:28 Steven Correll <steven.correll(a)gmail.com> wrote: >> �glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: >> I believe that C99 has variable dimension automatic arrays. >> I haven't tried them yet. >> Ron Shepard <ron-shep...(a)nospam.comcast.net> wrote: >> Can you allocate these multidimensional arrays with malloc() (or >> some other library routine) in the same routine that they are used? > Below is an example of a dynamically allocated C99 2D variable length > array using gcc. (As I wrote it, I realized that I ought to remember > to be more grateful for the ability to write something like "print *, > parray" in Fortran.) I find it interesting that PRINT was in Fortran I and Fortran II, but removed during the change to Fortran IV and Fortran 66, then added back later. (Though the older form required a format statement number, with no option for *. > Note that once you have created such an array, if > you want to pass it as an actual argument to another function, you the > programmer must pass the bounds along with the array. In Fortran > terms, C99 added adjustable arrays to the assumed-size arrays which it > inherited from K&R C, but still does not provide assumed-shape or > deferred-shape arrays. In compiler-implementation terms, a C99 pointer > to a variable length array is still a simple memory address, not a > dope vector containing information about the array bounds. Note though, at least as far as I can tell, the dimensions need to be known at block entry, similar to Fortran 66 adjustable arrays, though with the ability to allocate them. > #include <stdio.h> > #include <stdlib.h> > int > main(int argc, char **argv) { > int xdim = argc; > int ydim = argc + 1; > float (*parray)[xdim][ydim] = malloc(xdim * ydim * sizeof(float)); It might be a little less confusing, especially to those who don't do a lot of C programming, to write it as: float (*parray)[xdim][ydim]; parray = malloc(xdim * ydim * sizeof(float)); Specifically, it declares a pointer to a 2D array, and then allocates memory for the pointer. Also, for Fortran programmers not so used to C, float *x[3][3]; // declares a 2D array of pointers float (*x)[3][3]; // declares a pointer to a 2D array float (*x[3])[3]; // declares an array of pointer to arrays > for (int x = 0; x < xdim; x += 1) { > for (int y = 0; y < ydim; y += 1) { > (*parray)[x][y] = 10 * x + y; > } > } > for (int x = 0; x < xdim; x += 1) { > for (int y = 0; y < ydim; y += 1) { > printf("%g ", (*parray)[x][y]); > } > printf("\n"); > } > return 0; > } And note that you really don't need C99, all you need is cpp: #define x(i,j) (*(x+((i)-1)*(n)+(j)-1)) which, unless I typed wrong, gets you a variable dimension, origin 1, allocatable and changable dimension array that you even reference like a Fortran array. Or, to be even more Fortran like: #define x(i,j) (*(x+((j)-1)*(n)+(i)-1)) -- glen
From: glen herrmannsfeldt on 1 Jul 2010 14:38
Louis Krupp <lkrupp_nospam(a)indra.com.invalid> wrote: > Not if you want to store an eight-byte string in one variable; > then you need double precision. It seems that Robin missed that part. > Burroughs Large Systems also didn't normalize floating point data under > at least certain circumstances. Many years ago, I ported a 3-D > perspective plot package, PUREJOY, from CDC (6600?) to a B6700. Early > plots had weird spikes which came from the meta-data (for lack of a > better term) that the CDC code put in the low-order three or so bits of > coordinates. The CDC apparently normalized these variables so the > low-order bits didn't change the value much, but the B6700 FORTRAN code > had to be told to force normalization somehow (the instruction set > included a NRML operator or something, but I don't recall how I did this > in FORTRAN) before diddling with the low-order bits. There are some Burroughs machines that store integer and floating point in the same format. The exponent is arranged such that it is zero for an appropriately unnormalized integer value, and is the prefered exponent result if no bits are lost. Fortunately Fortran leaves the results of overflow undefined, as users of those machines will be very surprised. -- glen |