A weird issue with Interval[$MaxNumber]

Question

Bug introduced in 9.0 or earlier and persisting through 11.0.1 or later

---

From the Interval documentation:

For approximate machine- or arbitrary-precision numbers x, Interval[x] yields an interval reflecting the uncertainty in x.

$Version
(* 10.4.0 for Microsoft Windows (64-bit) (February 26, 2016) *)

Interval @ $MaxNumber === Uncompress @ Compress @ Interval @ $MaxNumber
(* True *)

IntervalMemberQ[Interval @ $MaxNumber, $MaxNumber]
(* True *)

IntervalMemberQ[Uncompress @ Compress @ Interval @ $MaxNumber, $MaxNumber]
(* False *)

What is going on here? What happens with the interval after the compress-uncompress round-trip?

Answer 1

A new and mostly rewritten version of the original answer which was flawed. See edit history if interested.

As any operation making $MaxNumber higher (more precisely: higher enough for its Precision to notice) results in an overflow, the Interval created here has the form

Interval[{$MaxNumber - something small, Overflow[]}]

The "something small" is approximately $MaxNumber / 10^$MachinePrecision (not so small, on second thought). Now it holds that

0 < Underflow[] < $MinNumber <= anything positive finite <= $MaxNumber < Overflow[] < ∞,

so it would make sense to accept Overflow[] for a bound of an interval, at least an open one. As the comments to the original version of this answer show, since there are only unions and intersections in Mathematica's interval arithmetic, even that works in the presence of Overflow[]. Of course, some problems will arise with a symbol that effectively represents an out of bounds error, like comparison with itself, but by any means $MaxNumber should be a member of the above interval.

I have done a bit of hacking on DumpSaves and discovered the following: Mathematica sorts Intervals into those that have numerical inputs and those that don't. I would call the latter "incomplete" because this category includes not only Intervals with unassigned symbols appearing in the bounds but also those with Slots and Blanks. Any incomplete Interval automatically returns False on IntervalMemberQ: try

(* This gets only evaluated after substitution *)
f[a_, b_, c_] := IntervalMemberQ[Interval[{a, b}], c];
f[1, 3, 2] (* True *)

(* This is evaluated immediately with the incomplete Interval *)
g[a_, b_, c_] = IntervalMemberQ[Interval[{a, b}], c];
g[1, 3, 2] (* False *)

or even

f = IntervalMemberQ[Interval[{#1, #2}], #3] &;
f[1, 3, 2] (* True *)

g = Evaluate[IntervalMemberQ[Interval[{#1, #2}], #3]] &;
g[1, 3, 2] (* False *)

My speculation is that this has to do with optimization: with a numeric Interval, all the bounds are compared, sorted along the real line and merged as appropriate as shown by the example

Interval[{-1, √2}, {0, π}, {7, 8}, {-5, -4}]

(* Interval[{-5, -4}, {-1, π}, {7, 8}] *)

This can't be done with incomplete intervals. It might be an "expensive" operation so it's good to do it once the interval becomes complete, and if two of these are intersected, unified, or compared, take this condition for granted.

Now what happens in the original examples is that the "incomplete" bit gets set when Overflow[] is manually provided as a bound to the Interval (even though Overflow[] is even explicitly recognized as numeric by NumericQ and compares with other numbers well). Somehow the Interval produced by Interval@$MaxNumber is still marked as numerical, though, and this is preserved under interval operations. This explains the situations with Uncompress@Compress@ and Identity/@ applied on the pre-made Interval since these force reevaluation of its parts.

In pattern and slot substitutions, a new object is formed so the incomplete bit is reexamined (and the optimizations done, if complete). But as long as the object stays unchanged there is no reason to touch this metainformation. Importantly, this flag is not a part of the expression tree displayed to the user and is ignored in comparisons. So if two objects only differ in this (due to an incoherent assignment at one or the other's creation) they look identical and are even considered equal in === and similar commands. It is enough difference, however, to prevent Share from merging them.

Of course, there are many good points supporting Mathematica's decision not to allow Overflow[] as a bound for Interval – if it was a design choice in the first place, that is. But one way or the other, this behaviour should be consistent. I agree the inconsistency is a bug, most likely originating in Interval.