apfelmus quantentunnel.de> writes:
>
> Dave Bayer wrote:
> > What I'm calling a "venturi"
> >
> >venturi :: Ord a => [[a]] -> [a]
> >
> > merges an infinite list of infinite lists into one list, under the
> > assumption that each list, and the heads of the lists, are in
> > increasing order
Hello,
On Wednesday 25 July 2007 01:42, Thorkil Naur wrote:
> Hello Melissa,
>
> On Tuesday 24 July 2007 19:09, Melissa O'Neill wrote:
> > ...
> > (See ONeillPrimes.hs in http://www.cs.hmc.edu/~oneill/code/haskell-
> > primes.zip for the complete code. I've also added Thorkil Naur's
> > code
Hello Melissa,
On Tuesday 24 July 2007 19:09, Melissa O'Neill wrote:
> apfelmus wrote:
> > After some pondering, the List a data structure for merging is
> > really
> > ingenious! :) Here's a try to explain how it works:
>
> Thanks apfelmus! A detailed explanation of this code is really
>
apfelmus wrote:
After some pondering, the List a data structure for merging is
really
ingenious! :) Here's a try to explain how it works:
Thanks apfelmus! A detailed explanation of this code is really
helpful for anyone trying to understand what is going on. The VIP/
Crowd analogy is a
Dave Bayer wrote:
> What I'm calling a "venturi"
>
>venturi :: Ord a => [[a]] -> [a]
>
> merges an infinite list of infinite lists into one list, under the
> assumption that each list, and the heads of the lists, are in
> increasing order.
>
> I wrote this as an experiment in coding data struct
Neil Mitchell wrote:
-O3 is slower than -O2 and -O in ghc? If you want "fast code" then
specify -O2, not -O3.
Oops. That ought to have been -O2.
But from what I can tell, -O3 is harmless (at least in this case).
Both invocations generate identical executables, at least for these
example
Hi
But for the current version of my code, there is still a bit of a
performance gap between our two methods. Here are the stats I get
(ghc -O3, 2.4GHz x86):
Are you aware that -O3 is slower than -O2 and -O in ghc? If you want
"fast code" then specify -O2, not -O3.
Thanks
Neil
_
Dave Bayer wrote:
Here is another prime sieve.
It's great to know people are still having fun with this stuff...
I've added your implementation to the zipfile available at
http://www.cs.hmc.edu/~oneill/code/haskell-primes.zip
(FWIW, I added specializations for Int and Integer and also
It appears that at least on gmane, my posts to this thread ended up as
singletons, breaking the thread. Here are the posts:
http://article.gmane.org/gmane.comp.lang.haskell.cafe/26426
http://article.gmane.org/gmane.comp.lang.haskell.cafe/26466
___
Hask
As an exercise, trying to understand the beautiful paper
Stream Fusion
From Lists to Streams to Nothing at All
Duncan Coutts, Roman Leshchinskiy and Don Stewart
http://www.cse.unsw.edu.au/~dons/papers/CLS07.html
http://www.cse.unsw.edu.au/~dons/streams.html
Here is another prime sieve. It is about half the length of the
fastest contributed code (ONeillPrimes) and nearly as fast until it
blows up on garbage collection:
% cat ONeillPrimes.hs | grep -v "^--" | wc
18511056306
% cat BayerPrimes.hs | grep -v "^--" | wc
85 566
G'day all.
This one is pretty elegant. A Pritchard sieve is actually an
Eratosthenes sieve with the loops reversed. Unfortunately, it's
a bit slower. Maybe someone else can speed it up a bit.
mergeRemove :: [Integer] -> [Integer] -> [Integer]
mergeRemove [] ys = []
mergeRemove xs [] = xs
merge
Here's another program you can add. It's fairly short and efficient.
-- Lennart
import System (getArgs)
infixr :>
data StreamInt = !Int :> StreamInt
(!>) :: StreamInt -> Int -> Int
(x :> _) !> 0 = x
(_ :> xs) !> n = xs !> (n-1)
-- By replacing lprimes on the next line by '5 :> gen
For those enjoying the fun with prime finding, I've updated the
source at
http://www.cs.hmc.edu/~oneill/code/haskell-primes.zip
I've tweaked my code a little to improve its space behavior when
finding primes up to some limit, added an up-to-limit version of the
Naive Primes algorithm,
OK.
Another weird thing is that much of the Haskell code seems to work
with Integer whereas the C code uses int. That doesn't seem fair.
-- Lennart
On Feb 25, 2007, at 02:40 , Melissa O'Neill wrote:
Someone asked if I'd include a "classic C" version of the Sieve in
my comparisons
oneill:
> Someone asked if I'd include a "classic C" version of the Sieve in my
> comparisons. Having done so, Lennart wrote (slightly rephrased):
> >How did you compare the C version with the Haskell versions? The
> >Haskell programs produce the Nth prime, whereas the C code produces
> >the
Someone asked if I'd include a "classic C" version of the Sieve in my
comparisons. Having done so, Lennart wrote (slightly rephrased):
How did you compare the C version with the Haskell versions? The
Haskell programs produce the Nth prime, whereas the C code produces
the last prime less than
How did you compare the C version with the Haskell versions?
The Haskell programs produce the Nth prime, whereas the C code
produces the last prime less than N.
To make the C code to what the Haskell code does you need to set some
upper bound that is related to the prime number distribution. I se
G'day all.
Quoting Melissa O'Neill <[EMAIL PROTECTED]>:
> Cool, thanks. When I ran your code trying to find the 10,000th
> prime, I got
>AtkinSieveTest: Ix{Integer}.index: Index (36213) out of range
> ((0,36212))
> but that went away when I made your array one bigger.
Fixed, thanks.
Cheers
Bulat Ziganshin asked:
but how it looks compared with classic C implementation of sieve
algorithm?
It's still worse. I Googled for a "typical" implementation and added
it to the collection. The best Haskell implementation is still about
two orders of magnitude slower, but remember that t
20 matches
Mail list logo
