Re: a question about formatOf operations

[Nick Maclaren <nmm1@xxxxxxxxxxxxx>]

> > >  binary64 = binary32 + binary80
> >
> > I don't see any language issue here, in a language that provides
> > type declarations.  Basically, in the absence of widenTo (perhaps
> > better named minWidth) specifications, the statement above denotes
> > a single operation.  A language that wants to avoid the difficulty
> > of supporting the single rounding should define a widenTo rule and
> > make it the default, so only those who do care about the single
> > rounding would use the appropriate declarations to turn off widenTo
>
> There isn't a lot of "shall" in clause 10 expression evaluation.
>
> The formatOf operations are required however in clause 5.
>         
> What exactly a language does with a statement of the form
>
>   binary64 = binary32 + binary80
>
> might vary, but usually it involves widening operands to a common format
> and then performing the operation, rounding the result to that common
> format - and in this case rounding again to the binary64 format - double
> rounding, with usually no way to prevent it.  widenTo is optional and
> doesn't help getting single rounding.  But the formatOf operations are
> not optional, in order to provide a mechanism to avoid the double
> rounding - usually by widen ing operands to a common format and then
> performing the operation, rounding the result to the narrow format.
>
> No matter what the default is, single or double rounding, there will
> have to be some explicit operation name to get the other.  That's the
> rub - how many of these explicit operation names have to be defined and
> implemented.

There is a massive degree of misunderstanding of the basic concepts
of programming languages here.  While I am not the global expert, I
have a lot of language expertise, and may be able to explain - please
bear with me.

The first thing is that, for the past 40 years, almost all languages
have had a single type system, with built-in types not being special,
and the same conversion rules applying to all of them.  Fortran and
C are notorious exceptions, but they aren't as different (nowadays)
as many people think.

The second is that most languages have an extensible type system,
with the application being able to define derived types that behave
almost exactly like built-in types.  C is an exception, and does not
support operations on its user-defined types, but Fortran and C++
are not.  In particular, the rules need to cater for at least the
following derived type forms:

    quaternion(<real type>)
    polar(<radial real type>, <angular real type>)

The third is that almost all modern languages have context independence
in their type system (as is regarded as good practice), where the type
of a result is determined SOLELY by the operation and the type of its
operands.  Therefore, "binary64 = binary32 + binary80" decomposes into
the context-independent actions "binary32 + binary80" followed by
"binary64 = [[[binary32 + binary80]]]".

For reasons that were good in context, K&R C had the concept of a
separate computation type - 'double' and like it.  C90 slightly extended
this to 'long double'.  C99 introduced an ill-defined concept of
FLT_EVAL_METHOD, which I assume is where widenTo came from.  But that is
GLOBAL, and C99 supports only three, fixed, floating-point types, and
does not support operations on user-defined types.

On this point, some older languages used the concept of the type of an
operation being determined by its result, and the whole operation being
in that type, but I haven't seen one like that in 30 years.  Until
"formatOf" reinvented it!  Even if "formatOf" had tackled the problem
properly, fitting it into any existing language would be a brass-bound
nightmare.



So, to summarise, let's see a draft proposal of how "formatOf" could
be specified in Fortran or C++ without forcing radical changes to the
existing language designs, and while giving a defined effect when used
on types like 'quaternion' and 'polar'.

Dammit, nobody responded to even my PREVIOUS request to produce even
minimal draft wording of how bitwise reproducibility could be inserted
into Fortran or C++.  I can only interpret that as meaning that nobody
knows how to do it.



Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1@xxxxxxxxx
Tel.:  +44 1223 334761    Fax:  +44 1223 334679