Re: mid-rad, inf-sup, etc.
Hossam A. H. Fahmy wrote:
However, I differ with Michel on the issue of having mid-rad as a
"secondary" type where it receives a "second class treatment" and
does not get its own interchange format. I would go for a "different"
type with clearly defined conversion rules between the two types just
as 754-2008 does between binary and decimal. We will have to live
with some inexact conversions if a program decides to use both types.
What do other people think?
Seems feasible.
The nice thing about intervals is we have inclusion isotonicity. So inexact
conversions, if they are ever neccessary, can still be contained. At play is
the tradeoff between speed and accuracy. Some implementations may require
high accuracy, while others may be less concerned about that and more about
speed. It leaves opportunities for vendors to compete or find niches at
various increments on the continuum. As long as inclusion isotonicity is not
violated, all such implementations can still be conforming, rigorous and
reliable.
Nate