On 13 Aug 1999 Rene Grognard [EMAIL PROTECTED] writes
[..]
My question is therefore: is Haskell at all suitable for complex numerical
applications ?
[..]
Furthermore would Haskell be a suitable language allowing
symbolic/algebraic numerical algorithms to live happily under the same
Sat, 14 Aug 1999 02:31:00 +1000, Fergus Henderson [EMAIL PROTECTED] pisze:
The merits of this restriction have been the subject of quite a
bit of debate. I think there is a reasonably good chance that it
may be dropped in Haskell 2.
How does the Haskell standard evolve? Who decides how it
(3) OK with GHC, error with Hugs:
f = \x - m x
x = f()
...
- Is GHC's treatment of (3) a bug?
At first glance it looks a bit that way to me, but
I will leave it for the more knowledgable Haskell experts
to give you a definitive answer on that one.
IIRC it's a known bug in Hugs,
TclHaskell was just announced here, and I grabbed the distribution this
morning. I was very eager to get started messing around with this, but
the TclHaskell manual is distributed as a Microsoft Word document which I
can't use and as a file that purports to be HTML. By "purports" I mean
that my
Given
class C a where
m :: a - ()
instance C () where
m() = ()
we observed the following behaviour:
(0) Error with GHC and Hugs:
f = \x - m x
(1) OK with GHC and Hugs:
f1 x = m x
(2) OK with GHC and Hugs:
f :: C a = a - ()
f = \x - m x
(3) OK with GHC, error with Hugs:
f = \x -
On Fri, 13 Aug 1999, Rene Grognard wrote:
My question is therefore: is Haskell at all suitable for complex numerical
applications ?
_In my opinion_, Haskell is suitable for numerical programming if you
don't need performance close to C (because your problems are small say and
you're
Most numeric analysis packages have some sort of global precission setting.
Are there any major obsticalls with having lazy precission through out a
numeric analysis package? (dose this cause a big-O type hit to any of the
algorithms which are commonly used in such packages) And would making
