mid-rad as compact encodings
Dan Zuras wrote:
> Nate's observation flows from the presumption that
> a narrow interval can be more compactly encoded
> than with inf-sup. Well, that & the presumption
> that adequately narrow intervals are common enough
> to justify the recoding.
Storage savings from compact encodings typically come from
private encodings in a particular application, taking particular
considerations into account. Sometimes the components are even
split into disjoint arrays, as was mentioned here for Rump's trick.
So this is unrelated to our standardization effort. A standardized
mid-rad representation is unlikely to be compact if it is to be
reasonably universal. The only place where I do see a possibility
of saving space is that decorations could conceivably be stored in
the low-order bits of the radius, which would otherwise have the
same precision as the midpoint (in order to have a matching exponent
range). That however would force a certain amount of packing and
unpacking. It might be ok to let decoration bits pollute inputs,
but outputs have to be subjected to mask and overlay.
I suppose the argument could be made that Engineering does not need
the full exponent range of double -- except during intermediate
computations. Then a (double mid, single rad) format might be ok,
it being understood that inputs and outputs would be restricted to
the smaller exponent range of single-precision. Internally however
the radius might also have to be processed as a double...
I get the impression however that radius computations are typically
carried out separately from midpoint computations, NOT as a sequence
of standard operations on midrad entities -- so again it fails to be
relevant to P1788.
It all comes back to the fact that Vienna's primitives are all we
really need: well-defined conversions to/from midrad.
Michel.
---Sent: 2010-05-12 13:44:53 UTC