>
> Not only Complex but the Real numbers too are impossible to be presented
> adequately algorithmically.
> In this sense, they differ from Rational greatly.
> Therefore, i propose for Haskell to name RealLike what it might call
> Real, and ComplexLike - what it might call Complex.
>
> On the other hand, Integer is indeed more important than Complex.
> Because ComplexLike can be programmed easily via Integer.
I am not saying otherwise, I am just saying that other
numbers should be aware of Complex for variety of reasons.
I think I answered it somewhere else.
Rational is currently defined by two Integers and Complex could be
defined by two Rationals, rather than by two Floatings.
But the Rational would have to be generalized, so one
could do the same basic oparations on Rationals as is currently
defined for Floatings: sqrt, log, sin, sinh, etc.
For me Floating is just one possible approximation of Real.
Some people do not even realize how punctured a Double
can be when they try to use it as a representation of a big
number. After all the logarithmic scale is used here and one
should be aware of really big "black holes" for big numbers.
I know of some poor souls that tried to use it for business
applications.
Imagine millions of dollars misteriously vanishing from some
corporate account, because Double was used to represent
dollars and cents? :-)
In contrary, sticking for a moment to a continued fraction, I can
think of any desired accuracy of a representation of an Irrational
number that can achieved this way.
For example, say you defined sqrt this way
sqrt :: Rational -> Rational -> Rational
then you could call sqrt to compute square root of 2 with
an accuracy 10^(-9), for example:
sqrt (1/1000000000) 2 ==> 66922 % 47321 ==> 1.414213562
For this you'd have to evaluate 13 steps in continued
fraction expansion. But if you do not care for any accuracy
better than 0.001 then 5 steps would suffice. You just
specify the accuracy and the sqrt function would do all
what is needed to achieve it.
Same way we could compute pi, e, sinh, etc. And as I
was saying in my original post - there are better ways
of doing this. And more efficient too! What I understand,
the efficient implementations of Irrationals are around
the corner.
>
> The main issue on Maple, Matlab, Mathematica ... is that they are the
> computer algebra systems.
> And Haskell is an universal programming language and tool.
So? Eiffel was also conceived as a general language,
until they realized the need for math library.
Same with C and other languages. And now you have
wavelets and The Best Fourier Transform On The West
(or whatewever they call it) implemented in C.
> It would be more natural to write an application in Haskell which would
> do what these CA programs do.
> In particular, i am developing such a program
> (DoCon-1.07 <haskell.org/docon/> ); hope to release DoCon-2 this year.
> Real and Complex (as Float) are not yet there, but, say, Rational-Complex,
> Gaussian integers, and such, they are.
Interesting, but what I sense here is an unnecessary complexity.
But I look forward to seeing it.
>
> I am going to suggest the more appropriate algebraic class hierarchy for
> Haskell-2.
> I wonder how lowd the community will start cussing.
> This will touch the so-called numeric classes too
> (Number classes are inside the Algebraic ones, but Haskell-1.4 somehow
> does not notice the difference at all).
> For, probably, many people think that Haskell-2 has not to care for not
> breaking the Haskell-1.4 apllication code.
I've already seen a statement saying that Haskell-2 does
not have to be compatible with Standard Haskell.
Jan
