I just saw this on the OCaml list (in a posting by Rafael 'Dido'
Sevilla [EMAIL PROTECTED] in the Observations on OCaml vs. Haskell
thread). I can't believe that a simple wc implementation should be
570 times slower in Haskell than OCaml - could someone investigate and
fix the test?
--KW 8-)
Keith Wansbrough [EMAIL PROTECTED] writes:
I can't believe that a simple wc implementation should be
570 times slower in Haskell than OCaml - could someone investigate and
fix the test?
With code like this, I'm not surprised!
main = do file - getContents
On Tue, Sep 28, 2004 at 10:46:14AM +0100, Keith Wansbrough wrote:
I just saw this on the OCaml list (in a posting by Rafael 'Dido'
Sevilla [EMAIL PROTECTED] in the Observations on OCaml vs. Haskell
thread). I can't believe that a simple wc implementation should be
570 times slower in
On Tue, Sep 28, 2004 at 12:01:11PM +0200, Tomasz Zielonka wrote:
On Tue, Sep 28, 2004 at 10:46:14AM +0100, Keith Wansbrough wrote:
I just saw this on the OCaml list (in a posting by Rafael 'Dido'
Sevilla [EMAIL PROTECTED] in the Observations on OCaml vs. Haskell
thread). I can't believe
On Tue, Sep 28, 2004 at 12:49:52PM +0200, Tomasz Zielonka wrote:
On Tue, Sep 28, 2004 at 12:01:11PM +0200, Tomasz Zielonka wrote:
On Tue, Sep 28, 2004 at 10:46:14AM +0100, Keith Wansbrough wrote:
I just saw this on the OCaml list (in a posting by Rafael 'Dido'
Sevilla [EMAIL PROTECTED]
On Tue, 28 Sep 2004, Tomasz Zielonka wrote:
Changed readArray to unsafeRead, and it is 47 times faster now.
I must say I am pleasantly surprised that GHC managed to unbox
everything there was to unbox without much annotations. For 5MB file the
program allocated only 192KB in the heap.
[ haskell newbie alert ]
On 2004-09-20, Henning Thielemann [EMAIL PROTECTED] wrote:
On Mon, 20 Sep 2004, Einar Karttunen wrote:
Size
Handling large amounts of text as haskell strings is currently not
possible as the representation (list of chars) is very inefficient.
Efficiency is
Can this not be handled in a nicer way by the compiler? What if the
compiler tried to allocate the lists in chunks? For example when dealing
with strings, why cant the compiler allocate the string as a fixed length
unit, terminated with a link to the next unit. (IE allow the atoms in the
list to
Hello,
As I'm investigating Haskell, it's occured to me that most of the
Haskell tutorials out there have omitted something that was quite
prominent in the OCaml material I had read: making functions properly
tail-recursive.
The OCaml compiler was able to optimize tail-recursive functions such
John Goerzen [EMAIL PROTECTED] writes:
The OCaml compiler was able to optimize tail-recursive functions such
that they could be compiled using a loop. This would achieve two main
benefits: performance due to not needing to allocate/deallocate stack
frames, and the ability to work on very
hello,
John Goerzen wrote:
Hello,
As I'm investigating Haskell, it's occured to me that most of the
Haskell tutorials out there have omitted something that was quite
prominent in the OCaml material I had read: making functions properly
tail-recursive.
The OCaml compiler was able to optimize
On Tuesday 28 September 2004 01:54 am, Iavor S. Diatchki wrote:
OTOH there are a few classical cases in haskell where you run out of
space even if you have a tail
recursive function: e.g.
sum n [] = n
sum n (y:ys) = sum (n + y) ys
the reason for this that the n+y expression never gets
Hi,
I am also looking for this kind of information in general, however I have done some
investigations that answer some of you questions. I posted a question on this kind of
optimisation recently [1], but it kept unanswered.
On Tue, 28 Sep 2004 18:10:11 + (UTC), John Goerzen [EMAIL
John Goerzen [EMAIL PROTECTED] writes:
If I instead wrote:
sum [] = 0
sum (x:xs) = x + sum(xs)
then I have the same problem.
What is the proper way to solve this little problem then?
sum n [] = n
sum n (x:xs) = (sum $! n + x) xs
It's unfortunate that it requires $! or seq, but it's
I'm trying to write a program that will copy an arbitrarily large text
file to a destination, and duplicate it 100 times.
Thus:
./myprog Input Output
would be the same as running:
cat Input Output# once
cat Input Output # 99 times
My first attempt was this:
import IO
main = disp
On Tuesday 28 Sep 2004 8:17 pm, John Goerzen wrote:
On Tuesday 28 September 2004 01:54 am, Iavor S. Diatchki wrote:
OTOH there are a few classical cases in haskell where you run out of
space even if you have a tail
recursive function: e.g.
sum n [] = n
sum n (y:ys) = sum (n + y) ys
John Goerzen writes:
That failed, though, because getContents closes the file
after it's been completely read (ugh -- why?).
getContents reads from standard input: you can't seek on
that stream. Just think of cat file | cat. The second
invocation reads from a pipe, not from a file on disk.
On 2004-09-28, Peter Simons [EMAIL PROTECTED] wrote:
John Goerzen writes:
That failed, though, because getContents closes the file
after it's been completely read (ugh -- why?).
You could read the contents once, write it to a temporary
file, and then copy it multiple times from there.
On 2004-09-28 at 21:19- John Goerzen wrote:
On 2004-09-28, Peter Simons [EMAIL PROTECTED] wrote:
John Goerzen writes:
FWIW, this is working for me:
import IO
main = disp 100
disp 0 = return ()
disp n =
let copy x = do
eof - isEOF
if eof
1. Do Haskell interpreters/compilers perform [tail call optimization]?
Georg Martius wrote:
ghc does it with one of -O -O1 -O2 switches.
hugs doesn't seam to do it since [2] says that
foldl (\n _ - n + 1) 0 [1..10]
causes a stack overflow.
All Haskell compilers (including Hugs)
Thanks to a lot of help from Gregory Wright, it is now possible to
install ghc 6.2.1 on Tiger - it takes quite a bit of fiddling before
it will work, but there is a way. The package available at
Haskell.org will not work, however the darwin ports version will given
that gcc 3.1 is installed on
On Tuesday 28 September 2004 22:19, John Goerzen wrote:
[program that calls isEOF once per line deleted]
but it seems wasteful to poll isEOF so much.
I think all Haskell implementations have a buffering layer between the Haskell
level and the operating system. So, calls to hGetLine, hIsEOF,
On 2004-09-28, Alastair Reid [EMAIL PROTECTED] wrote:
On Tuesday 28 September 2004 22:19, John Goerzen wrote:
That said, if you want to write a cat-like program which is as fast as Unix
cat, you should not process data a character at a time or a line at a time
but, rather, read fixed size
John Goerzen writes:
One of the things I do when I learn a new language is to try to probe
where its weaknesses are.
Please, when meeting new women in your life, don't do so.
Otherwise you won't live long enough in order to appreciate
your new knowledge...
Jerzy Karczmarczuk
Hi.
floorRootDef, floorRoot :: Integer - Integer - Integer
floorRootDef k n | k=1 n=1 = last (takeWhile (\x-x^k=n) [1..])
floorRoot k n | k=1 n=1 = h n where
h x = let y=((k-1)*x+n`div`x^(k-1))`div`k in if yx then h y else x
(Oddly enough, you get an iteration formula for the _floor_
G'day all.
Quoting John Goerzen [EMAIL PROTECTED]:
* (++) is both a list and a string concatenation operator
This could easily be handle by a typeclass.
* Pattern matching works well with strings (that's my #1 gripe about
strings in OCaml)
* Thanks to the laziness of Haskell lists,
26 matches
Mail list logo
