Re: mid-rad as compact encodings
I would concur with Michel. A conversion between infsup and midrad would suffice and make things much more robust yet usable in another format if need be.
Regards,
Rudnei
2010/5/12 Michel Hack
<hack@xxxxxxxxxxxxxx>
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.
> 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). 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. 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.
Michel.
---Sent: 2010-05-12 19:38:48 UTC