Re: [Haskell-cafe] Strings in Haskell

[Bryan Donlan]

Neil Mitchell wrote:
> Hi Alexy,
>
>> Now I'm reading a
>> Haskell book which states the same.  Is there a more efficient Haskell
>> string-handling method?  Which functional language is the most
>> suitable for text processing?
>
> There are the Data.ByteString things, which are great, and have much
> less overhead.
>
> But remember that Haskell is lazy. If you are thinking "well I have to
> process a 50Mb file", remember that Haskell will lazily read and
> process this file, which substantially reduces the memory requirements
> so only a small portion will ever be in memory at a time.

Or you can get the best of both worlds by using Data.ByteString.Lazy :)
Even with laziness, all the indirections that String causes hurts 
performance.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Strings in Haskell

[Neil Mitchell]

Hi Alexy,


Now I'm reading a
Haskell book which states the same.  Is there a more efficient Haskell
string-handling method?  Which functional language is the most
suitable for text processing?


There are the Data.ByteString things, which are great, and have much
less overhead.

But remember that Haskell is lazy. If you are thinking "well I have to
process a 50Mb file", remember that Haskell will lazily read and
process this file, which substantially reduces the memory requirements
so only a small portion will ever be in memory at a time.

Thanks

Neil
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Strings in Haskell

[Spencer Janssen]

On Jan 22, 2007, at 7:18 PM, Alexy Khrabrov wrote:

Greetings -- I'm looking at several FP languages for data mining, and
was annoyed to learn that Erlang represents each character as 8 BYTES
in a string which is just a list of characters.  Now I'm reading a
Haskell book which states the same.


The standard string type in Haskell is indeed a linked list of  
characters, with about 12 bytes of overhead per character.



Is there a more efficient Haskell string-handling method?


Yes!  There is a library called Data.ByteString [1], it is included  
with the latest versions of GHC and Hugs, and is also available as a  
standalone package.  Data.ByteString represents strings as packed  
arrays of bytes, so the overhead is about 1 byte per character.  This  
library exhibits fantastic performance, rivaling C's speed while  
maintaining the elegance of Haskell.



Cheers,
Spencer Janssen

[1] http://www.cse.unsw.edu.au/~dons/fps.html


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Strings in Haskell

[Stefan O'Rear]

On Mon, Jan 22, 2007 at 05:18:19PM -0800, Alexy Khrabrov wrote:
> Greetings -- I'm looking at several FP languages for data mining, and
> was annoyed to learn that Erlang represents each character as 8 BYTES
> in a string which is just a list of characters.  Now I'm reading a
> Haskell book which states the same.

The book is lying - the size of strings is unspecified and implementation
dependant.  In GHC String is 12 or 20 bytes per character, depending on
construction details.

> Is there a more efficient Haskell string-handling method?

Yes!  Data.ByteString.* implements packed strings of bytes.  They are less
lazy, and don't support unicode, but they are small (8 bits / character)
and fast (I have 100 MBy/s disks and my ByteString-based throwaway filters
are IO-bound).

> Which functional language is the most suitable for text processing?

If you expected any answer other than Haskell, you asked on the wrong list. :)

Stefan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Strings in Haskell

[Alexy Khrabrov]

Greetings -- I'm looking at several FP languages for data mining, and
was annoyed to learn that Erlang represents each character as 8 BYTES
in a string which is just a list of characters.  Now I'm reading a
Haskell book which states the same.  Is there a more efficient Haskell
string-handling method?  Which functional language is the most
suitable for text processing?

Cheers,
Alexy
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: IO in lists

[Dan Piponi]

Magnus Therning asked:


but how do I go about creating a finite list, e.g. a list that ends as
soon as 'q' is pressed?


A slightly different approach that doesn't use anything unsafe:

What you want is to return something like an IO [Char] but it needs to
be able to interleave IO. A list of type [Char] is essentially a
solution to the equation
X = Maybe (Char,X)
It's either the empty list (represented by Nothing) or Just a pair of
the head and tail of the list. But this doesn't allow us to
intersperse IO along the computation of the list. In order to to that
we need a solution to
X = IO (Maybe (Char,X))

So define

data X = X { unX :: IO (Maybe (Char,X)) }

We can now write the 'q' terminated list as

test = X $ do
   a <- getChar
   if a=='q'
   then return Nothing
   else return (Just (a,test))

For all intents and purposes, this is what you want. It reads
characters until it reaches a 'q' and then returns IO Nothing.

To make use of this we can write something like this to print out the
contents of the list:

test2 :: X -> IO ()
test2 test = do
   a <- unX test
   case a of
   Nothing -> return ()
   Just (a,b) -> do
   print a
   test2 b

