Re: Another proposal for a "split" function to complement "mid"

["Joel C. Salomon" <joelcsalomon@xxxxxxxxx>]

On Tue, Mar 20, 2012 at 2:31 AM, John Pryce <j.d.pryce@xxxxxxxxxxxx> wrote:

On 20 Mar 2012, at 04:13, Joel C. Salomon wrote:

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.

That's why my suggestion cheated, but I didn't make myself clear enough.

At Level 1, split(xx) is defined for all non-empty intervals, but its value is not specified beyond some properties that it must have.

At Level 2, we do specify the value returned by split(), including for open and half-open intervals.

(Still leaving the can of worms that is split(Empty) firmly closed.

(Also, the question of how to most usefully define split() is open for discussion; I'm just trying to cheat at Level 1, not defining anything in terms of HUGH_VAL.)

Does that sound workable?

—Joel