MATH Package Study Subgroup From: Chuck Swart To: Interested Parties Date: June 22,1993 Subject: Minutes on MeetTH Package Study Subgroup From: Chuck Swart To: Interested Parties Date: June 22,1993 SUMMARY This meeting took place at T.I. (DASC meetings following DAC) from 9:00 a.m. until 2:00 p.m. with the following participants: Chuck Swrt, Mentor, chuck_swart@mentorg.com John Hines, Wright-Patterson AFB, hines@el.wpafb.af.mil Rita Glover Documentation and Design Services, ritag@doc.com Clive Charlwood, Synopsys, crc@synopsys.com Alex Zamfirescu, Vantage, a.zamfirescu@ieee.org Neal Stollon, TI, Attendance was sporadic, with people coming into and out of the meeting. There were never more than three people in the meeting at any one time. Consequently, although, several issues were raised and progress was made on a number of items, no issues could really be closed out. 2. Items Related to PAR approval, coordination with analog working group, etc. We now have a PAR 1076.2. John Hines has the action item to check with IEEE on forming a ballot constituency using the VHDL 92 ballot group as the starting point. Rita Glover has agreed to help with final document preparation for voting on the package. 3. Coordination with analog working group. Jean-Michel Berge has the action item to submit analog requirements to the math working group. Alex Zamfirescu pointed out that analog plans on requiring a new real type called FLOAT. This type will require greater accuracy than the current REAL type. This requirement poses a problem for the math package, which is intended to be compatible with current requirements on real numbers in VHDL. One possible solution is to develop two math packages, one with functions which work on type REAL, the other with similar functionality, which uses the new type FLOAT. (Since the COMPLEX package is intended to support analog needs, complex numbers should probably be based on FLOATs.) One consequence of such a decision is that we could ballot the REAL based math package almost immediately and could ballot the FLOAT and COMPLEX packages at the same time that analog is balloted. 4. Examining Needs for Additional Functionality. Neal Stollon suggested that we contact the company Math Cad (??) to see if our math package is adequate. Chuck Swart recommended that we submit our package headers to the net news group comp.lang.vhdl and ask for comments. Neal Stollon again asked for more distributions than uniform and for even and odd functions. 5. Developing a test bench. Jose Torres did not report on whether he had contacted Don Hanson about the useability of the Ada test suite as a basis for the math functions test bench. John Hines has the action item to look into obtaining NBS FORTRAN tests of math functions. Chuck Swart has the action item to see whether Mento Graphics tests of their math package can be used as a basis for the test bench. 6. Feedback on PROPOSAL AT THE MEETING It was noted that the FOREIGN attributes on functions SRAND, RAND, and GET_RAND_MAX is non-portable. In addition, different vendors are likely to use different FOREIGN strings for their implementations. Clive Charlwood suggested that we use the FOREIGN attribute to describe the particular function and that complying vendors would then have to recognize particular strings to be compliant. For example, the SRAND function might have FOREIGN attribute "MATH_SRAND" It was suggested that we examine how analog has dealt with this problem, since they almost certainly will use foreign procedures. It was felt that keeping hooks to the standard C random functions was a good idea. A few very small nits were reported by Chuck Swart: The note on GET_RAND_MAX should read "--Note: the value of ( REAL(RAND()/ REAL(GET_RAND_MAX()) is a" Somewhere we agreed that the functions were required to check for valid input values (I have been unable to find this requirement) However, the tangent function doesn't do this check. Should this be added or not? A more serious related problem is that package implementations which use C library functions and the like do not have a guarantee that inputs will be checked for validity. Are implementations which do not use the supplied package body required to report the same errors? Several subprograms have variables declared which should really be constants, since their values are not changed within the subprogram. One example of this is in the CEILING function "variable large: real := 1073741824.0;" should more accurately be "constant large: ..." This is largely a matter of style. 7. BEST QUOTE AT THE MEETING Victor Berman, when discussing portability problems with reals: "Real numbers are unreal."