'test2 test' now prints out one of these q-terminated strings. There
is a bit of clutter because of the X and unX. And it's slightly
wordier because we're using Maybe instead of the nice Haskell List
notation. But I think it does exactly what you want. In particular we
have sepration of concerns - the object 'test' is in charge of
generating data and test2 is responsible for reading it, without
unsafe operations. And it seems to print the characters one at a time
as they are entered (with ghc).
--
Dan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: GHC concurrency runtime "breaks" every 497 (and a bit) days

[Benjamin Franksen]

Neil Davies wrote:
> In investigating ways of getting less jitter in the GHC concurrency
> runtime I've found the following issue:
> 
> The GHC concurrency model does all of its time calculations in "ticks"
> - a tick being fixed at 1/50th of a second. It performs all of these
> calculations in terms the number of these ticks since the Unix epoch
> (Jan 1970). Which is stored as an Int - unfortunately this 2^31 bits
> overflows every 497 (and a bit) days.
> 
> When it does overflow any threads on the timer queue will either a)
> run immediately or b) not be run for another 497 days - depending on
> which way the sign changes. Also any timer calculation that spans the
> wrapround will not be dealt with correctly.
> 
> Although this doesn't happen often (the last one was around Sat Sep 30
> 18:32:51 UTC 2006 and the next one will not be until Sat Feb  9
> 21:00:44 UTC 2008) I don't think we can leave this sort of issue in
> the run-time system.
> 
> Take a look at the definition of getTicksofDay (in
> base/include/HsBase.h (non-windows) / base/cbits/Win32Utils.c) and
> getDelay (in base/GHC/Conc.lhs) to understand the details of the
> issue.
> 
> I don't mind having a go at the base system to remove this problem -
> but before I do I would like to canvas some opinions. I'll do that in
> a separate thread.

I answer but on this thread because IMO the overflow is a /much/ more
serious problem than the jitter due to unnecessarily coarse rounding.
Fortunately both can be solved together, by using 64 bit timestamps and the
highest available resolution. In my experience avoiding overflow by using
enough bits is a lot more reliable than any trick to 'handle' overflow.
With 64 bit timestamps, even if the base resolution is as small as one
nanosecond (which is lot more than you get on stock hardware even if you
use raw hardware timers), you still get overflow only every 585 years which
I would deem acceptable for all practical purposes.

BTW, the timer resolution should be available as a (platform dependent)
constant. Maybe it would even be useful to define a simple external
interface (to the RTS, i.e. in C) so that advanced users may plug in e.g.
extra hardware timers for ultimate resolution.

Cheers
Ben

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Resolution of time for threadDelay / registerDelay

[Neil Davies]

The GHC concurrency run time currently forces all delays to be
resolved to 1/50th of second - independent of any of the run time
settings (e.g. -V flag) - with rounding to the next 1/50th of second.

This means that, in practice, the "jitter" in the time that a thread
wakes as compared with can be rather large - 20ms to 30ms; 20ms from
the GHC base library rounding along with a "jiffy" from the operating
system.

As far as I can see there is no reason why there should be any
quantization of delay times - the implementation creates an ordered
list of times which could be at any resolution (say microseconds) -
this would reduce the "jitter" to that of an operating system jiffy.

Thoughts?

Neil
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] GHC concurrency runtime "breaks" every 497 (and a bit) days

[Neil Davies]

In investigating ways of getting less jitter in the GHC concurrency
runtime I've found the following issue:

The GHC concurrency model does all of its time calculations in "ticks"
- a tick being fixed at 1/50th of a second. It performs all of these
calculations in terms the number of these ticks since the Unix epoch
(Jan 1970). Which is stored as an Int - unfortunately this 2^31 bits
overflows every 497 (and a bit) days.

When it does overflow any threads on the timer queue will either a)
run immediately or b) not be run for another 497 days - depending on
which way the sign changes. Also any timer calculation that spans the
wrapround will not be dealt with correctly.

Although this doesn't happen often (the last one was around Sat Sep 30
18:32:51 UTC 2006 and the next one will not be until Sat Feb  9
21:00:44 UTC 2008) I don't think we can leave this sort of issue in
the run-time system.

Take a look at the definition of getTicksofDay (in
base/include/HsBase.h (non-windows) / base/cbits/Win32Utils.c) and
getDelay (in base/GHC/Conc.lhs) to understand the details of the
issue.

I don't mind having a go at the base system to remove this problem -
but before I do I would like to canvas some opinions. I'll do that in
a separate thread.

Neil
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] strange behavior in Text.Regex.Posix

