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.

(* 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?

  • $\begingroup$ Same with "9.0 for Microsoft Windows (32-bit) (January 24, 2013)" $\endgroup$ Mar 9 '16 at 22:48
  • $\begingroup$ Confirmed with "10.3.1 for Linux x86 (64-bit) (December 8, 2015)". Very strange indeed. $\endgroup$
    – The Vee
    Mar 10 '16 at 0:41
  • 1
    $\begingroup$ If you take the one before last step of Trace of either of the last two commands' evaluation, you get two objects which are identical to the last bit on every level but transform to True and False, respectively. So Uncompress@*Compress does not corrupt the object itself but some part of MMA's metadata about it that determines the result. This survives if you save the two objects in MX and import back (not WDX, that makes them both False just like the compression), so it's more than just runtime state of the kernel (evaluate cache etc.) $\endgroup$
    – The Vee
    Mar 10 '16 at 1:00
  • $\begingroup$ If you take the output of Interval@$MaxNumber as input, then IntervalMemberQ returns False, like the Uncompress@Compress... round-trip. Something is happening on re-parsing, I guess. $\endgroup$
    – Michael E2
    Mar 10 '16 at 3:36
  • 1
    $\begingroup$ IntervalMemberQ[Identity /@ Interval @ $MaxNumber, $MaxNumber] is also False. Interval @ $MaxNumber === Identity /@ Interval @ $MaxNumber is True (as expected). $\endgroup$ Mar 10 '16 at 5:17

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.

  • $\begingroup$ interval = Interval[$MaxNumber]; Print[interval]; IntervalMemberQ[interval, $MaxNumber] also evaluates to True, although the interval is already fully evaluated, apparently. $\endgroup$ Mar 10 '16 at 22:36
  • $\begingroup$ Even interval = IntervalUnion[Interval[{0, 1}], Interval[$MaxNumber]]; Print[interval]; IntervalMemberQ[interval, $MaxNumber] is True. $${}$$ Also, interval = IntervalUnion[Interval[{0, 1.6052167619336615*^1355718576299609}], Interval[$MaxNumber]]; Print[interval]; IntervalMemberQ[interval, $MaxNumber] is True (and prints Interval[{0,Overflow[]}]). $\endgroup$ Mar 10 '16 at 22:41
  • $\begingroup$ My research was incomplete, then, I should have spotted these cases. I will replace my answer. This one deserves downvoting / deletion. $\endgroup$
    – The Vee
    Mar 11 '16 at 11:38
  • $\begingroup$ OK, I have a new reasoning I am fairly certain about. If I'm not mistaken it covers all the known cases. I rewrote my answer. $\endgroup$
    – The Vee
    Mar 11 '16 at 17:15
  • 1
    $\begingroup$ Bingo! Check the "valid" flag using System`Private`ValidQ. Example: System`Private`ValidQ[Interval[$MaxNumber]] --> True, System`Private`ValidQ[Identity /@ Interval[$MaxNumber]] --> False. This is where it goes wrong. Note that the valid flag is mutually exclusive with the "incomplete" flag, which may not have its own Q-test. Or you may just reformulate my answer with respect to this one. $\endgroup$
    – The Vee
    Mar 21 '16 at 14:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.