hshankar@sim.Berkeley.EDU (RAMACHANDRAN HARISHANKAR) (03/12/88)
I must disagree that the strong typing available in pascal and c and ada is sufficient <or necessary> for fortran users. First, I have never found the need for structures in my numerical programming. The data structures are simply not that complex. So adding that feature simply complicates life for insufficient reason. Second <and far more important> the kind of strong typing available in pascal does not handle tensors and units. In the example given <length*time = velocity I think> if we defined variables with appropriate types, pascal would still not allow us to check for that error. In one of my programs I had a large number of multidimensional arrays, with nearly all dimensions that same <either 2 or 5>, but with very specific physical meaning. So it was alright to contract the 2nd row of A with the 3rd column of B, but not with the 4th column, even though the dimensions agreed. The resulting mess took me months to work out, and I finally did so by the use of a precompiler that enforced my strong typing for me. So fortran DOES need strong typing, and it needs a version of it that is quite different from pascal and c. <ada I am not familiar with and cannot comment on> A more general example is the need to distinguish covarient and contravarient indices in a tensor. Both are indices going from 1 to 4. But never should we allow covarient to contract with covarient and vv. I do not know of an algorithm that will allow fortran to enforce this, but I do know that pascal does not. [I learnt the language for that purpose and found it unsuitable] Third, pascal and c compilers <that I have encountered> lack the complex type, and most of my programming is in the complex plane. Fourth, invisible coddling by a language is VERY beneficial to those of us who are not master programmers. When I program I use all sorts of horrible constructs, knowing that if it is wrong the compiler will catch me out. I don't make a career of programming. It is just a tool to use in doing research. So I expect to find safeguards to protect me from myself. I believe that a very large number of scientists are in the same boat. In short, I don't care about structured constants and typedefs and things like that, but DO care to have the ability to associate units with dimensions. That is a very important and useful capability. Many mathematical aids now a days have this ability, and it is there because physicists think better in terms of conceptual formulae than in terms of computerese. <apologies for the long posting> hari ramachandran.
zdenko@csd4.milw.wisc.edu (Zdenko Tomasic) (03/13/88)
In article <1456@pasteur.Berkeley.Edu> hshankar@sim.Berkeley.EDU.UUCP (RAMACHANDRAN HARISHANKAR) writes: >I must disagree that the strong typing available in pascal and c and ada is >sufficient <or necessary> for fortran users. > >First, I have never found the >need for structures in my numerical programming. The data structures are ^^^^^^^^^^^^^^^^^^^ >simply not that complex. So adding that feature simply complicates life >for insufficient reason. This depends a lot on what you are doing and how. If you are used to basic data structures, you may already be conditioned to consider them exclusively and not even consider anything else (why bother learning new stuff when a quick hack along old lines seems to suffice or does it?). Thus, you may subconsciously limit yourself and potentially miss a data structure that might be more convenient or efficient. It seems to me that in your tensor example below a new data structure (user defined?) is what you really need. Object oriented programming should probably be considered also, but I do not know enough about it to be specific. Someone will doubtlessly pick up on that. > >Second <and far more important> the kind of strong >typing available in pascal does not handle tensors and units. In the example >given <length*time = velocity I think> if we defined variables with appropriate >types, pascal would still not allow us to check for that error. In one of >my programs I had a large number of multidimensional arrays, with nearly >all dimensions that same <either 2 or 5>, but with very specific physical >meaning. So it was alright to contract the 2nd row of A with the 3rd column >of B, but not with the 4th column, even though the dimensions agreed. The >resulting mess took me months to work out, and I finally did so by the >use of a precompiler that enforced my strong typing for me. So fortran >DOES need strong typing, and it needs a version of it that is quite different >from pascal and c. <ada I am not familiar with and cannot comment on> > >A more general example is the need to distinguish covarient and contravarient >indices in a tensor. Both are indices going from 1 to 4. But never should >we allow covarient to contract with covarient and vv. I do not know of an >algorithm that will allow fortran to enforce this, but I do know that pascal >does not. [I learnt the language for that purpose and found it unsuitable] > The above just proves the need for the user defined data structures and operations. No compiler (or compiler writer, language designer) can predict all the needs of the world, just the most common ones. However one should be careful with customized definitions, else the eventually data structure extensible languages may end up being a big mess rather than help. Make a new structure only if you really need it and it cannot be easily achieved through the common ones. >Third, pascal and c compilers <that I have encountered> lack the complex >type, and most of my programming is in the complex plane. > This just indicates that they are not best tools for nontrivial numerical analysis or math programming. However, that by itself does not mean they cannot be improved or extended for purposes other than what they have been designed (pascal-teaching novice programming, c-systems programming). >Fourth, invisible coddling by a language is VERY beneficial to those of >us who are not master programmers. When I program I use all sorts of horrible >constructs, knowing that if it is wrong the compiler will catch me out. I >don't make a career of programming. It is just a tool to use in doing research. >So I expect to find safeguards to protect me from myself. I believe that >a very large number of scientists are in the same boat. > This is a dangerous attitude if you believe that compiler is responsible for catching all your errors so you will not have to think about it. There are definite limits on compiler error checking and they can mostly be limited to syntactical check and partly semantics. No compiler can read your mind and know what you actually want. Those which try to do that can mislead you and confuse more than you ever thought possible. After all, compilers do not have intelligence, just compiler writers(?) :-) and they are all too human too. >In short, I don't care about structured constants and typedefs and things >like that, but DO care to have the ability to associate units with dimensions. >That is a very important and useful capability. Many mathematical aids >now a days have this ability, and it is there because physicists think >better in terms of conceptual formulae than in terms of computerese. > ><apologies for the long posting> > >hari ramachandran. In short, even if you do not intend to be professional programmer, you must know your tool and know it well. There is no substitute for clear thinking, YOUR thinking. Zdenko Tomasic UWM, Chem. Dept. Milwaukee,WI,53201 __________________________________________________________ UUCP: ihnp4!uwmcsd1!csd4.milw.wisc.edu!zdenko ARPA: zdenko@csd4.milw.wisc.edu __________________________________________________________
hshankar@sim.Berkeley.EDU (RAMACHANDRAN HARISHANKAR) (03/15/88)
In article <5208@uwmcsd1.UUCP> zdenko@csd4.milw.wisc.edu (Zdenko Tomasic) writes: >In article <1456@pasteur.Berkeley.Edu> hshankar@sim.Berkeley.EDU.UUCP (RAMACHANDRAN HARISHANKAR) writes: >>The kind of strong >>typing available in pascal does not handle tensors and units. >> >>A more general example is the need to distinguish covarient and contravarient >>indices in a tensor. Both are indices going from 1 to 4. But never should >>we allow covarient to contract with covarient and vv. I do not know of an >>algorithm that will allow fortran to enforce this, but I do know that pascal >>does not. [I learnt the language for that purpose and found it unsuitable] >> > >The above just proves the need for the user defined data structures >and operations. No compiler (or compiler writer, language designer) >can predict all the needs of the world, just the most common ones. >However one should be careful with customized definitions, else >the eventually data structure extensible languages may end up being >a big mess rather than help. Make a new structure only if you really >need it and it cannot be easily achieved through the common ones. > I would think that it is precisely such cases - data structures that represent common physical objects - where we need specific implementations. I don't care WHO does it; ie whether it is done in a macro or in the compiler, but would want the ability to enforce tensor relationships. As far as I know, the kind of user defined data structures that have been proposed do not make tensors possible. Similarly, the user defined data structures also do not make associating quantities with units possible. <I am basing this statement on my experiences with Pascal and C, so it may not be true for the proposed Fortran standard>. Another example: If I want an array of structures, it is very easy to create, once I have the structure defined. But if I want the STRUCTURE of the array to be a group, then very difficult. ie, if I wanted to refer to <say> the velocity field of a flow on a torus, I define a coordinate system on the torus as (x,y), each coordinate is modulo 2 pi. The velocity field would consist of 2 entries at each (x,y). So EXTREMELY simple structure. <tangent space is just R X R> What is complex is the way the indices interact. If I store 40 points for the 2 pi range, then I would want the entry at (64,38) to be identified with the entry at (24,38). In practice, for each reference of this data type, I would apply the modulo operator to the arguments. And frequently I do this using a preprocessor. However this is possible only because of the extremely simple nature of the example. I am not aware of any way in which user defined data structures make this possible. And I feel that this is the kind of data structures that is really useful in mathematical physics. The elements of the system are invariably in a tangent space, and so well suited to Fortran's existing data structures. It is the interconnections among the indices that messes things up. To me this kind of data structure definition ought to be as accessible as the kind available for Pascal and C. It makes the transfer of ideas to program that much easier, which in the ultimate analysis is the justification of language features. > >Zdenko Tomasic harishankar ramachandran u.c. berkeley