[John MacFarlane]

Can anyone help me understand this odd behavior in Text.Regex.Posix (GHC 6.6)?

Prelude Text.Regex.Posix Text.Regex> subRegex (mkRegex "\\^") "he\350llo" "@"
"[EMAIL PROTECTED]"

Why does /\^/ match \350 here?  Generally Text.Regex.Posix seems to work
fine with unicode characters.  For example, \350 is treated as a single
character here:

Prelude Text.Regex.Posix Text.Regex> subRegex (mkRegex "e.l") "he\350llo" "@"
"[EMAIL PROTECTED]"

The problem is specific to \350 and doesn't happen with, say, \351:

Prelude Text.Regex> subRegex (mkRegex "\\^") "he\351llo" "@"
"he\351llo"

Is this a bug, or just something I'm not understanding?

John

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Type infer

[Marco Túlio Gontijo e Silva]

Hello,

I'm trying to define a partition__ function that is like
Data.Set.partition, but use State Monad:

> import Data.Set
> import Control.Monad.State

> partition__ f =
> do
> snapshot <- get
> let
> (firsts, rest) = Set.partition f snapshot
> put rest
> return firsts

When I try to infer it's type in ghci I got:

$ ghci
   ___ ___ _
  / _ \ /\  /\/ __(_)
 / /_\// /_/ / /  | |  GHC Interactive, version 6.6, for Haskell 98.
/ /_\\/ __  / /___| |  http://www.haskell.org/ghc/
\/\/ /_/\/|_|  Type :? for help.

Loading package base ... linking ... done.
Prelude> :load partition.hs
[1 of 1] Compiling Main ( partition.hs, interpreted )
Ok, modules loaded: Main.
*Main> :type partition__
partition__ :: (MonadState (Set a) t, Ord a) => (a -> Bool) -> t (Set a)

Ok, then I add

> partition__ :: (MonadState (Set a) t, Ord a) => (a -> Bool) -> t (Set
a)

to the file and then:

*Main> :reload
[1 of 1] Compiling Main ( partition.hs, interpreted )

