Re: mid-rad as compact encodings
Replying to me, Nate Hayes wrote:
>> it would require is that among those internal formats there be at
>> least ONE that fulfills 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 would not preclude 1788-conforming infsup support, but it might make
it less efficient than if it had native support. It is an interesting
research question to figure out how efficient midrad hardware could be
used to implement infsup primitives. Note that this implementation
could use a private internal representation of infsup during arithmetic,
according to the as-if rule. This private internal representation would
have no trouble representing semibounded intervals. What this system
could not do is use its native type as a stand-in for a 1788 type.
The inefficiency of infsup support on such a platform might not be an
issue if the applications used on it primarily use midrad arithmetic
anyway. Such applications would likely run faster than on native-infsup
platforms.
Michel.
---Sent: 2010-05-12 22:06:55 UTC