John Lato wrote:
I'm working
with moderate-sized files (tens to hundreds of MBs) that have some
ascii header data followed by a bunch of 32-bit ints.
but I don't know if [Int32] is actually the best choice. It seems to me
that something like a lazy list of strict arrays (analogous to a lazy
I would love to have the ability to define binary operator modifiers.
For example:
f \overline{op} g = liftM2 op f g
f \overleftarrow{op} n = liftM2 op f (return n)
n \overrightarrow{op} g = liftM2 op (return n) f
\widehat{f} x = liftM f x
so that for example you could
On Oct 29, 2007, at 3:36 , Tim Newsham wrote:
or go through the trouble of defining a bunch of binops
f + g = liftM2 (+) f g
n + g = return n + g
f + n = f + return n
read' = liftM read
This looks a lot like Control.Applicative to me.
--
brandon s. allbery
Derek Elkins wrote:
Try with rem instead of mod.
(What the heck is with bottom?)
The bottom was there by error and I was lazy to redo
the tests so I rather posted exactly what I was
doing. I do not know the compiler that good to be
absolutely sure it cannot have impact on result
... so I
Don Stewart wrote:
perfect :: [Int]
perfect = [i | i-[1..1], i == sum (divisors i)]
This should be a little faster , as sum will fuse,
perfect :: [Int]
perfect = [i | i-[1..1], i == sum' (divisors i)]
where sum' = foldr (+) 0
sum' did not help. Times are about the
Hello Tim,
Monday, October 29, 2007, 10:36:18 AM, you wrote:
or go through the trouble of defining a bunch of binops
Is there any way in Haskell to modify binops in this way and still
be able to use them infix?
Template Haskell looks like an perfect tool for implementing this
--
Best
rem is faster because it has slightly different behaviour to mod, and
there happens to be an intel instruction that maps more directly to
rem than to mod, thus making it much faster on intel processors.
Why do you expose perfect and divisors? Maybe if you just expose main,
perfect and divisors
On 10/28/07, Isaac Dupree [EMAIL PROTECTED] wrote:
Josef Svenningsson wrote:
Less bogus timing:
avg4: 18.0s
avgS: 2.2s
avgP: 17.4s
OK, so these figures make an even stronger case for my conclusion :-)
Single traversal can be much faster than multiple traversals *when
done right*.
Rodrigo Queiro wrote:
Why do you expose perfect and divisors? Maybe if you just expose main,
perfect and divisors will be inlined (although this will only save
10,000 function entries, so will probably have negligible effect).
I exposed them so that I can check types in ghci.
Hiding them does
On 10/29/07, Josef Svenningsson [EMAIL PROTECTED] wrote:
But using those flags yielded a very interesting result:
avgP: 4.3s
Superlinear speedup!? As you say, I would have expected something
slightly larger than 9s. I think what happens here is that for avg4
the entire list has to be kept
Hello Josef,
Monday, October 29, 2007, 2:08:54 PM, you wrote:
that can maybe account for the additional time savings. I'm not sure
how to verify that this is the case though.
Bulat kindly suggested I use +RTS -s to monitor the garbage collectors
behavior. It seems my hypothesis was right.
One factor that is slightly unusual about this
phenomenon is that it only occurs with GHC, but not
with Hugs 98. Typing
:cd D:\From C Drive\Documents and
Settings\DekuDekuplex\Programming
Practice\Haskell\GHC
in Hugs 98 does not cause an error, but typing the
same command in GHC does. It
Ryan Dickie wrote:
One thing I've noticed is that turning on optimizations significantly
increases the speed of haskell code. Are you comparing code between
languages with -O2 or without opts?
I had done no optimization, but neither -O nor -O2 make a significant
difference in either the C or
Hello all,
just to compare the stuff, I get quite other results being on other
OS. Thus, the result of C++ compiler may not be that interesting as I do
not have the one presented below.
My machine:
Linux 2.6.23-ARCH #1 SMP PREEMPT Mon Oct 22 12:50:26 CEST 2007 x86_64
Intel(R) Core(TM)2 CPU
Peter Hercek wrote:
Daniel Fischer wrote:
What perpetually puzzles me is that in C long long int has very good
performance, *much* faster than gmp, in Haskell, on my computer, Int64
is hardly faster than Integer.
I tried the example with Int64 and Integer. The integer version
was actually
Am Montag, 29. Oktober 2007 13:49 schrieb Dusan Kolar:
Hello all,
just to compare the stuff, I get quite other results being on other
OS. Thus, the result of C++ compiler may not be that interesting as I do
not have the one presented below.
Just to chime in, my results with the code below:
I would love an answer to this as well.
Isaac Dupree [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
10/27/2007 06:48 PM
To
Haskell-cafe haskell-cafe@haskell.org
cc
Subject
[Haskell-cafe] viewing HS files in Firefox
When I try to go to one of the Module.hs files, e.g. on
OK, if somebody wants to speculate (and if it even makes sense for
such a microbenchmark) here are some more data.
Except different OS and C++ compiler also processor is different.
On my side it was AMD Athlon 64 X2 4800+ (2.4GHz, 2x1MiB L2 cache
non-shared; CQ was not switched off during the
Folks,
Did quasiquotations ever make it into the GHC tree?
They were implemented as a patch to 6.7.
Thanks, Joel
--
http://wagerlabs.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
Wolfgang Jeltsch wrote:
Since the Control.Grapefruit subtree would probably only consist of
Control.Grapefruit.Signal and submodules, I’d prefer to just use
Control.Signal and Control.Signal.*. But this would pose the problem that no
other FRP library could use Control.Signal without
On Mon, Oct 29, 2007 at 04:25:45AM -0700, Benjamin L. Russell wrote:
One factor that is slightly unusual about this
phenomenon is that it only occurs with GHC, but not
with Hugs 98. Typing
:cd D:\From C Drive\Documents and
Settings\DekuDekuplex\Programming
Practice\Haskell\GHC
Are you
Hi,
Long ago (back in 2001), there was a message in the Haskell mailing
list, archived e. g. here:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg08187.html
and what it refers to is here:
http://www.cs.york.ac.uk/fp/libraries/layout.html
which goes for Graphics.UI. etc
I used this
On Mon, 29 Oct 2007, Dimitry Golubovsky wrote:
So, I'd suggest for the Grapefruit library: whatever is specific to
this library, goes under Graphics.UI.Grapefruit. Whatever may be
commonly used elsewhere (say some useful data structures) might go
under Data. So, if FRP signals are usable
In GHC it works without the and don't work with them:
Prelude :cd C:\Documents and Settings
Prelude :! pwd
C:\Documents and Settings
Olivier.
On 10/29/07, Benjamin L. Russell [EMAIL PROTECTED] wrote:
Please pardon this intrusion for an elementary
question on setting the GHC search path.
I
oops .. here is the Tim Sweeney talk
http://lambda-the-ultimate.org/node/1277 The Next Mainstream Programming
Languages If I remember correctly argues that with multicores coming that
current programming language paradigmns will not cut the mustard due to
current bad parallelism models. I guess
I didn't see anything either. But a search of the site finds one article
that mentions Haskell exactly twice (no Tom Sweeney though). An
interesting overview of the Language Wars (French translation available
as well):
The Semicolon Wars:
Every programmer knows there is one true programming
[redirecting to haskell-cafe]
On 10/29/07, Brent Yorgey [EMAIL PROTECTED] wrote:
Haskell is a wonderful language, so I hate to say this...but personally I
don't see the benefit of using Haskell here, unless the manipulations you
want to do are very complex. Some simple shell (or
On 10/29/07, Stefan O'Rear [EMAIL PROTECTED] wrote:
The OP specified that the images are around 5M in size, and need to be
rescaled, so we're talking about quite a bit of computation per shellout
(tens to hundreds of megacycles). Are context switches that slow?
I don't know. I'd have to do
On Mon, Oct 29, 2007 at 02:39:58PM -0700, Tim Chevalier wrote:
[redirecting to haskell-cafe]
On 10/29/07, Brent Yorgey [EMAIL PROTECTED] wrote:
Haskell is a wonderful language, so I hate to say this...but personally I
don't see the benefit of using Haskell here, unless the manipulations you
You're right; it works without the double-quotes.
Problem solved. Thanks!
Benjamin L. Russell
--- Olivier Boudry [EMAIL PROTECTED] wrote:
In GHC it works without the and don't work with
them:
Prelude :cd C:\Documents and Settings
Prelude :! pwd
C:\Documents and Settings
Olivier.
I needed something small for writing out png files and didn't see
anything, so I wrote my own. It's not really large or general enough yet
to warrant a full package. It wouldn't require much work to support other
variant formats, such as color.
Png.hs
{-
A small library for
31 matches
Mail list logo
