NumericPrelude.Numeric

Note - random generates values in the Int range

Used for marking occurrences of Int#

fromEnum just truncates its argument, beware of all sorts of overflows.

List generators have extremely peculiar behavior, mandated by Haskell Report 2010:

>>> [0..1.5 :: Float][0.0,1.0,2.0]

Note that due to the presence of NaN, Float's Eq instance does not satisfy reflexivity.

>>> 0/0 == (0/0 :: Float)False

Also note that Float's Eq instance does not satisfy extensionality:

>>> 0 == (-0 :: Float)True>>> recip 0 == recip (-0 :: Float)False

This instance implements IEEE 754 standard with all its usual pitfalls about NaN, infinities and negative zero.

>>> 0 == (-0 :: Float)True>>> recip 0 == recip (-0 :: Float)False>>> map (/ 0) [-1, 0, 1 :: Float][-Infinity,NaN,Infinity]>>> map (* 0) $ map (/ 0) [-1, 0, 1 :: Float][NaN,NaN,NaN]

This instance implements IEEE 754 standard with all its usual pitfalls about NaN, infinities and negative zero. Neither addition nor multiplication are associative or distributive:

>>> (0.1 + 0.1 :: Float) + 0.5 == 0.1 + (0.1 + 0.5)False>>> (0.1 + 0.2 :: Float) * 0.9 == 0.1 * 0.9 + 0.2 * 0.9False>>> (0.1 * 0.1 :: Float) * 0.9 == 0.1 * (0.1 * 0.9)False

See instance Ord Double for discussion of deviations from IEEE 754 standard.

Beware that toRational generates garbage for non-finite arguments:

>>> toRational (1/0 :: Float)340282366920938463463374607431768211456 % 1>>> toRational (0/0 :: Float)510423550381407695195061911147652317184 % 1

Beware that results for non-finite arguments are garbage:

>>> [ f x | f <- [round, floor, ceiling], x <- [-1/0, 0/0, 1/0 :: Float] ] :: [Int][0,0,0,0,0,0,0,0,0]>>> map properFraction [-1/0, 0/0, 1/0] :: [(Int, Float)][(0,0.0),(0,0.0),(0,0.0)]

and get even more non-sensical if you ask for Integer instead of Int.

Note - random produces values in the closed range [0,1].

See Floating point number caveats.

Uses non-IEEE754 encoding. Does not round-trip NaN.

Used for marking occurrences of Float#

fromEnum just truncates its argument, beware of all sorts of overflows.

List generators have extremely peculiar behavior, mandated by Haskell Report 2010:

>>> [0..1.5][0.0,1.0,2.0]

Note that due to the presence of NaN, Double's Eq instance does not satisfy reflexivity.

>>> 0/0 == (0/0 :: Double)False

Also note that Double's Eq instance does not satisfy substitutivity:

>>> 0 == (-0 :: Double)True>>> recip 0 == recip (-0 :: Double)False

This instance implements IEEE 754 standard with all its usual pitfalls about NaN, infinities and negative zero.

>>> 0 == (-0 :: Double)True>>> recip 0 == recip (-0 :: Double)False>>> map (/ 0) [-1, 0, 1][-Infinity,NaN,Infinity]>>> map (* 0) $ map (/ 0) [-1, 0, 1][NaN,NaN,NaN]

This instance implements IEEE 754 standard with all its usual pitfalls about NaN, infinities and negative zero. Neither addition nor multiplication are associative or distributive:

>>> (0.1 + 0.1) + 0.4 == 0.1 + (0.1 + 0.4)False>>> (0.1 + 0.2) * 0.3 == 0.1 * 0.3 + 0.2 * 0.3False>>> (0.1 * 0.1) * 0.3 == 0.1 * (0.1 * 0.3)False

IEEE 754 Double-precision type includes not only numbers, but also positive and negative infinities and a special element called NaN (which can be quiet or signal).

IEEE 754-2008, section 5.11 requires that if at least one of arguments of <=, <, >, >= is NaN then the result of the comparison is False, and instance Ord Double complies with this requirement. This violates the reflexivity: both NaN <= NaN and NaN >= NaN are False.

IEEE 754-2008, section 5.10 defines totalOrder predicate. Unfortunately, compare on Doubles violates the IEEE standard and does not define a total order. More specifically, both compare NaN x and compare x NaN always return GT.

Thus, users must be extremely cautious when using instance Ord Double. For instance, one should avoid ordered containers with keys represented by Double, because data loss and corruption may happen. An IEEE-compliant compare is available in fp-ieee package as TotallyOrdered newtype.

Moving further, the behaviour of min and max with regards to NaN is also non-compliant. IEEE 754-2008, section 5.3.1 defines that quiet NaN should be treated as a missing data by minNum and maxNum functions, for example, minNum(NaN, 1) = minNum(1, NaN) = 1. Some languages such as Java deviate from the standard implementing minNum(NaN, 1) = minNum(1, NaN) = NaN. However, min / max in base are even worse: min NaN 1 is 1, but min 1 NaN is NaN.

IEEE 754-2008 compliant min / max can be found in ieee754 package under minNum / maxNum names. Implementations compliant with minimumNumber / maximumNumber from a newer IEEE 754-2019, section 9.6 are available from fp-ieee package.

Beware that toRational generates garbage for non-finite arguments:

>>> toRational (1/0)179769313 (and 300 more digits...) % 1>>> toRational (0/0)269653970 (and 300 more digits...) % 1

Beware that results for non-finite arguments are garbage:

>>> [ f x | f <- [round, floor, ceiling], x <- [-1/0, 0/0, 1/0] ] :: [Int][0,0,0,0,0,0,0,0,0]>>> map properFraction [-1/0, 0/0, 1/0] :: [(Int, Double)][(0,0.0),(0,0.0),(0,0.0)]

and get even more non-sensical if you ask for Integer instead of Int.

Note - random produces values in the closed range [0,1].

See Floating point number caveats.

Uses non-IEEE754 encoding. Does not round-trip NaN.

Used for marking occurrences of Double#