Strip out duplicates (in n-log(n) time, by building an intermediate Set)

Builds a MemberSpec, but returns an Error spec if the list is empty

The exact count of the number elements in a Bounded NumSpec

The exact number of elements in a Bounded Integral type.

This is an optimizing version of TypeSpec :: TypeSpec n -> [n] -> Specification n for Bounded NumSpecs. notInNumSpec :: Bounded n => TypeSpec n -> [n] -> Specification n We use this function to specialize the (HasSpec t) method typeSpecOpt for Bounded n. So given (TypeSpec interval badlist) we might want to transform it to (MemberSpec goodlist) There are 2 opportunities where this can payoff big time. 1) Suppose the total count of the elements in the interval is < length badlist we can then return (MemberSpec (filter elements (notElem badlist))) this must be smaller than (TypeSpec interval badlist) because the filtered list must be smaller than badlist 2) Suppose the type t is finite with size N. If the length of the badlist > (N/2), then the number of possible good things must be smaller than (length badlist), because (possible good + bad == N), so regardless of the count of the interval (MemberSpec (filter elements (notElem badlist))) is better. Sometimes much better. Example, let n be the finite set {0,1,2,3,4,5,6,7,8,9} and the bad list be [0,1,3,4,5,6,8,9] (TypeSpec [0..9] [0,1,3,4,5,6,8,9]) = filter {0,1,2,3,4,5,6,7,8,9} (notElem [0,1,3,4,5,6,8,9]) = [2,7] So (MemberSpec [2,7]) is better than (TypeSpec [0..9] [0,1,3,4,5,6,8,9]). This works no matter what the count of interval is. We only need the (length badlist > (N/2)).

T is a sort of special version of Maybe, with two Nothings. Given:: NumSpecInterval (Maybe n) (Maybe n) -> Numspec We can't distinguish between the two Nothings in (NumSpecInterval Nothing Nothing) But using (NumSpecInterval NegInf PosInf) we can, In fact we can make a total ordering on T So an ascending Sorted [T x] would all the NegInf on the left and all the PosInf on the right, with the Ok's sorted in between. I.e. [NegInf, NegInf, Ok 3, Ok 6, Ok 12, Pos Inf]

Use this on the lower bound. I.e. lo from pair (lo,hi)

Use this on the upper bound. I.e. hi from pair (lo,hi)

multiply two (T x), correctly handling the infinities NegInf and PosInf

What constraints we need to make HasSpec instance for a Haskell numeric type. By abstracting over this, we can avoid making actual HasSpec instances until all the requirements (HasSpec Bool, HasSpec(Sum a b)) have been met in Constrained.TheKnot.

let n be some numeric type, and f and ft be operations on n and (TypeSpec n) Then lift these operations from (TypeSpec n) to (Specification n) Normally f will be a (Num n) instance method (+,-,*) on n, and ft will be a a (Num (TypeSpec n)) instance method (+,-,*) on (TypeSpec n) But this will work for any operations f and ft with the right types

Put some (admittedly loose bounds) on the number of solutions that genFromTypeSpec might return. For lots of types, there is no way to be very accurate. Here we lift the HasSpec methods cardinalTrueSpec and cardinalTypeSpec from (TypeSpec Integer) to (Specification Integer)

A generic function to use as an instance for the HasSpec method cardinalTypeSpec :: HasSpec a => TypeSpec a -> Specification Integer for types n such that (TypeSpec n ~ NumSpec n)