> What about `=='?
A very good question!
The answer to which is that `==' doesn't really exist for real numbers
and nor does `<=', but max and min do. Even for Floats and Doubles,
sensible numeric code ought to have overlapping domains: i.e.
f(x) = if x < k +/- epsilon then g(x) else h(x)
^^^^^^^^^^^
[the tolerance of the comparison]
then g(x) ought to be defined upto k+epsilon, and h(x) ought to be
defined from k-epsilon.
> Is it guaranteed that if `x == y' is true then
> `f x == f y' is true for all `f' (presuming that `f x == f y' is
> type-correct and does not evaluate to bottom)?
In general this isn't possible.
> For that matter, are functions required to always return the same results
> for the same arguments?
Exercise:
Without using non-computable operations and concepts such as
`==', cast the above into mathematics.
[This can be done, see my paper in Glasgow FP workshop 1991, section 1]
Provided you accept the limitation of computable continuity on the
function and mumble about what it means to be the `same' then yes, we
can ensure that functions give the `same' answer for the `same'
arguments.
> If that were the case, then it would prevent certain optimizations,
> e.g. replacing `(x + 0.1) + 0.2' with `x + 0.3', because such
> optimizations can change the results returned. Does Haskell allow
> these sort of optimizations?
What I would hope is that user-placed parentheses would prevent
constant-folding. The alternative is that the Haskell compiler becomes
a skilled Numerical Analyst.
---
David Lester.
