From jls@uxb.liv.ac.uk Tue Feb 9 10:29:39 1993 Received: from ib.rl.ac.uk by dkuug.dk with SMTP id AA29142 (5.65c8/IDA-1.4.4j for ); Tue, 9 Feb 1993 11:31:19 +0100 Received: from mail.liv.ac.uk by ib.rl.ac.uk (IBM VM SMTP V2R1) with TCP; Tue, 09 Feb 93 10:30:44 GMT Received: from uxb.liverpool.ac.uk by mailhub.liverpool.ac.uk with SMTP (PP) id <25550-0@mailhub.liverpool.ac.uk>; Tue, 9 Feb 1993 10:29:58 +0000 From: jls Message-Id: <455.9302091029@uxb.liv.ac.uk > Subject: HPF 1.0 chapter 5 To: hpf-comments@cs.rice.edu Date: Tue, 9 Feb 93 10:29:39 GMT Cc: SC22WG5@dkuug.dk (SC22/WG5 members) X-Mailer: ELM [version 2.3 PL11] X-Charset: ASCII X-Char-Esc: 29 Comment on HPF 1.0, Jan'93 Chapter 5, Intrinsic and Library Procedures My major comment on the chapter is on the lack of precision of the text. The Fortran 90 standard is a good example of how such intrinsic procedure libraries should be defined. The highly structured nature of the text in the standard ensures that each procedure is properly and fairly fully described. From a users point of view this is very important. In most cases the user of a particular facility will need only to consult the description for that facility. The current draft of HPF is very woolly and has important snippits of information scatted about so that it becomes necessary to read large swaths of the HPF document plus bits of the F90 document to get some idea of what is being suggested. The text reads more like a suggestion as to desirable functionalities rather than a set of precise definitions for a standard. The very general comment is therefore that this whole chapter needs to be rewritten using the section 13 of the Fortran 90 standard as the model, (or possibly the ISO Varying Strings in Fortran standard currently at the CD stage of processing could be used as a model). The following are some specific comments but these are far from exhaustive since I ran out of stamina and patience trying to make sence of much of the current description. 1. F90 does not, for very good reasons, assume a 2's complement representation for integers. It defines a model representation for numeric values based loosely on the Brown model. This is essentially a sign-modulus model for integers and all the intrinsic inquiry functions for intergers provide values by choosing a mapping of the actual representations onto this model. ILEN should be similarly defined. 2. The HPF mapping inquiry subroutines all suffer from complexity not fully or particularly well explained. Using the F90 document structure recommended above with some well chosen examples would help. The example shown on page 82 appears to have an error. The rank of A is declared to be 2, but the align-source-list attached to it in the directive has a length of 3. 3. The choice of putting the Computational Library procedures in an HPF module is to be applauded. However, since module names will be global it is critical that standardised module names are unique. They therefore need to be of a character that makes it unlikely that any user or any other group or body will by accident use the same name. A short name like HPF_LIB does not satisfy these criteria. It would be better to use something like HPF_COMPUTATIONAL_LIBRARY as well as being more precisely descriptive it is less likely to be used by any other group. The descriptions of these procedures are particularly poor. I assume these procedures are mostly generic but it is not specified over what set of types they are generic. (the procedure names should be defined as generic even if there is only one specific procedure involved as this can greatly ease future name space management for users of the module). There are a very large number of generic procedures defined in this module. When the number of specific variants is properly defined this number will be much greater. Without being an expert on all the application areas which might be affected I find it hard to say whether or not all these procedures are useful/needed, but I cant help feeling that many of them are perhaps a little obscure. A short rationale for the inclusion of some of the less obvious procedures with some indication of the likely application would be useful. 4. Should not the function LEADZ and ILEN be described in the same section of HPF and have the same status. They appear to produce values that are complementary and related to each other and the bitsize. -- Dr.J.L.Schonfelder Director, Computing Services Dept. University of Liverpool, UK Phone: +44(51)794 3716 FAX : +44(51)794 3759 email: jls@liv.ac.uk