gsg0384@uxa.cso.uiuc.edu (01/08/89)
Regarding to my original posting <117400002@uxa.cso.uiuc.edu> from gsg0384@uxa.cso.uiuc.edu : >1. What languages support the run-time array sizing in a particular module >as in FORTRAN 8x ? ... I appreciate many kind replies from net landers, Particular thanks to Roberts. I am sorry not to be specific in my original posting. Now I think I may understand the cost of dynamic *local* array sizing. But I think we, stone-age FORTRAN programmers, usually physicists, mecha- nical engineers, and civil engineers, need that feature desperately. Otherwise, we should always provide the source code to the customer so that he can redimension for the memory size of his hardware. By 'run-time array sizing', I meant the following practice in Turing. var n:int put "Give size." get n var a:array 1..n of real /* Now I can use the dynamic array a[i], i = 1, ..., n. */ By 'to dimension a local array dynamically', I meant the following practice in CRAY UNICOS' ftn77 vectorizing compiler's extension to FORTRAN 77. subroutine routine(n) integer n real a(n) c Now I can use *local* array a(i), i = 1, ..., n for CRAY II only. Too often I cannot help thinking that the CStists do research on what they like to do, but not on what most users want them to do. The result is that we still don't have a language any better than FORTRAN 77 for our purpose, as is stated in Press et al.'s 'Numerical Recipe in C'. G. Hugh SONG gsg0384@uxa.cso.uiuc.edu U. of Illinois at Urbana-Champaign
sommar@enea.se (Erland Sommarskog) (01/12/89)
G Hush Song (gsg0384@uxa.cso.uiuc.edu) writes: > var n:int > put "Give size." > get n > var a:array 1..n of real > /* Now I can use the dynamic array a[i], i = 1, ..., n. */ >... > subroutine routine(n) > integer n > real a(n) >c Now I can use *local* array a(i), i = 1, ..., n for CRAY II only. Don't know really what your problem is, but both Ada and Algol supports this. -- Erland Sommarskog ENEA Data, Stockholm This signature is not to be quoted. sommar@enea.se
sam@csri.toronto.edu (Samuel Weber) (01/15/89)
In article <117400003@uxa.cso.uiuc.edu> gsg0384@uxa.cso.uiuc.edu writes: > >Regarding to my original posting > ><117400002@uxa.cso.uiuc.edu> from gsg0384@uxa.cso.uiuc.edu : >>1. What languages support the run-time array sizing in a particular module >>as in FORTRAN 8x ? ... > >By 'run-time array sizing', I meant the following practice in Turing. > example deleted > >By 'to dimension a local array dynamically', I meant the following practice >in CRAY UNICOS' ftn77 vectorizing compiler's extension to FORTRAN 77. > > subroutine routine(n) > integer n > real a(n) >c Now I can use *local* array a(i), i = 1, ..., n for CRAY II only. Unless I misunderstand you, you can do this in Turing as well. Example: procedure routine(n:int) var a:array 1..n of real % now you can use the *local* array a(i), i=1,...n >Too often I cannot help thinking that the CStists do research on what they like >to do, but not on what most users want them to do. The result is that >we still don't have a language any better than FORTRAN 77 for our purpose, >as is stated in Press et al.'s 'Numerical Recipe in C'. I am sorry to say that I'm not up on my FORTRAN 77. What is there in that language that is not in Turing? Also, have you looked at Numerical Turing? It is being developed here, and has a number of quite nice features for numerical analysis. For example, real numbers can have thousands of digits of accuracy, and arithmetic on them is (of course) carried out to this degree of precision. The precision is controllable dynamically (ie. at any time the program can 'decide' that it need to use, say 10 more digits of accuracy, and from then calculations, and variable declarations, are carried out with the increased number of digits). Also, you can trap exceptions, such as overflow, underflow, divide by zero, etc, and decide what to do to recover from them. At this point I bet there are some systems people protesting "But what hardware can support arithmetic with thousands of digits of accuracy?" The answer is that if the precision is too great to do with the hardware then software routines are called on to do it. Of course, this makes calculations with ultra-high precision slow, but then if you have a problem which requires 1000 digits of precision, you get rather annoyed when a system hack tells you "You can only get 16, but it's going to be fast!" Does that make you feel better about us computer scientists? > G. Hugh SONG > gsg0384@uxa.cso.uiuc.edu > U. of Illinois at Urbana-Champaign -- --Sam Weber "Little Birds are teaching sam@csri.toronto.edu Tigresses to smile, Innocent of guile: Smile, I say, not smirkle-- (quote by Mouth a semicircle, Lewis Carroll) That's the proper style."