Sergey Mechveliani <[EMAIL PROTECTED]> writes:
> Only one has to prepare to script
> let {real1 =...; real2 =...} in real1==real2
>
> and obtain error "cannot solve real1==real2 ..."
> or, maybe, an infinite loop - both at run time.
>
> We guess, why:
> either the equality is solved for some arguments *not* like it
> should solve for Real,
> or
> it terminates in the above way for some arguments.
>
> In *this sense* i say that Real cannot be represented algorithmically.
I think numerical algorithms using "Float" or "Double" already avoid
testing for equality of floats or doubles, because after a few steps
of a numerical algorithm equality would occur more by coincidence than
by design. It seems that the situation is similar to equality for functions.
Functions, and higher order types such as Int -> Int are certainly used
in Haskell programming, however the language does not offer an equality
test for functions, since Int -> Int is not in the Eq class. Similarly,
reals (with unbounded representations) could be used in Haskell programs,
but no test for equality would be offered by the language. The user could
certainly implement an operator "equal within epsilon", which is really
the test used in numerical algorithms.
Peter White
[EMAIL PROTECTED]
