On 02-Aug-1998, Jan Skibinski <[EMAIL PROTECTED]> wrote:
>
> I've been recently working on yet another Haskell server, and when
> testing its safety limits on numerical examples, I realized that
> there are several quite annoying problems with Haskell numerical
> types and classes.
>
> + Many
On 3 Aug, [EMAIL PROTECTED] wrote:
> so sqrt :: (Numeric n, Floating f) => n -> f
whoops! I meant to say
sqrt :: (Numeric n, Numeric f) => n -> f
or something - the important bit was that the result type shouldn't be
constrained to be the same as the argument, because while sqrt int is
meani
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
At 16:00 +0400 98/08/03, S.D.Mechveliani wrote:
>Not only Complex but the Real numbers too are impossible to be presented
>adequately algorithmically.
Strictly speaking, the "real numbers" should be called floating numbers,
which one usually does in computer contexts if being more accurate.
>But where on Earth it is said that the domain of Complex numbers
>should be restricted to Float or Double? Why not Rationals as
>well?
In pure math, given a ring $R$, one speaks about its complexification
$R_\C = $R \tensor_\Z \Z[i]$ (using LaTeX commands and \tensor = \otimes,
\C = \mathbb{C}
Jan Skibinski <[EMAIL PROTECTED]> wrote on 2 Aug 1998
(Subject: Rambling on numbers in Haskell)
> ... I realized that there are several quite annoying problems with
> Haskell numerical types and classes.
> ...
> Yet again - as it has happened with other languages, someone
> has decided t
>
> 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
Hi Jan,
| ... I realized that
| there are several quite annoying problems with Haskell numerical
| types and classes.
| ...
| + Hugs is supplied with the type Number. According to its
| author: "Fixed width integers with overflow detection.. Unlike
| Int, overflows are detected and caus
To answer just one of Jan Skibinski's questions:
> + Haskell extension libraries define a bunch of Word types.
> An attempt to show that Haskell can be numerically efficient?
The motivation for adding Word{8,16,32,64} was to make it easier to
interface to foreign libraries which use the
Hi Jon:
>
> whoops! I meant to say
> sqrt :: (Numeric n, Numeric f) => n -> f
>
> or something - the important bit was that the result type shouldn't be
> constrained to be the same as the argument, because while sqrt int is
> meaningful it doesn't usually give an int result. What
Hi Mark:
> Please don't blame Haskell for the Number library; it isn't part
> of any Haskell standard.
I did not try blaming anyone or anyting. I was hoping
to initiate some constructive flow of solutions. Thank
you for your explanation. I had somehow anticipate
> | [..]
> | sufficient restrictions in this area Haskell's type system would
> | become undecidable, I decided to demonstrate this directly. In this
>
> It's great that you've done this, but I think someone ought to
> point out that this result, and even the basic method, is not
> actually new:
Hi Fergus:
>
> 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 is its potential
13 matches
Mail list logo
