Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Motion P1788/M0029.01: Level-3-interface-only --- Final version to vote on



Dan and P1788, especially compiler people:

On 14 Dec 2011, at 01:24, Dan Zuras Intervals wrote:
>>  However they also support an interchange medium at the binary level. One 
>>  can't specify this for a "general" T assuming only what's in the Explicit/
>>  Implicit motion 19, but for each 754-conforming type we can easily define 
>>  its interchange format (should it be "interchange type"?) as follows:
> 
> 	You are correct that it SHOULD be "interchange type" but please
> 	continue to use the expression "interchange format".
> 
> 	During the 754 deliberations we tried to use the word "type" to
> 	refer to our datatypes but the compiler people in the room always
> 	objected on the grounds that a compiler notion of "type" carries
> 	with it baggage that we could neither discuss nor agree upon.
> 	So you will notice that the word "type" is largely eliminated
> 	from the 754 document.
> 
> 	Indeed, the word "format" was controversial as well.  And the
> 	use of it in 754 is not quite the same as the use of it elsewhere.
> 	We use it to refer to an abstraction separate from its bit pattern
> 	for which we reserve the word "representation".
> 
> 	I am not a fan of such tortured prose but it is something that
> 	seems to come out naturally in the committee process.

Dan, I would prefer to use "type". I want to reserve "interval format" for Level 3, and "interval type" for Level 2.

My reason is as follows. An interval type T is, like a 754 format F, an "abstraction separate from its bit pattern" but T is at a higher level of abstraction than F. Namely, a T-datum is basically "a mathematical interval that knows what type it belongs to", see my draft Level 2 text (from clause 6) copied below. So a T-datum exists above any representation, while I think an F-datum is defined by its representation (the radix, exponent width, and significand width). 

I hope the extract below makes my point sufficiently clear. A type name is something like "binary64". I would suggest that whatever names are used for types in P1788 are not necessarily those used by a language or an implementation.

Compiler people, do you wish to object to this usage?

John Pryce

EXTRACT FROM DRAFT P1788 CLAUSE 6.
----------------------------------
6.1. Datums are tagged by names.
A format or type is an abstraction of a particular way to represent numbers or intervals—e.g., "IEEE 64 bit binary" for numbers -- focusing on the Level 1 objects represented, and hiding the Level 3 method by which it is done.

However a datum is more than just the Level 1 value: for instance the number 3.75 represented in 64 bit binary is a different datum from the same number represented in 64 bit decimal.

This is achieved by formally regarding each datum as a pair:
        number datum    =  (Level 1 number, format name),
        interval datum  =  (Level 1 interval, type name), 
where the name is some symbol that uniquely identifies the format or type. The Level 1 value is said to be _tagged_ by the name. This achieves two needed properties: distinct formats or types are disjoint sets; and two datums are equal if and only if they represent the same Level 1 value tagged by the same name.

Names are omitted except when clarity requires. 

[Example. Level 2 interval addition within a type named t is normally written z = x + y, though the full correct form is (z, t) = (x, t) + (y, t). The full form might be used, for instance, to indicate that mixed-type addition is forbidden between types s and t but allowed between types s and u. Namely, one can say that (x, s) + (y, t) is undefined, but (x, s) + (y, u) is defined.]