Re: How do I bisect unbounded intervals?
On Tue, 17 Jan 2012 13:43:35 +0100, Vincent Lefèvre wrote:
> I would not associate a T-format with the interval type T.
> For instance, for a binary64-based inf-sup interval type T, one may
> want the midpoint in binary64, but also in binary128, as allowed by
> IEEE 754 (§5.4.1).
Then, on Tue, 17 Jan 2012 15:01:54 +0100:
> On 2012-01-17 07:15:07 -0600, Ralph Baker Kearfott wrote:
>> That's an interesting thought. Can you elaborate on why one might
>> want more precision in mid than in the end points?
>
> In some cases (in particular for not too large intervals, which
> are cases for which the midpoint is most interesting), this would
> allow one to get the exact result.
And on Wed, 18 Jan 2012 01:59:29 +0100:
> I think it would make sense and be consistent to interval arithmetic
> operations and also the IEEE-754 formatOf operations.
To which Dan Zuras replied:
> While I sympathize with Vincent's feelings in this
> matter, I hesitate to follow 754 in the "formatOf"
> direction.
There is another way to deal with this: If you want a higher-resolution
midpoint, first convert the *Interval* to wider precision, then take its
midpoint. That would fit with the T-format approach recommended by John
Pryce on Mon, 16 Jan 2012 22:25:49 +0000:
| ...How do midpoint and the other numeric functions
| of intervals work for an _implicit_ type?
|
|I've basically defined an interval type T as a set of mathematical
|intervals plus a specified T-hull operation. No number-format is
|mentioned. But Level 2 midpoint, etc., must return a datum of some
|number format. Hence I see nothing for it but to make the revised
|definition:
|
| An interval type T is a set of mathematical intervals,
| plus a specified T-hull operation, plus a specified
| number format, let's call it the T-format.
You see, John was concerned about implicit types, and subsequent discussions
reminded us that implicit types could encode their information in all sorts
of different ways. Yet common functions like mid() and rad() applied to
any interval type should return something in an explicitly-defined format.
When multiple FP precisions are supported, it makes sense to me to expect
formatOf versions, either explicit (like mid64(), rad32() etc.) or (in a
language where types can be overloaded) implicit, depending on the format
of the source operands. This would in particular avoid double-rounding
issues, which is the primary reason that 754-2008 took that route.
Ok, now I have spoken both in favour and against using formatOf functions!
Michel.
P.S. Baker, this may trigger another DFR. After this posting I'll change
my stds-1788 setting back to NOREPRO to avoid further DFRs.
---Sent: 2012-01-18 19:10:37 UTC