Skip to content

Inconsistency with in(x, ::Interval) and iterate(::Interval) #425

@goretkin

Description

@goretkin

(originally from JuliaReach/ReachabilityAnalysis.jl#373 (comment))
From doing ?in

  in(item, collection) -> Bool
  (item, collection) -> Bool
  (collection, item) -> Bool

  Determine whether an item is in the given collection, in the sense that it is == to one of the values generated by iterating over the collection. Returns a Bool value,
  except if item is missing or collection contains missing but not item, in which case missing is returned (three-valued logic
  (https://en.wikipedia.org/wiki/Three-valued_logic), matching the behavior of any and ==).

  Some collections follow a slightly different definition. For example, Sets check whether the item isequal to one of the elements. Dicts look for key=>value pairs, and the
  key is compared using isequal. To test for the presence of a key in a dictionary, use haskey or k in keys(dict). For these collections, the result is always a Bool and
  never missing.

To help explain, I'll define

my_in(element, collection) = any(==(element),  collection)

which perhaps is more clear as

my_in(element, collection) = any( element == x for x in collection)

and "consistency", and following the documentation of in, means that one of two should be the case:

  1. my_in errors
  2. my_in returns the same answer as in

Interval of IntervalArithmetic.jl wants to both be set and a <:Number:

julia> supertypes(typeof(Interval(0,1)))
(Interval{Float64}, AbstractInterval{Float64}, Real, Number, Any)

and it's a fact of life (unfortunately? fortunately?) that <:Numbers are singleton collections of themselves: https://github.com/JuliaLang/julia/blob/6614645892f03915e4f10b051df9a228c980abc8/base/number.jl#L233 and so

julia> in(0.5, Interval(0, 1))
true

julia> my_in(0.5, Interval(0, 1))
false

One possibility is to just document this. I'd be curious to see if it wreaks any havoc to define new methods on Interval (iterate, length, first, last, maybe copy, ...) that error. This is safer and stricter, and ensures consistency with in.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions