# Difference between revisions of "Ord instance"

(sketch) |
(Bool and Complex) |
||

Line 7: | Line 7: | ||

Depending on these opinions we come to different conclusions |
Depending on these opinions we come to different conclusions |
||

whether there should be <hask>Ord</hask> instances for <hask>Bool</hask> and <hask>Complex</hask> numbers. |
whether there should be <hask>Ord</hask> instances for <hask>Bool</hask> and <hask>Complex</hask> numbers. |
||

+ | In most circumstances expressions like <hask>a < b</hask> are certainly a bug, |
||

+ | when <hask>a</hask> and <hask>b</hask> are <hask>Bool</hask> or <hask>Complex</hask> numbers. |
||

+ | Consider someone rewrites an algorithm for real numbers to complex numbers |
||

+ | and he relies on the type system to catch all inconsistencies. |
||

+ | The field operations can remain the same, but <hask>(<)</hask> has to be applied to results of <hask>abs</hask>, |
||

+ | <hask>realPart</hask> or other functions that yield a real. |
||

+ | The truth of <hask>False < True</hask> relies on the encoding of <hask>False</hask> by 0 and <hask>True</hask> by 1. |
||

+ | However there are also programming languages that represent "true" by -1, because this has bit pattern 1....1. |
||

+ | The CPU has an instruction to fill a byte with the content of a flag |
||

+ | and you can use this bit pattern for bitwise AND and OR operations. |
||

+ | This makes that representation very efficient. |
||

+ | In such a language it is <hask>False > True</hask>. |
||

+ | If you use the numeric value of boolean values for arithmetics like in <hask>2 * fromEnum bool - 1</hask> |
||

+ | in order to map <hask>False</hask> to -1 and <hask>True</hask> to 1 without an <hask>if-then-else</hask>, |
||

+ | then porting a program between different representations of boolean values becomes error-prone. |
||

− | == Ord for magnitudes == |
||

+ | However you like to work with <hask>Set</hask>s of boolean values and complex numbers, |
||

+ | and <hask>Set</hask> requires an <hask>Ord</hask> instance. |
||

− | == Ord for arbitrary total orderings == |
||

== See also == |
== See also == |

## Revision as of 09:20, 3 September 2010

What is the meaning of the `Ord`

instance?
Certainly most people agree that an `Ord`

instance shall provide an total ordering.
However opinions differ whether there shall be more in it:

- An
`Ord`

instance may also suggest a notion of magnitude - An
`Ord`

instance may be free of any other association

Depending on these opinions we come to different conclusions
whether there should be `Ord`

instances for `Bool`

and `Complex`

numbers.
In most circumstances expressions like `a < b`

are certainly a bug,
when `a`

and `b`

are `Bool`

or `Complex`

numbers.
Consider someone rewrites an algorithm for real numbers to complex numbers
and he relies on the type system to catch all inconsistencies.
The field operations can remain the same, but `(<)`

has to be applied to results of `abs`

,
`realPart`

or other functions that yield a real.
The truth of `False < True`

relies on the encoding of `False`

by 0 and `True`

by 1.
However there are also programming languages that represent "true" by -1, because this has bit pattern 1....1.
The CPU has an instruction to fill a byte with the content of a flag
and you can use this bit pattern for bitwise AND and OR operations.
This makes that representation very efficient.
In such a language it is `False > True`

.
If you use the numeric value of boolean values for arithmetics like in `2 * fromEnum bool - 1`

in order to map `False`

to -1 and `True`

to 1 without an `if-then-else`

,
then porting a program between different representations of boolean values becomes error-prone.

However you like to work with `Set`

s of boolean values and complex numbers,
and `Set`

requires an `Ord`

instance.

## See also

- Haskell-Cafe on Unnecessarily strict implementations