# Ord instance

### From HaskellWiki

(Bool and Complex) |
(corrections) |
||

(One intermediate revision by one user not shown) | |||

Line 18: | Line 18: | ||

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

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

− | In | + | In principle we could also provide machine dependent efficient representations of boolean values in Haskell. |

+ | If "true" is associated with -1 then it holds <hask>False > True</hask>. | ||

If you use the numeric value of boolean values for arithmetics like in <hask>2 * fromEnum bool - 1</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>, | in order to map <hask>False</hask> to -1 and <hask>True</hask> to 1 without an <hask>if-then-else</hask>, | ||

Line 25: | Line 26: | ||

However you like to work with <hask>Set</hask>s of boolean values and complex numbers, | 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. | and <hask>Set</hask> requires an <hask>Ord</hask> instance. | ||

+ | You may consider using the <hask>Ord</hask> instance by <hask>Set</hask> operations an abuse, | ||

+ | since they do not require a particular ordering. | ||

+ | Ordering is only needed for implementation of efficient <hask>Set</hask> operations | ||

+ | and the operations would be as efficient, if the order is reversed or otherwise modified. | ||

+ | But we would certainly not like to have <hask>1 < 2</hask> for <hask>Integer</hask>s | ||

+ | and <hask>1 > 2</hask> for, say, <hask>Rational</hask>s. | ||

+ | |||

+ | The solution might be a type class especially for <hask>Set</hask> and <hask>Map</hask>. | ||

+ | However it would miss automatic instance deriving. | ||

## Latest revision as of 09:35, 3 September 2010

What is the meaning of theHowever opinions differ whether there shall be more in it:

- An instance may also suggest a notion of magnitudeOrd
- An instance may be free of any other associationOrd

Depending on these opinions we come to different conclusions

whether there should beConsider 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, butHowever 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 principle we could also provide machine dependent efficient representations of boolean values in Haskell.

If "true" is associated with -1 then it holdsthen porting a program between different representations of boolean values becomes error-prone.

However you like to work withsince they do not require a particular ordering.

Ordering is only needed for implementation of efficientand the operations would be as efficient, if the order is reversed or otherwise modified.

But we would certainly not like to haveHowever it would miss automatic instance deriving.

## [edit] See also

- Haskell-Cafe on Unnecessarily strict implementations