[Cfp-interest] WG14 meeting notes for Part 3

[Rajan Bhakta]

Same for this part.
Note that we have some issues we need to look at (tagged with *AI* below 
for context):
1) Rename the "generic" floating types to something else like "classic"
2) Jim's slide examples need to be added to the TS
3) The word "interchange" should be replaced by something else


n1691: (Floating point TS Part 3) 
  Benito: C++ is working on some typedefs for extended types as well. Bill 
Seymour will make sure they (C++) know that we have an ISO work item for 
this already while they are still in a study group so we don't get out of 
sync. 
  Issue 1: 
    Blaine: What is the technical reason for having part 1 or part 2 
binding? 
    Jim: The types requires arithmetic for use. We could have the data 
interchange types without any binding to the previous parts. 
    Douglas: What is the point of the issue? 
    Jim: It is a distributed specification. How hard will this be for 
implementers to follow these? 
    Benito: The downside started when we asked for Part 1 and Part 2 to be 
independent. 
    Blaine: Why weren't the extended types put into part 1 and part 2 
themselves originally? 
    Jim: These are optional from the IEEE spec. Parts 1 and 2 are 
mandatory from the IEEE spec. 
  Type structure additions: 
    Blaine: Why do you want to have the distinction between data 
interchange types and interchange floating types? 
    Jim: An example is _Float16. Most implementations will want this as a 
data interchange type. A particular may want to have arithmetic operations 
on it as well making it an interchange floating type. 
    Clark: Representation is different from type. A type implies 
representation and operations. It seems confusing to talk about 
interchange types. It may be better to only have interchange 
representations. 
    Jim: How do you get the representation? 
    Clark: You can convert the representation to a type to handle it. 
Maybe say transcribe instead of convert? 
    Tom: You do in fact define the data interchange types including 
operations on the types. Which is being proposed? 
    Jim: It will come later in the presentation. These are the types you 
can put the representation into. You can do conversion, comparison macros, 
etc. but not arithmetic. 
    Jim: This is the type binding from IEEE to C. 
    Clark: You are renaming real floating types into generic floating 
types. 
    Douglas: The paper changes all uses of real floating type to generic 
floating type. 
    Clark: Why do this? 
    Jim: Due to the decimal TR (now Part 2). The reason is to keep real 
floating type wherever it is in the standard. 
    Clark: I don't like the connetations of "generic" (Blaine also). 
    Jim: We can look at renaming this (*AI*) to maybe something like 
"classic"? 
  Issues not labelled as issues (first so labelled slide): 
    No comments. 
  Example 2: 
    Blaine: Is there some macro to know if _Float16 can also be 
arithmetic? 
    Jim: Yes. 
    Douglas: Why would you have _Float32x be 128 and not _Float64x? 
    Jim: It can be like the slide before. 
    Jim: The types are distinct. 
    Barry: Should these tables (from the examples) be in the TS? 
    Jim: We can add them. (*AI*) 
  Issues not labelled as issues (second so labelled slide): 
    Seymour: How does float + Float64 work? 
    Jim: Promoted to Float64 since to do + Float64 must be an arithmetic 
type 
    Clark: I would prefer a world where this hierarchy or considerations 
didn't apply. I would prefer the interchange stuff be in terms of 
representations not types. 
    Jim: That would not get rid of any of this. These are all arithmetic 
types. 
    Clark: I would banish the concept of interchange type. 
    Jim: What would float256 be? 
    Clark: I would not have one. No types. 
    Jim: That is required by the IEEE standard. 
    Douglas: Can't you have all data types being arithmetic types? 
    Jim: That wouldn't help Clark. 
    Clark: The extended types are fine. The interchange types is the 
issue. 
    Seymour: I've got a bunch of bits coming in my modem. I have to put 
them in an object before I do anything with it. 
    Clark: I think of interchange as working on a buffer. 
    Jim: I think you are tripping up on the name. 
    Clark: Yes, that and other things. 
    Blaine: You can make a typedef of a char array for those types. You 
could have functions that work on those. And not have arithmetic versions 
of the interchange types. 
    Jim: The terminology is not being used right. The IEEE spec allows 
data interchange types to be arithmetic. 
    Blaine: Is it possible to separate the arithmetic float16 to be 
distinct from the data only float16 (different names)? Would this work 
with IEEE? 
    Jim: We could then have the data only version handled differently. 
    Roberto: Is it possible to deliver the IEEE spec without data only 
interchange types. 
    Jim: This is a full specification of optional features of the 
standard. 
    Martin: Are you opposed to the types being introduced as fundamental 
types or even for "user defined" types (typedefs)? 
    Clark: To talk about an interchange floating point type mixes up ideas 
that do not help the world. The floating point standard says binary16 is 
an interchange type. That is a special case. I don't think the world would 
thank us for this. People would want arrays of binary16 and operate on 
them without pain. 
    Jim: Suppose your implementation doesn't do computation in float128 
but wants to be able to handle it (for example, by converting to float64x 
like 80-bit floats) to do actions on it. 
    Blaine: The interchange types should be distinct non-arithmetic types 
with the exception of float16. The other interchange types should never be 
arithmetic. 
    Jim: The problem is terminology. The floating point spec refers to all 
non-extended types as interchange types. (*Issue still*) 
  Issues not labelled as issues (third so labelled slide): 
    Blaine: Does the conversions include runtime code? 
    Jim: It could. 
    Martin: Do these types have to be fundamental types. 
    Jim: These are scalar types. They cannot be structs. If we want to 
respecify them we'd have to come up with new ways to do conversions and 
classification macros etc. to make them functions. 
    Martin: Would doing those changes resolve Blaine and Clark's 
objections? 
    Blaine: No, I don't want data only to be the same as arithmetic types 
ever. 
  Issues not labelled as issues (fourth so labelled slide): 
    No comments. 
  Jim: Sensing reaction to the interchange terminology. We can go back and 
change the terms we used for this. 
  Benito: Follows IEEE terminology. 
  Blaine: I want a reference to the IEEE description in this document. 
  Benito: It requires reading IEEE in the TS. 
  Jim: We can look at adding or paraphasing the definition from the IEEE 
spec for interchange terms. 
  Blaine: I need to understand the IEEE terminology and so I'll pull back 
until I understand it. 
  Willem: I feel that interchange types are like jpeg. This is not a 
concern for the language. Do we need to have them at all for C? Is it 
appropriate for us? 
  Blaine: Interchange is nailed down. A specific number of bits for 
mantissa, etc. so it can be used anywhere that follows the standard. 
  Jim: If you think of it as data, it is interchangable data whether or 
not you can do arithmetic. Email follow up on this item. 
  Jim: The other concern is for the items that are not arithmetic not be 
types. 
  Blaine: They need to be types, no question. Just don't put floating in 
the name. 
  Clark: You can think of them as struct types or model them as such. 
  Jim: Conversions make it interesting. 

Regards,

Rajan Bhakta
z/OS XL C/C++ Compiler Technical Architect
ISO C Standards Representative for Canada
C Compiler Development
Contact: rbhakta at ca.ibm.com, Rajan Bhakta/Toronto/IBM
Telephone: (905) 413-3995 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20130506/e6326162/attachment-0001.html