Re: mid-rad as compact encodings
Michel Hack wrote:
Nate Hayes wrote:
Another possibility could be to encode a mid-rad value in 64-bits,
perhaps with a single exponent. In that case a mid-rad interval
would be 50% the storage size of a normal inf-sup interval.
I doubt we want to standardize a made-up format that does not match
existing 754 formats. That's why I mentioned that compact encodings
would most likely be used as application-specific private internal
formats.
Yes, Michel, I agree.
Just with the caveat: whenever possible, we should try not to write
P1788 in a way that would intentially preclude a vendor from using
mid-rad as an internal format.
The standard would never preclude any kind of internal format. What
it would require is that among those internal formats there be at
least ONE that fullfils the requirements of the standard -- and that
means something that is EXACTLY convertible to an infsup interchange
format (if it is not one already).
Well, this WOULD preclude a mid-rad only processor, if I understand
correctly, even if the processor provided all the appropriate inf-sup
conversions.
It turns out that few midrad
forms -- and none of the practical ones -- can do that. The ones
that might be convertible exactly are likely to occupy MORE space
than plain infsup.
It is becoming abundantly clear (to me at least) that advantageous use
of midrad is going to be application-specific, so there is no point in
trying to standardize that.
Folks, I hope I've made it clear I agree with this!
For infsup there is sufficient
mathematical support to define a solid standard, so that's what we
should concentrate on -- plus a standard interface to the midrad
world, e.g. as in Vienna.
This too!
Nate