partition.hs:4:0:
Non type-variable argument in the constraint: MonadState (Set a) t
(Use -fglasgow-exts to permit this)
In the type signature for `partition__':
  partition__ :: (MonadState (Set a) t, Ord a) =>
 (a -> Bool) -> t (Set a)
Failed, modules loaded: none.

Why do I need glasgow-exts to specify a type infered by GHCi without
-fglasgow-exts?

Thanks.

-- 
malebria
Marco Túlio Gontijo e Silva
Correio (MSN): [EMAIL PROTECTED]
Jabber (GTalk): [EMAIL PROTECTED]
Ekiga: [EMAIL PROTECTED]
IRC: [EMAIL PROTECTED]
 [EMAIL PROTECTED]
Skype: marcotmarcot
Telefone: 33346720
Celular: 98116720
Endereço:
Rua Paula Cândido, 257/201
Gutierrez 30430-260
Belo Horizonte/MG Brasil

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ANN: regex-* updates and regex-tdfa 0.20 first release

[Chris Kuklewicz]

Greetings.  I have several bits of news about regex-* packages.

  First: I have fixed a small bug in one instance of RegexContext, defined in
Text.Regex.Contex in the regex-base class (included in GHC).  The new version of
regex-base is 0.80 and is available at
http://darcs.haskell.org/packages/regex-unstable/regex-base/.  The instance
fixed was
> instance (RegexLike a b) => RegexContext a b (MatchResult b) where
and I doubt this affects anyone at the moment.

  Second: There is also a new version of regex-tre at
http://darcs.haskell.org/packages/regex-unstable/regex-tre/ (version
0.81) that exposes the 'compRightAssoc' option when making a Regex
(see Text.Regex.TRE.Wrap for all the options).

  Third: I wish to note that that the libtre backend (up to the
current version 0.7.5) that regex-tre uses is buggy and that regex-tre
/ libtre should only be used where testing shows that no bugs are
being trigged.  (Why go to that much trouble?  Because the libtre
backend is very very fast).

  Fourth: The fabulous new all Haskell POSIX compatible backend!

  This is a first announcement of regex-tdfa, my "tagged" DFA regular
expression backend.  It is an implementation of regular expressions in
Haskell; it does not hand off the data to a library written in c.  The
ultimate goal of regex-tdfa is to replace regex-posix as the default
engine that come with GHC.  Why go to the trouble of replacing
regex-posix?  Because regex-posix is very very slow (and not quite
POSIX, as seen at the end of this message).

  The new regex-tdfa does not use the slow backtracking method like my
pure Haskell backend regex-posix.  It uses a deterministic finite
automata, similar in spirit to one I derived from CTKlight for use in
the pure Haskell regex-dfa backend (which is LGPL -- the rest are
BSD-3 license).  But regex-dfa is fast at a cost of not returning any
parenthesized subexpression captures (i.e only \0 and not \1 \2 \3
...).

  The regex-tre backend (BSD3) that uses the libtre c library (LGPL)
employs a special "tagged" dfa technique to get subexpression captures
while still using an efficient DFA.  The regex-posix engine that comes
with GHC is impossibly slow but regex-tre is very very fast and
(claims to also be) a POSIX engine. I was thus inspired to create
regex-tdfa which aims to create a pure Haskell variant of this
tagged-DFA algorithm under a simple BSD3 license.

  The 0.20 version of regex-tdfa that I am announcing is available at
http://darcs.haskell.org/packages/regex-unstable/regex-tdfa/ and
requires the updated regex-base (version 0.80 or greater) and is
setup to compile for GHC 6.6.  These could be back-ported to GHC 6.4
by adding the fps package to GHC 6.4 to get Data.ByteString and
removing references to Data.Sequence in the new regex-base and
regex-tdfa packages.

  As of now, my first untuned version of the regex-tdfa backend
performs about 2-3 times slower than regex-tre and the libtre c
library.  This also means regex-tdfa performs 3+ times faster than the
regex-parsec engine.  So the goal of a fast replacement for
regex-posix is close to hand.

  The bad news: libtre has two problems, the first is that it is
buggy.  I have found patterns that the libtre engine does not handle
correctly: the wrong match for the whole expression and/or
subexpressions is returned (or it will fail to match when it should
have succeeded).  The second problem is that it does not always follow
the POSIX standard policy in determining which possible parenthesized
subexpession captures to return when there are several possibilities.

  My regex-tdfa engine does not have the bugs that I have found in
libtre.  But since it uses the same design concepts as libtre it had
the same problem with not following the POSIX standard policy for
capturing subexpressions.  To fix this I have exteneded the tagging
technique to keep enough information to follow the POSIX spec.  So of
all the regex-* backends, the regex-tdfa is the only one that passes
all the tests that I have for POSIX compatibility.

  End note: The regex-posix engine, despite its name, does not follow the POSIX
standard policy for capturing subexpressions.  Example 1 of 2:
"ab" =~ "((a?)((ab)?))(b?)"
This should capture the sub ranges (0,2)(0,2)(0,0)(0,2)(0,2)(2,2)
But it does capture the sub ranges (0,2)(0,1)(0,1)(1,1)(-1,-1)(1,2)
The first group is (0,2) means the whole match was \0=="ab"
The second group (0,2) or (0,1) means the first group "((a?)((ab)?))" should
match \1=="ab" but it returns \1=="a".  This first group should have been chosen
for maximum length and the failure to do so is a policy violation.

Example 2 of 2:
"x" =~ "(.?)*"
This should capture: (0,1)(0,1)
But it does capture: (0,1)(1,1)
The first group of (0,1) means the regex did match the whole \0=="x".
But the regex-posix engine matched an extra iteration of the "(.?)" under the
"*" operator against the empty string after the "x" and returned the empty
capture of (1,1).  This highly non-useful behavior vio

[Haskell-cafe] Haskell -> Tk

[Peter Padawitz]

Does anybody know O'Haskell or Timber and its interface Tk.hs to Tcl/Tk 
(see here )?


I have the following problem:

Tk.hs  contains a 
record (structure) /Canvas/ with selectors


line  :: [(Int,Int)]  -> [LineOpt]  -> Request Line
polygon   :: [(Int,Int)]  -> [PolygonOpt]   -> Request Polygon

that are compiled into synonymous Tk widgets for lines and polygons, respectively. Unfortunately, Tk.hs crashes if the point list parameter of line or polygon 
contains more than 100 points. Why??? 

Of course, one may split a point list into smaller ones that are compiled correctly. But this may not produce the same picture, for instance, if the entire list 
represents a polygon to be filled or a line to be smoothened.


Peter


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Problems using Storable.poke* from separate OS thread.

[Corey O'Connor]

On 1/21/07, Lemmih <[EMAIL PROTECTED]> wrote:



Do you have a smaller test case? I couldn't reproduce the error after
I pulled out the MacOS stuff.



No, I don't have a smaller test case yet. I'm trying to reproduce the same
environment as the CoreAudio IO proc using a real-time scheduled pthread.
Which is what I understand CoreAudio is doing. I'm starting to think the
problem could be:
- Interference with the alarm signal haskell uses to schedule. There is a
bug filed in GHC's trac system, so I presume it's still true, but I haven't
located the code in GHC that sets this up.
- The haskell code is too slow. If a coreaudio IO proc takes too long the
system will still call the callback but essentially silence all output.
Which is what is consistent with what I observed, but doesn't explain why
code after the poke* call is not occuring.

--
-Corey O'Connor
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Fractional sqrt

[Yitzchak Gale]

I wrote:

I added a new page for the Numeric Quest library...

http://www.haskell.org/haskellwiki/Numeric_Quest


I also updated the references to Numeric Quest
on the Mathematics and Physics page.

http://www.haskell.org/haskellwiki/Libraries_and_tools/Mathematics

Henning Thielemann wrote

I would not throw away the links to the Internet archive


For modules that were previously mentioned on the
Mathematics page and not re-hosted in your darcs
repo, I left the links as they were.

For modules that are in the repo, the original version
can always be obtained from the repo. In addition,
there is a link on the Numeric Quest page to the
author's main Haskell page in the Internet Archive.

From there, it is easy to navigate with one click

to any of the author's original work still available in
the Archive, including all of the modules that are
also in the darcs repo.

Perhaps I should add a note to that effect.

I intentionally removed the direct links to the Archive
from the Mathematics page for modules that are now
in your repo. I estimate that people clicking from there
are more likely to be lead astray than to be helped.

Do you think it is important to have a separate link
for each repo module to the Internet Archive?
If so, they can be added to the Numeric Quest
page.


The Darcs repository at cvs.haskell.org is no official update by Jan
Skibinski - I set up that repository to simplify further development.


OK - I'll add a note to that effect.


I added the keyword "continued fractions" to the Wiki page so the module
can be discovered by other people.


Good, thanks.

-Yitz
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Fractional sqrt

[Ian Lynagh]

On Mon, Jan 22, 2007 at 03:26:38PM +0200, Yitzchak Gale wrote:
> 
> Can someone with access to darcs.haskell.org
> please fix this library? darcs get currently does not
> seem to work for it.
> 
> http://darcs.haskell.org/numeric-quest/

I've fixed the permissions, although applying patches in the future
might break them again.


Thanks
Ian

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Fractional sqrt

[Henning Thielemann]

On Mon, 22 Jan 2007, Yitzchak Gale wrote:

> Henning Thielemann wrote:
> > > > there is already an implementation of continued
> > > > fractions for approximation of roots and transcendent functions by Jan
> > > > Skibinski:
> > > >  http://darcs.haskell.org/numeric-quest/Fraction.hs
> 
> I wrote:
> > > Wow, nice. Now - how was I supposed to have found that?
> 
> Simon Peyton-Jones wrote:
> > Perhaps one of you can add this to the libraries-and-tools page?
> http://www.haskell.org/haskellwiki/Libraries_and_tools/
> 
> I added a new page for the Numeric Quest library,
> and added it to the Mathematics category.
> (Should it be in any other category?)
> I also updated the references to Numeric Quest
> on the Mathematics and Physics page.

Great work! However I would not throw away the links to the Internet
archive because the pages stored there link to the original HTML pages
which are lost. It's cumbersome to navigate through the archived pages.  
The Darcs repository at cvs.haskell.org is no official update by Jan
Skibinski - I set up that repository to simplify further development.

I added the keyword "continued fractions" to the Wiki page so the module
can be discovered by other people.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Fractional sqrt

[Yitzchak Gale]

Henning Thielemann wrote:

there is already an implementation of continued
fractions for approximation of roots and transcendent functions by Jan
Skibinski:
 http://darcs.haskell.org/numeric-quest/Fraction.hs


I wrote:

Wow, nice. Now - how was I supposed to have found that?


http://www.haskell.org/haskellwiki/Libraries_and_tools/

It turns out that it is mentioned on the wiki, on the
Mathematics and Physics subpage of Libraries and Tools.

http://www.haskell.org/haskellwiki/Libraries_and_tools/Mathematics

But the references were a bit unclear and out of date.

I added a new page for the Numeric Quest library,
and added it to the Mathematics category.
(Should it be in any other category?)
I also updated the references to Numeric Quest
on the Mathematics and Physics page.

Can someone with access to darcs.haskell.org
please fix this library? darcs get currently does not
seem to work for it.

http://darcs.haskell.org/numeric-quest/

Also, these modules should each be moved into
the hierarchy somewhere. Does anyone have
suggestions? It may help to look at:

http://www.haskell.org/haskellwiki/Numeric_Quest

Thanks,
Yitz
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe