Re: Motion 42, reference implementation, manufacturer acceptance, 17th byte
On 2/9/2013 8:14 AM, Ulrich Kulisch wrote:
I vote YES on motion 42.
Comment:
I admire John and all the others who have put together this motion. If
it would be a resaerch paper I would be happy supporting it strongly.
But there is only little experience available with the use of
decorations. Siegfried Rump asked for at least one prototype
implmentation and in gerneral I wonder whether we blow up the standard
too much with the concepts of flavors and decorations. In the first
round the standard should be simple and easily understandable to
everybody. A basic goal of P1788 should be getting it accepted by the
manufacturers. I agree that supporting the proof of correctness of a
verification process would be important. But can't we leave this for a
second round or for a part two of the standard..
With best wishes
Ulrich Kulisch
I find your comment quite interesting.
I too would like to see at least one implementation, and have
started working on one.
You refer to the "first round". Are you suggesting there would be
a second draft of the current document that would add decorations etc?
If you are referring to the next round being another standards
committee some time in the future, my guess is that this would
be unlikely to happen for decades if ever, at least under IEEE
auspices. The revisions of IEEE-754 are separated by 23 years.
Thus if one is uncertain about decorations etc., then this
standards document should be clear about supporting the tools
for implementing decorations, not necessarily requiring
some controversial properties under discussion. If the distinctions
that are controversial (mathematically) do not affect the
implementation, it is perhaps unnecessary to agree!
On the matter of having 1788 being accepted by manufacturers,
I suspect that they just won't take any notice of it, one
way or the other.
(I don't know if there is a representative of any manufacturer
on the committee right now, but if so, he or she should speak
up).
What is the evidence that I speak of? There is substantial
evidence that the key elements of the IEEE 754 floating-point
standard (key for a good 754-conforming implementation),
are generally made inaccessible either by the
hardware or software manufacturer (or both).
Some manufacturers
who claim to support the IEEE standard are supportive mainly of
the FORMATS but not all operations (in particular, directed
rounding, but also other parts). Just in case the hardware
provides registers for modes and traps, it is likely that the
software (operating systems and programming languages) will
render these hardware features difficult to access or non-portable
or ineffective. For example, Java specifies round-to-nearest.
(at least last time I looked). Some operating systems
supporting multiprocessing may not save and restore
the bits needed to keep the floating-point
flags consistent from before and after an interrupt.
Now it is possible to find some implementations on some hardware
and some software that does just what one wants (754- conforming).
It just may not be the hardware and software that is most widely used.
Or one may implement directed rounding entirely in software,
assuming the hardware produces some consistent rounding. This may
or may not be 754-conformant.
Perhaps high speed and getting the tightest possible interval
are secondary to getting agreement on the mathematics and
notation. In that case it may not be necessary to
get manufacturers' or programming language implementers'
support at all, and an entirely conforming implementation
of 1788 may depend on nothing of the IEEE 754 standard.
It seems possible from my (undoubtedly incomplete) understanding
of the draft standard. If standard language and loose conformance
is acceptable, that's a lower hurdle for implementers who need
not worry about intervals widening by a unit in the last place.
.................
At the risk of putting yet too much into one email, I'll mention
one solution to the 17th byte problem that is widely used in Lisp.
I do not know if it has been considered for decorated intervals,
or if it is just silly in the expected context of intervals...
but if not, here it is.
The notion is of "typed pointers". If
(and this is certainly not necessarily the case) we assume that
all references to large objects are done by pointers, we have
bits at our disposal. To be clear, what this means is that an
array of intervals will be implemented as an array of pointers.
Each pointer (say 32 bits), has the address of a 16-byte quantity (2
doubles)..
Assume the 16 byte quantity is on a 16-byte boundary. The
last 4 bits of the address are necessarily zero. But if you
know they are supposed to be zero, why not use them to store a
decoration? When you follow that pointer to an address of an
interval you mask off those bits. If you want to find the
decoration you mask off the 28 high-order bits.
(Lisp uses this scheme to distinguish pointers to numbers, to
lists, etc. This is important because Lisp is not strongly typed.
It does, however, make it trivial to implement intervals whose
endpoints are integers, exact rationals, single or double floats,
"bigfloats", ... and to operate on them with other operands that
are scalars of any numeric type.)
Richard Fateman