Minutes from December meeting
Linda Stanberry
uunet!ocfmail.ocf.llnl.gov!linda
Mon Jan 4 11:53:41 PST 1993
Enclosed are the minutes from the December meeting of X3J11.1 (NCEG).
There are some omissions in this text--whitespace where non-ASCII characters
(like the infinity symbol) should appear. These characters will not be
omitted in the copy distributed with the mailing, but for electronic
distribution, ASCII text is preferred. The postscript version with all
the characters is available electronically on request.
Linda Stanberry
lindaaocfmail.ocf.llnl.gov
----------------------------------------------------------------------------
Minutes of X3J11.1 Meeting #4
(NCEG Meeting #9)
7-8 December 1992
Holiday Inn
1000 Sully Road
Stirling, Virginia 22170
Attendees
David Alpern, Sam Figueroa, Jamie Frankel, Azar Hashemi,
Phil Hatcher, Marc Hoffman, Rex Jaeschke (Chair), David
Keaton, Tom MacDonald (Vice Chair), Michael Meissner,
Bill O'Farrell, Dave Prosser, Gary Sabot, Linda Stanberry
(Meeting Secretary), Jim Thomas, Bill Torkelson, Fred
Tydeman, Alex Zatsman, Jeff Zeeb, Jonathan Ziebell
Legend
The following symbols in the left margin of these minutes
have the indicated meaning:
A General approval
SV Straw vote
MSP Formal vote (Moved, Seconded, Passed)
* Action item
The activities reported here are grouped by subject and
do not necessarily follow the exact sequence of
presentation during the meeting.
1. Opening activities (Jaeschke)
1.1 Opening Comments, Goals and Purpose of the Meeting
The meeting was convened at 9:00 a.m. on Monday, 7
December 1992, by Chairman Jaeschke. MacDonald served as
Vice Chairman. Stanberry served as meeting secretary.
Jaeschke indicated that the goals of the meeting were the
same as in previous meetings: (1) to review the work of
subgroups near closure, and (2) to work toward closure in
the remaining subgroups.
1.2 Host Facilities
Jaeschke was the host for this meeting, and he provided
information on the hotel and local restaurants. He also
provided for copying of papers needed for the meeting.
1.3 Approval of Previous Minutes [X3J11.1/92-039]
Prosser asked for clarification of address for CBEMA, on
page 4 of the minutes: is it really "Eye Street" instead
of "I Street"? Yes. Other corrections reported by
Prosser:
In section 2.1, page 5, corrected Tom Plum's statement
to be "...that only wide-character (rather than byte-
string) versions of functions should be defined when
making new interfaces."
In section 6, page 10, should strike the words,
"however, initializers do specify evaluation order of
initializers within list" from the second paragraph.
On page 11, the words that Prosser agreed to add to
explain modifiability of string literals were the
words that appeared above.
In section 8, page 14, fourth paragraph, should
clarify that pointers to VLA's are not allowed
universally in "all" proposals, but only in some
places.
In section 9, page 16, second paragraph, the word
"empty" was omitted from "...it may lead to empty file
scope declarations if macros are nulled."
In section 10, page 17, third paragraph, the word
"don't" was omitted from "...if we don't add IEEE
values, ..."
Thomas reported an error in section 9, page 15, last
paragraph, <float.h> should be <fenv.h>.
Stanberry reported an error in section 11.4, page 18, the
deadline for the second mailing should have been 24
October.
A The minutes as amended by these corrections were then
approved.
1.4 Status of Action Items from Previous Meeting
Jaeschke will notify potentially delinquent members, in
danger of losing voting rights for non-attendance. Done,
two members notified.
Need to identify to which standards or other groups to
send each proposal. Done, and proposals were
distributed.
Need to get proposals to WG14/X3J11 within 4 weeks to be
sure they get in first mailing for those groups. Done.
MacDonald will produce revised cover letter for the
aliasing proposal. Done.
Tydeman will work with Knaak to provide specifications
for IEEE exceptional values in the library functions for
the complex proposal. Done, X3J11.1 92-061.
Jaeschke will provide hotel information [for the December
meeting] in the first mailing. Done.
Jaeschke will assist in getting addresses and contacts
for these standards groups [to receive the forwarded
proposals]. Done.
Individual subgroup editors are responsible for
identifying and sending their proposals to any other
target groups. Done.
Kwan will determine mail deadlines for C++ and will
notify Thomas, MacDonald, and Prosser. Done.
1.5 Approval of the Agenda
There were several revisions proposed to accommodate
schedule needs of those present, and to reallocate agenda
time for those who were not able to be present (Hough and
Kwan).
A Agreed to handle some of administration items earlier
because MacDonald had to
leave early on Tuesday.
A Agreed to add 92-049 to (original) agenda item 9, and to
add 92-061 and 92-075 to
(original) agenda item 11.
A Agreed to rearrange the order of presentations as a
result of discussions.
1.6 Introduction of Participants
Attendees introduced themselves and subgroup focal points
were identified. An attendance list was circulated
(attached to these minutes).
1.7 Distribution of New Documents
New papers were assigned numbers and available documents
were distributed.
92-061 "Merging Complex and IEEE-754, " Tydeman,
distributed.
92-073 "Parallel Control Flow Constructs," Alpern.
92-074 "Data Parallel Control Flow -- Foils," Alpern.
92-075 "Complex Extension to C (Revision 9)," Knaak,
distributed.
92-076 "Elemental Functions (draft)," Hatcher,
distributed.
92-077 "Array Syntax slides for Supercomputing '92,"
Farance.
92-078 "Using Iterators to Express Parallel operations
in C (revision 3)," Becker,
Zoya, and Homer.
92-079 "A Report on the Industry Committee on 64-bit C
Data Types," Kwan,
distributed.
92-080 "Cover Letter for IEEE Floating-Point
proposal," Thomas.
92-081 "HyperC, A C language for Data Parallelism,"
HyperParallel
Technologies, distributed.
92-082 "More Recommended Changes to X3J11.1/92-040,"
Thomas, draft
distributed.
92-083 "Minutes of X3J11.1 Meeting #4," Stanberry.
1.8 Identification of voting members
MacDonald announced that there were 14 voting members at
the meeting.
2 Liaison Reports
2.1 X3J11/WG14 (Jaeschke)
J11 had voted "no" on the Danish proposal for alternate
digraphs, which had included some keywords conflicting
with NCEG proposals.
X3J11/89-159 has been withdrawn as the ANSI standard, and
was replaced with the ISO standard; hence, it is no
longer correct to cite it in our proposals. MacDonald
suggested that we include both documents' numbers, not
just the ISO document, since some people (most of those
at the meeting) did not have the ISO document, and still
used the ANSI document. Jaeschke suggested that the ISO
numbers should always be first, and the ANSI numbers
should follow in parentheses.
Tydeman asked for how to get the ISO document. It should
be available through ANSI (CBEMA) or Global Engineering.
Also, with the ANSI standard withdrawn, J11 can't do
interpretations "in theory," although WG14 will rely on
them to do so "in practice." If J11 and WG14 decide on
holding future joint meetings, it will impact our
schedule.
Prosser asked about the 5 year ramp-up process for a new
C standard and its impact on NCEG--will our work affect
some future standard? Also at issue is getting funding
for participation.
Thomas asked for clarification on our status with respect
to WG14: we have no official status with them.
There was nothing specifically from WG14 to report.
2.2 X3J16/WG21
Since Swan is no longer participating in NCEG, we no
longer have a formal liaison to X3J16. Consensus was to
leave as informal for the present.
Thomas reported that he had been contacted by Jonathon
Shapiro to establish communication with J16.
Hashemi reported on the discussion of the aliasing
proposal at the last J16 meeting. They judged that (1)
it was unsafe; (2) alternatives had not been explored;
(3) it was not as important for C++ as for C; and (4)
it's architecture dependent. They therefore were not
interested in adopting or including the proposal as of
now. There was general disagreement with their
judgement, and discussion of how to respond to J16 on
this. MacDonald suggested that we draft a response once
we see the actual minutes from their meeting.
2.3 X3H5
Jaeschke reported that he received a first cut of H5's
unapproved document with Fortran and C bindings. Their
mailing also included the draft HPFF document.
We do not have a formal liaison with H5.
2.4 X3T2/LIA
Tydeman is our informal liaison with LIA (formerly LCAS).
He reported that they will hold a meeting 4-8 January 93
in New Mexico to formalize the proposed standard to ISO.
Jaeschke suggested that bindings are a second issue with
this group, and asked for direction from the committee on
how we should respond to their proposals.
2.5 POSIX
Nothing new reported.
2.6 DSP (Hoffman)
The committee was asked if there was any interest in
fixed-point representations. No interest was expressed
at this time.
2.7 Other liaison reports
Jaeschke reported on the assessment of international fees
for members of X3 technical committees. The fees are
intended to replace income to CBEMA that had been
contributed in the past by 20 or so private corporations
who no longer will fund the international activities.
The rationale for collecting these fees from committee
members is (1) the participants of the committees benefit
the most from the standards produced, and (2) there is no
way to collect from non-participants. The new fee
structure includes a $300 fee for TAG members per
committee (i.e., for each of J11 and J11.1), and it is
also proposed to disallow the "one free subcommittee"
membership in the future. So someone who is a member of
both J11 and J11.1 can expect their fees to go from $300
per year to $1200.
Frankel asked (1) what benefit does J11.1 have from its
ANSI affiliation, versus being an ad hoc committee; and
(2) can non-payment of retroactive fees be held against
future voting rights?
Prosser suggested that J11 and J11.1 may wish to seek a
merger of their charters, and become one committee.
Tydeman noted that organizations such as X/Open listen
more if you are a standards body.
* Jaeschke will pursue what our options are with
respect to merging with J11, and
will report back to the committee.
Frankel reported on the Birds of a Feather session on
data parallel languages that was held at the
Supercomputing '92 conference. There were presentations
by several NCEG/ASX persons (Alpern, Becker, Frankel),
and Frank Farance had made a presentation on the NCEG/ASX
activity.
3. Brief status of subgroups re deliverables
Thomas reported on FP/IEEE. The changes from the
previous meeting had been incorporated into 92-040 which
was distributed for circulation to other standards
bodies. There were a few responses (<10). Some
additional recommendations for changes to 92-040 had
arisen from those responses, and also from the subgroup
meeting from Sunday evening. These proposed changes will
be presented during the FP/IEEE agenda slot.
Frankel reported on ASX. The subgroup met in September
in Los Gatos, hosted by Farance and Jervis. The minutes
from this meeting were reported in 92-072. They also met
Sunday night, discussing parallel control flow and
organizational details including agenda for Monday
night's meeting. The Monday night meeting will address
HyperC, elemental functions, deliverables, the Tuesday
ASX agenda time, and administrivia (next meeting, etc.).
Prosser and Tydeman reported the status of the ad hoc
group on Extended Integer Arithmetic, in Kwan's absence.
They have decided on a header file with macros to define
the mappings for types onto specific architectures. They
have also begun to address some I/O issues.
Prosser reported on Initializers/Compound Literals
(ICLs). As a result of the distribution of the proposal,
he had received one comment. More will be presented
under the agenda slot for ICLs.
MacDonald reported on Aliasing. Homer had received zero
comments from the distribution of the proposal; hence
they believe it is ready for public review.
MacDonald reported on VLAs. CRI has revised their
proposal from the input of the last meeting, and from
their point of view, the proposal is ready for
distribution. Prosser added that he expects both VLA
proposals to be distributed.
MacDonald reported on Complex. The latest document
reflects the changes from the last meeting, but needs to
be discussed with respect to Tydeman's proposal for IEEE
complex and Thomas' proposal for an imaginary type.
4. Aliasing (MacDonald) [X3J11.1 92-068]
The major change to the document since the last meeting
is inclusion of words from the RFI response from J11.
MacDonald reviewed the formal definition and examples
that were changed as a result.
Tydeman asked about the third example that had been part
of the RFI--why is it not included in the document?
MacDonald said that the third example had dealt with
whether or not the even/odd elements of an array can be
considered as an object, and that it was not included
with this proposal because they believe it was not
justified by the standard to do so.
MacDonald believes the semantics of the aliasing proposal
essentially are those of Fortran77, and not of Fortran90.
That is, it deals with contiguous objects rather than
with non-unit-stride/non-contiguous objects. It is too
difficult to include those semantics without some array
syntax, and CRI wanted to keep the proposal separable
from any other proposal.
MacDonald reviewed additional changes:
Figure 11 was modified to use structs passed by value
rather than using struct pointers, just to avoid any
confusion and to simplify the example.
Section 3.5 was added for clarification of when
restrict in a typedef name has effect, which is at the
point of object declaration. Alpern asked what
happens if restrict is used twice. The same rules
apply as for const and volatile.
Section 3.6 was added for clarification/emphasis that
the compiler still needs to do pointer analysis, and
that it is possible to give up the non-alias-ness of
pointers. Meissner asked if you need to cast to
assign. The same rules apply as with const and
volatile; i.e., there may be some more complex
expressions that would require casts.
Prosser asked what would be the behavior in Figure 12 if
restrict were used on the declarations of p and q. Would
access through r and s violate the rules? No. What if
the given block was the body of a loop; would that
violate the rules? No. Alpern asked so why not restrict
qualify p and q? Not necessary and in some contexts
(macros) it might not be desirable. Sabot and Frankel
noted that since pointer restriction has principle
benefit for parameters, let the compiler do the pointer
tracking in the body as usual.
Prosser asked about the use of the restrict qualifier on
the return type of a function, as described in section
3.7. He suggested and the committee agreed that it would
be better to say that this was quietly accepted, but
undefined (instead of having no effect). Note: it is
not a constraint violation.
Alpern, Prosser, and Sabot suggested that the examples
are oriented towards an implementor's point of view, and
may be misleading to users.
Prosser suggested that the "shorthand" in section 1.7 for
restrict qualifiers should be universal to all qualifiers
(const/volatile). Hence, it would be best to have a
separate proposal that addresses this as a notational
convenience. Jaeschke suggested that it be removed, but
add wording such as "this was considered" to the
rationale.
SV Any objection to removing the special case of
[restrict] from this proposal?
None.
SV Is there support for addressing the general case?
Lots.
* MacDonald will move the special case to the rationale, and
work on a proposal for
the general case for the next meeting, as an amendment to
the aliasing proposal.
Alpern asked to reorganize the wording in 3.6--the second
sentence of the first paragraph would be better as the
first sentence of the second paragraph.
SV Any objections to the suggested rewording of section
3.6?
None.
MSP Should we forward 92-068 as amended for public review?
(MacDonald, Stanberry)
13 yes. 1 yes with comment. 0 no. 0 abstain.
Prosser voted yes with comment, "It is inappropriate to
use the type system to express aliasing information -- it
is inherently an algorithmic property."
Frankel asked for clarification on what is "public
review"? Jaeschke answered that this involves a press
release from CBEMA and making the document available
through Global Engineering.
The logistics of forwarding for public review were
discussed briefly. Prosser noted that we should combine
all documents that we forward into a single document. It
would also be desirable to have all forwarded documents
use the same typesetting, and perhaps a task force to
review the documents for this should be formed.
* Jaeschke will organize the distribution of documents for
public review.
5. Initializers /Compound Literals (Prosser) [X3J11.1 92-
046]
The result of the semipublic review of 92-046 resulted in
one comment, received from Ken Thompson who objected to
the use of the "=" sign in initializers as "completely
gratuitous."
Frankel suggested that we add a footnote for rationale of
why we included it. Prosser would accept wording from
such a footnote from Frankel.
SV Should we remove the equal sign punctuator which is
grammarically unnecessary?
1 yes. 11 no. 2 abstain.
* Prosser will add footnote words to 92-046 to explain the
rationale for the equal sign.
MSP Should we forward 92-046 with the rationale wording
for public review? (Prosser,
Meissner)
14 yes. 0 no. 0 abstain.
Jaeschke introduced discussion of how to distribute our
technical report for public review. We have the latitude
to make our own rules here. He reviewed the process
followed by J11 for public review of the draft standard:
they fixed a review period, and responded to all comments
received. We don't have to respond to individual
comments, but we might want to compile a response diary
that we may distribute with the technical report. If our
proposals are adopted by J11 in the next standard, they
will have the formal review at that time. It is also an
open question of whether we publish our technical report
in parts, rather than waiting for all subgroups to
complete their work.
Frankel asked if we can distribute besides through Global
Engineering. Jaeschke suggested it may be possible to
use anonymous ftp. Prosser observed that it will go to
the standards committees anyway; maybe we don't need to
distribute through CBEMA.
We returned to the issue of using a common typeset for
all proposals since that would probably have a more
favorable response, but the real problem is who would do
the work to combine the proposals? Prosser indicated he
might be able to spend some time on this, but could not
give a time estimate on how long it would take.
Consensus is that we should not try to combine the
proposals until after the public review, and finalization
of a technical report.
We did agree that there should be a common form for
title, cover letter, table of contents, and cross-
reference with each proposal. Details were deferred to
New Business.
6. VLA's (MacDonald, Prosser) [X3J11.1 92-069, 92-035]
MacDonald presented changes to 92-069, the CRI proposal,
as result of comments at the last meeting.
The principle issue is the lexical ordering one, and they
found that any change they made in the wording/semantics
here led to different problems. The current wording is
the same as in revision 5: this requires two passes over
the parameters, but only two passes; in the second pass
must remember which id's are VLA's . As a result of the
change back to revision 5 semantics, some examples are
now ok that weren't ok in the previous (revision 7)
version.
Other changes that were made:
In 3.6.4.2 (switch statement), added constraint
violation if VLA typedef declaration bypassed.
In 3.6.6.1 (goto statements), also a constraint
violation if VLA typedef declaration bypassed by goto.
Alpern noted (1) a returned pointer to a VLA has no way
of returning size information, and (2) there was a need
to clarify "current function prototype scopes" in section
3.5.4.3.
Frankel suggested on the lexical ordering issue that the
proposal might be written in such a way as to allow
implementors to make extensions--e.g., to require lexical
ordering or to allow other extensions. Meissner and
Prosser thought this would lead to incompatible
extensions, or extensions that have different
semantics/bindings.
Prosser then suggested that there is an alternative with
no lexical ordering problems: 92-035. The major
differences in handling of VLA's between this and the CRI
proposal are in binding times--fat pointers are bound at
run time, and the CRI VLA's at declaration time. Prosser
further argued that 92-035 was the best of both Ritchie's
proposal and CRI's proposal.
Prosser gave a quick review of the features of fat
pointers whose major advantage is that there is a
complete description of the object in a single unit.
Noted also that they can be the return value of a
function, and there are no restrictions on typedefs or
structs. His aim for this meeting is to get a 2/3 vote
of approval for 92-035, which is Ritchie's proposal with
AVLA's.
There was lots of discussion (Frankel, Thomas, O'Farrell,
Hoffman) on the following example:
void f(float *p, int n, int m)
{
float (*a)[?] = (float(*)[n])p;
int i, j;
for (i=0; i<n; ii++)
for (j=0; j<m; j++)
... a[i][j] ...
...
}
Noted that if sizes are not passed as parameters, can
calculate as
n = sizeof(a[0])/sizeof(a[0][0])
Optimized code need not have space allocated for array
extents--in the example above, could just use m and n.
Only needed if passed to another function, or otherwise
"escapes."
Stallman's proposal [92-016] was briefly discussed. This
suggests additional syntax to allow forward declarations
of parameters in a prototype. No one volunteered to
champion this proposal.
Discussion then continued on whether or not we should
forward both the CRI proposal and the Ritchie+AVLA
proposals. Thomas believes we will get feedback from
implementors trying both. Meissner suggested that as an
implementor he didn't want to have two versions because
each would have costs. Frankel wants a third version,
the CRI proposal but amended to require lexical ordering.
Jaeschke suggested that we can continue to deliberate in
committee but should put out the proposals in parallel;
sending out both indicates that the committee cannot
decide between the two; a comparison of the two should be
included with the distribution.
Prosser will combine the Ritchie and AVLA proposals into
a formal proposal format if we are going to forward it.
Thomas suggested that, considering the lack of responses
from the previous proposal distributions, perhaps we
should specifically designate contacts/recipients to
provide feedback.
SV Should we forward a 3rd VLA proposal (CRI with
lexical ordering) along with the
two existing proposals?
4 yes. 6 no. 4 undecided.
Not enough clear sentiment to produce this 3rd proposal.
SV Preference vote for the two VLA proposals.
Ritchie+AVLA 6
CRI 6
No opinion 2
MSP Should we forward the two proposals for futher
comment? (Jaeschke, Tydeman)
10 yes. 1 yes with comment. 2 no. 2 undecided.
* MacDonald will provide revised VLA document and cover
letter for CRI proposal.
* Frankel will provide words for his yes with comment vote.
* Prosser will produce combined Ritchie+AVLA proposal, and a
cover letter to distill
the major differences between the two proposals.
7. Complex (Thomas, MacDonald, Tydeman) [X3J11.1 92-061,
92-071, 92-075]
Thomas presented his proposal for including an imaginary
type in the complex proposal, 92-071. He noted that this
proposal only deals with a private imaginary type, and he
really believes we should adopt a public one. He claimed
the following advantages of having an imaginary type:
(1) Allows natural optimization for implementations
with NAN's and INF's. For example, only one
arithmetic operation need be performed for expressions
such as "xi * yi", where xi and yi are imaginary type.
(2) More natural expression of, for example, 0i, than
using the macros in the FP/IEEE proposal.
(3) Also gives i * i real type instead of complex
type.
(4) No suffix required, which makes notation more like
math; I treated consistently as multiplicative factor.
(5) More compatible with C++.
(6) Allows overloading with function arguments, if
users can have variables of imaginary type.
Not everyone agreed with these advantages. Prosser noted
that no need for I if full type, could use casts for
conversions; and if it is a type, the i suffix is just as
appropriate as the f and l suffixes. MacDonald disagreed
with claims of more natural expressiveness: all reals
are also complexes; can produce unnatural (non-complex)
results; and so called "desirable results" with NAN's are
arguable--you get bogus results with imaginary type too.
Prosser stated that the imaginary type proposal makes
complex operators behave symmetrically rather than the
lattice-approach given in the complex proposal [92-075].
MacDonald agreed, and added that you can also get
symmetry by going back to the old rules for the "usual
arithmetic conversions," which require a real operand to
be promoted to a complex type when the other operand is a
complex type.
There was discussion of the impact that this proposed
type would have on the library functions. Discussion
also on compatability with Fortran. MacDonald stated
that the proposal is not consistent with what Fortan
does. Tydeman noted that Fortran90 doesn't allow 0's or
-0's. There was also discussion of the complexity of
adding a full type--e.g., specification of scanf() would
need imaginary format or rules for interpretting when an
imaginary argument given. It was noted that this type
could e specified not to have a new representation,
however.
Frankel suggested that an imaginary type would be for
user convenience only since the desired operations can be
implemented today with user effort; this also allows the
user to specify what the "correct" result of operations
is.
Thomas reiterated that he believes the inclusion of an
imaginary type to the complex proposal is very useful for
full IEEE implementations. His arguments included: it
would allow expressive, efficient code; there is a need
for an imaginary unit I for expressing some common math
expressions; complex C extensions should be compatible
with IEEE extensions; and the imaginary type should be
public, not a private compiler type. He indicated the
scope of what would be needed in order to add the
imaginary type to C: keyword, type specifications,
definition of constant expressions, library function
overloading specifications, promotion rules, and usual
arithmetic conversions.
There was more discussion with MacDonald disagreeing with
expressiveness argument, and Frankel indicating that IEEE
just makes results less surprising, not necessarily
better. Also, it was noted that the current proposal [92-
071] does not address a full imaginary type, so it would
have to be revised, and should be merged with [92-075],
and should be in the style of the FP/IEEE document.
SV Is there interest in adding a public imaginary type
to the complex proposal?
5 yes. 2 no. 5 abstain.
There was discussion before taking the vote on the impact
of adding to the complex proposal later. If approved
later, and with David Knaak's approval, Thomas will merge
a revised 92-071 and 92-075.
Figueroa proposed a compromise between the complex and
imaginary proposals. His idea is to include special
semantics in the complex proposal for cases of constants
that are purely imaginary, such that these semantics
would not be incompatible with a future inclusion of an
imaginary type. The semantics could be specified in
tabular form similar to what Tydeman has done for complex
with IEEE. There was discussion: is this just the same
as in 92-071? Figueroa will provide input to Thomas and
Knaak on this.
Tydeman presented features of his proposal to merge
complex with the FP/IEEE proposal [92-061]: written as
an appendix to the FPCE proposal [92-040]; multiply and
divide still need more work--what is shown is without
compiler help; marriage of ADA and Kahan proposals;
specifies what happens with NAN's and INF's.
There was some discussion on how to merge--i.e., which
document to merge with, and how to cross-reference
between documents. Also noted that definition of terms
would be useful (e.g., branch cut, math unbounded, etc.).
Tydeman clarified in 3.8 ABS, NAN's don't propagate where
return value doesn't depend on input value.
MacDonald presented the revised complex proposal from
Knaak [92-075]. He indicated the following changes had
been made:
ISO numbering explained, but will be revised again as
required now.
In $3.1.1, added wording on how complex becomes a
keyword.
In $3.1.2.5 rationale, updated imaginary type
paragraph and replaced the paragraph that had a
misleading quote from IEEE 754 standard. Thomas noted
that propagation of NAN's is not an implementation
option. He will talk to David Hough about this issue
and give feedback to Knaak.
In $3.1.3 a substantial change was made to allow the
suffix i to appear in any order of suffixes, although
Knaak believes this is a mistake. MacDonald noted
that it was necessary to integrate with floating
constants grammar to do this. Prosser noted that the
grammar is incorrect, and MacDonald and Knaak will
redo to correct. Thomas noted that 1i gets promoted
to double--is that what we want? 1.fi is needed to
get float. Should it be 1i for float and 1.i for
double? Thomas also suggested that a distinction
needed to be made between floating and complex
constants. This would require duplication of most of
the grammar. Suggested rewording of the semantics
section was accepted to clarify when a floating
constant has complex type, and the grammar will be
amended to replace floating-constant with floating-or-
complex-constant. It was noted that you need constant
expressions as well to represent all complex constant
values. Also, "zero" was changed to "unsigned or
positive zero" for consistency.
In $3.3, added formulas but consensus was to leave
them in the rationale, and not make them part of the
semantics. Should add clarification that an
implementation does not have to match exact operation
specified by the formula if overflow/underflow occurs.
Thomas asked if it was necessary to make a special
case for NAN's in $3.9. Consensus was that it does no
harm, and doesn't imply any need for other special
cases.
The old $3.3.4.5 was removed, but the rationale from
that section was moved to the constants section, $3.4.
The %% operator symbol was changed to one which the
secretary cannot find (a circumscribed x) on any of
the special keys on her Mac.
In $4.14.2, the limitations on 0 arguments was
removed.
In $4.14 rationale, agreed to replace "Some merging of
the header <complex.h> and the header <fp.h> will be
necessary" with "<complex.h> and <fp.h> should be made
consistent".
8. FP/IEEE [X3J11.1 92-040, 92-070, 92-082(draft)]
Thomas presented proposed changes to be made to 92-040
that were the result of the responses to the proposal
distribution and the subgroup meeting of Sunday night.
Thomas summarized the changes in 92-070:
In $2, P7, L1 and L16, revise the rationale on
behavior of functions.
In $2, P7, L37, revise the discussion of static vs.
dynamic modes.
In $4.2.1.2, P25, L40, clarify and liberalize
hexadecimal input.
In $4.2.2.2, P27, L35-36, allow removing of trailing
zeros from hex output.
Two minor edit fixes.
Next Thomas presented the proposed changes in 92-082, and
noted that this was just a draft--the committee's
amendments would be added before 92-082 goes into the
mailing:
In $1.3, bibliographical changes and updates were
suggested. MacDonald noted that only documents
beginning in '92 are X3J11.1 docs; the prior ones are
NCEG docs.
In $1.5, add definition of subnormal number.
In $2.3.1, add underscore prefix to _MIN_EVAL_FORMAT
and _WIDEST_NEED_EVAL; clarification that they need
not be constants. Make the same changes in $F.
In $3.1.2.1, add clarification for warning if a hex
float constant cannot be represented "exactly in its
evaluation format..."
In $3.4 and $3.5, move examples from rationale to
spec.
In $3.4, change "raises an exception" to "may raise an
exception."
In $4.2.1.2, replace "strings" with "character
sequences," and font changes.
In $4.2.2.1, use an 80-bit extended format example,
and add example to show how to omit trailing zeroes.
Several style changes for consistency.
In $4.3.7, add clarification that these are common
Fortran functions.
In $4.4.1, clarify how to detect if "excepts" is
supported.
In $4.4.1.1-4, change the return type of these
functions from int to void and delete the "Returns"
sections. In $C.4, make same changes for these
functions.
In $F, revise words about Appendix E, since it is not
going away anytime soon.
MSP Should we adopt the changes to 92-040 as described in
92-070 and 92-082? (Thomas,
Tydeman)
12 yes. 0 no. 0 abstain. 2 absent.
Thomas briefly noted with respect to Stallman's proposal
in 92-049 that macros should be used in place of pragmas
that no responses had been received, even though this was
addressed in the cover letter on the FPCE distribution.
The consensus of the committee is that no need has been
established to disallow pragmas because of the need to
use them in macros: no examples provided, and
disagreement on style.
Thomas noted a couple of issues that had been raised, but
too late to include in a revised proposal. These
included exact representation formatting, and a swap
operation.
Thomas noted that some references will be very long if
both the ISO and ANSI references are given. The ANSI
references could be given in footnotes.
Tydeman asked if comments will still go out with the
documents. Deferred until later.
MSP Should we forward 92-040 as revised by 92-070 and
(revised) 92-082 for public
review? (Thomas, Tydeman)
12 yes. 2 yes with comment. 0 no. 0 abstain.
* MacDonald and Tydeman will send their comments to Thomas.
9. Extended Integer
In Kwan's absence, there was no one to present 92-079,
although Thomas had brought it to the meeting for
distribution.
Discussion centered on do we want to include something in
our TR or leave to the ad hoc group to do? Tydeman has
had some exchanges with this committee, and believes
their focus is to support 64 bit arithmetic without
breaking existing code. He has asked them if they are
going to address wide-chars, but expects that they will
ignore them. He has sent corrections to them for the
specification of the new macros INTMAX_MIN and INT64_MIN
in <limits.h>.
10. Array Syntax
Frankel presented a summary of the ASX subgroup status.
The subgroup held a meeting in Los Gatos on 21-23
September, and met Sunday and Monday evenings during this
meeting.
There were several papers discussed at the September
meeting as detailed in the minutes, 92-072. Some of the
issues raised (elemental functions, parallel control
flow, forall, left indexing, pointer handles) are the
subject of new papers this time, and/or continue to be
discussed. There were also several modifications
accepted to the base document as proposed in 92-026.
This basically removed features of C*: bool type,
assertion grammar, overloading, and Thinking Machine
specific references. Other features such as the notion
of current shape may be removed in the future, pending
discussions of parallel control flow extensions.
At the evening meetings this time, they tried to address
some organizational problems that have arisen. Bob
Jervis has had to resign as recording secretary and
technical editor for the group due to lack of financing
to attend meetings. Farance was not able to attend this
meeting, so no organizational decisions were made at this
time. Several new presentations were made: Alpern [92-
073], Hatcher [92-076], and Paris [92-081]. Deliverables
were identified and will be detailed in the minutes from
their meeting.
The ASX group recognizes that it has many issues left to
complete, and has determined to meet every three months
to work toward closure. The next meeting will be hosted
by MasPar in San Jose on 8-10 March 1993. A preliminary
agenda has been proposed, with time to discuss elemental
functions, parallell control flow, and parallel pointer
handles. Papers on these topics should be submitted
early for full consideration; a priority system for
addressing papers by date of submission was devised to
give preference to those distributed well ahead of the
meeting, and Monday papers will be given lowest priority.
If agenda time is desired for other topics, it should be
requested from Farance prior to 23 January 1993 so that
the revised agenda will be included in the first X3J11.1
(NCEG) mailing.
Frankel reiterated that the procedure they are following
is to consider proposals as amendments to the base
document, and encouraged all who want to participate to
formulate their presentations in that way.
Hoffman asked the question, "What is array syntax?" It
appears that the direction that this subgroup has taken
is more data parallel extensions than array syntax
extensions. Should the subgroup change its name?
* Frankel will investigate possibility of changing the
subgroup name for the next
meeting.
11. Administration
Note: the order of presentation here agrees with the
meeting agenda, but 12.1 and 12.2 were chronologically
just prior to 12.7, and after the other administrivia.
11.1 Summary of Decisions Reached.
Stanberry reviewed the votes taken during the meeting.
11.2 Action Items Committed To
Stanberry reviewed the action items from the meeting.
11.3 Future Meeting Schedule
17-18 May 1993 in New York. Host will be Farance, Inc.
X3J11 will meet after the X3J11.1 (NCEG) meeting, on 19-
21 May.
* Farance will provide meeting information for the first
mailing.
6-7 December 1993 in Hawaii. Host will be Plum Hall,
Inc. X3J11 will be meeting jointly with WG14 on the
preceding Wednesday through Friday, 1-3 December.
There was discussion of whether attendance would be
affected because of the choice of Hawaii for this
meeting.
ASX will meet 8-10 March 1993 in San Jose. Host will be
MasPar Computer Corp.
WG14/J11 will hold a joint meeting in June of 1994 in
Japan. The December 1994 meeting will be U.S. based.
11.4 Mailings and Submission Procedures
Submit mailings to MacDonald (tamacray.com).
The minutes of this meeting should be distributed by e-
mail to the nceg mailing list within 4 weeks of the
meeting.
There was some discussion of the mailing list size.
MacDonald and Jaeschke had reduced the list to what were
deemed active participants, which weeded the list down to
39 from 150. CRI can continue to handle the mailings for
the reduced list.
The deadlines for submitting mailings are:
23 January 1993 - first mailing
3 April 1993 - second mailing
11.5 Next Meeting Agenda
Jaeschke will formulate next agenda from the one used for
this meeting, except to eliminate agenda time for
exceptions since none has been used in the last two
meetings.
11.6 Other Business
Jaeschke led discussion on how to organize the public
review of our proposals. After looking at time frames
for subgroups to get the documents to him, and thence to
CBEMA, etc., proposed a 60 day review period so that we
could get responses in time to collate for the May
meeting.
* Jaeschke will produce a cover letter for distribution with
the documents, in which he
will designate responses should be sent to him. He will
circulate the cover letter to nceg by email first.
* MacDonald, Prosser, and Thomas will submit their documents
to Jaeschke by 29
January.
There was a brief discussion of the inclusion of ISO
standard references in these documents. The consensus
was that ISO must be primary, ANSI should be also used as
secondary reference. Further, the ISO references must be
integrated into the documents, not in cover letter or
other "mapping" information.
* Jaeschke will arrange distribution through Global
Engineering or whatever is
necessary.
MacDonald asked if we could bypass the informal review of
the VLA proposals, and send these out for public review
with the other documents. Meissner stated that he
thought it would be a bad idea to send two proposals for
public review.
SV How many are in favor of combining the VLA proposals
with distribution of
other documents approved for public review?
4 yes. 4 no. 5 undecided. 1 absent.
The two VLA proposals will be handled as an informal
distribution, with timeline to be determined between
Prosser and MacDonald.
* Jaeschke will determine from CBEMA whether or not we can
publish TR in parts or
what the procedure should be--e.g., publish mutliple
TR's.
* Jaeschke will find out if electronic distribution of
public review documents allowed.
* Keaton will look into setting up access through anonymous
ftp for distributing these
documents.
We thanked Jaeschke for hosting the meeting (not to
mention taking all those action items)!
11.7 Adjournment
Jaeschke adjourned the meeting at 4:32 p.m., 8 December.
More information about the Numeric-interest
mailing list