On 3 Aug, Jan Skibinski wrote:
>> How hard is it to write "import Complex"?
>>
>
> Not hard at all, but I think I did not make myself
> clear in my previous post. Here is the clarification:
>
> One of the benefits of having Complex closely coupled
> with other numbers
That of itself is not an argument for its inclusion in the language
core rather than in a library. I think that there is a general
agreement that the number hierarchy needs an overhaul, which could go
a long way towards adressing your complaints.
> is its potential utilization in error handling.
> So far, evaluation of sqrt (-1) produces unrecoverable error.
I think that there is some confusion wrt types here. If you are
hoping for a floating answer, sqrt (-1) has to produce an error.
While in some cases a Number type (like Miranda) may be useful, I
think the 'proper' solution in most cases is to make the types of
things like sqrt overloaded to reflect their properties.
so sqrt :: (Numeric n, Floating f) => n -> f
> Not only sqrt, but a bunch of other functions could be
> rescued in a similar way:
>
> log (-1)
same overloading as sqrt, then
> asin (4/3) - currently interpreted as Floating, produces NaN
different issue (press the button on Kent for details ;-)
> Anyone can design a complex number library. The task is
> not much more complex (pun intended:-) than dsigning
> the type Point.
> What is difficult though is to make Complex a citizen
> of the world of existing numbers.
Right, but it should be done via a class hierarchy, not by squishing
all the numbers into one type.
--
Jon Fairbairn [EMAIL PROTECTED]
