Re: Another proposal for a "split" function to complement "mid"
Joel
On 20 Mar 2012, at 04:13, Joel C. Salomon wrote:
> Vladik Kreinovich <vladik@xxxxxxxx> wrote:
>> Maybe not make it Level 1 at all, keep it Level 2 function only?
>
> I think Vladik's on to something, but perhaps I can go a step farther:
> At Level 1, the particular value returned is not specified; but some
> properties of the value are defined (e.g., inf <= split <= sup or some
> such).
>
> This avoids mathematical confusion about how to define the result of
> splitting half-open intervals or Entire -- the operation is defined,
> but the particular value isn't. 0 is acceptable for split(Entire) at
> Level 1; so is 42, or -13.75.
>
> At Level 2, we can make use of the underlying FP format's
> characteristics and define split([0,oo)) &c. in terms of HUGE_VAL.
There's a lot to be said for this but the question of reproducibility raises its head. If 1788 says each implementation must have a "split" function but leaves it partly unspecified, then I can send my B&B program to you and it may run quite differently on your machine from on mine.
It was to increase reproducibility that I said "an implicit interval type includes a hull operation as part of its definition". Maybe I sneaked that past the group. Now here's a similar situation.
Reminder: Quite a few people have argued in favour of a pragmatic "split" function that always does SOMETHING at Level 2, leaving "midpoint" free to be more mathematical and return NaN for intervals such as [0,inf] that have no midpoint at Level 1. IMHO this is a good idea.
What does the group think?
- For "split", if we decide to have it, what wins? Reproducibility or freedom?
- Is this issue to be decided case by case, or should we have a general policy about it?
John Pryce