To my remark on the *real* Real numbers
>> 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.
>> ...
>> In *this sense* i say that Real cannot be represented algorithmically.
Peter White [EMAIL PROTECTED] writes
> I think numerical algorithms using "Float" or "Double" already avoid
> testing for equality of floats or doubles ...
Avoid them it or not, Float it is very far from what a Real number means
in mathematics. So this is not right to compare the real Real to what
is arranged for Float.
Though, of course, Float is useful for many things.
> ... 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.
Of course, they could be used so, and it would be, probably, right to
call them infinite objects Real.
And, yes, much similarly, Haskell represents Hom(X,Y) by X -> Y.
As we used to do with the numbers much more than with the functions,
then the computational quality of algorithmic Real will hurt us a bit.
For example, we add the polynomials a*x^2+1 + (b*x^2 + x)
with Real coefficients and discover that it might be a problem to find
the *degree* of result.
Concerning the infinite continued fraction representation, it is good.
I only doubt whether it is better to leave it for application
mathematical programs.
One can even supply the Real representation with the explicit function
description
fTerm for the map f :: Integer -> Integer,
so that f(n) is the n-th element of the infinite continued fraction.
fTerm may be, say, a typeless lambda-expression.
Then the program can try to prove theorems on the number simplification
by processing fTerm-s!
Say, e^2+e^3 /= pi^4
- after the remarkable constants e,pi are coded as the fTerm-s (and
they can be coded so, this is like obtaining the decimal digits).
Only the thing is rather complex for the standard library.
--------------------------------------------------------------------
Ch.A.Herrmann <[EMAIL PROTECTED]> writes on 4 Aug 1998:
> we have to distinguish between 3 sets:
>
>(1) The set of algebraic numbers (rationals + roots etc.).
> An arbitrary finite subset of this set can be represented in the machine.
> Each element can be represented as a root of a polynomial
> with rational coefficients.
> An exact representation will be appropriate for things like testing,
> whether the square of the square root of 2 is 2.
> I guess (I don't know) that it is possible to test whether
> two representations represent the same number or not.
All the algebraic numbers can be represented by the programs - so that
the things you mention can be tested by the programs.
Only the design is complex and is a special subject of computer algebra
(or symbolic computation) software. The packages that do it are greater
in volum than the Haskell implementations.
The representation for such numbers is more complex than just a list of
digits.
The computational cost may grow enormously with the encrease of the
equation polynomial degrees ...
>(2) The set of all real numbers.
> An arbitrary finite subset cannot be represented in the machine.
> Specific subsets can be represented, if we agree upon codes
> for "e", "pi", "sum from i=a to b of ...", "integral" etc.
> The question is: how does evaluation of expressions with these
> numbers look like? Simplification based on heuristics?
As with the data H = Integer -> Integer in Haskell.
If the program it tired to compare f(x) == g(x) for different x
then it might use the explicit symbolic representation for f,g - if
it is somewhere given (for we might imagine that it is given).
Then, with this symbolic representation, it remains only to apply
simplification based on heuristics.
------------------
Sergey Mechveliani
[EMAIL PROTECTED]
