I have to agree that reading and maintaining regular expressions can be
challenging :)
On Wed, Feb 13, 2013 at 9:50 PM, Erik de Castro Lopo
mle...@mega-nerd.comwrote:
wren ng thornton wrote:
Regexes are powerful and concise for recognizing regular languages. They
are not, however, very
Just to play devil's advocate:
100% agreed that there are better things to do in Haskell _source code_ than
regexps.
The thing about regexps is that they can be accepted at run time as _data_.
This means, for example, that they can be put in whatever you use for
localisation.
See for
On 2/13/13 11:18 PM, wren ng thornton wrote:
On 2/13/13 11:32 AM, Nicolas Bock wrote:
Since I have very little experience with Haskell and am not used to
Haskell-think yet, I don't quite understand your statement that
regexes are
seen as foreign to Haskell-think. Could you elaborate? What would
(I'll be brief because my head is hurting, but please don't interpret that
as an intent to offend)
A few points:
1) Capture groups are all you need to do some meaningful interpretation of
data; these were around long before perl.
2) Yacc is typically used in conjunction with lex, partly for (a)
It's worth remembering that the main gain from lex/yacc had originally to do
with making the generated programs fit into 64K address space on a PDP11 more
than with any direct performance efficiency.
--
brandon s allbery kf8nh
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
On
replacing it.
Date: Tue, 12 Feb 2013 20:32:01 -0800
From: bri...@aracnet.com
To: nicolasb...@gmail.com
CC: bm...@hotmail.com; b...@redivi.com; haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] performance question
On Tue, 12 Feb 2013 15:57:37 -0700
Nicolas Bock nicolasb...@gmail.com wrote
On Tue, Feb 12, 2013 at 11:32 PM, bri...@aracnet.com wrote:
actualy native code compiler. Can't regex be done effectively in haskell
? Is it something that can't be done, or is it just such minimal effort to
link to pcre that it's not worth the trouble ?
PCRE is pretty heavily optimized.
Since I have very little experience with Haskell and am not used to
Haskell-think yet, I don't quite understand your statement that regexes are
seen as foreign to Haskell-think. Could you elaborate? What would a more
native solution look like? From what I have learned so far, it seems to
me that
One way in which regexps are foreign to Haskell-think is that, if they
break, they generally break at run-time. This could be ameliorated with
template haskell, but a substantial portion of Haskell coders find that a
smell itself.
On Wed, Feb 13, 2013 at 8:32 AM, Nicolas Bock
On Wed, 2013-02-13 at 08:39 -0800, David Thomas wrote:
One way in which regexps are foreign to Haskell-think is that, if
they
break, they generally break at run-time. This could be ameliorated
with
template haskell
Care to elaborate on the ameliorate using TH part? I figure regexes
would be
Well, this runtime errors are actually type errors. Regexps are actually a DSL,
which is not embedded in Haskell. But it could be. Strings won't work for that,
but something like that would:
filter (match $ a many anyChar .txt) filenames
and this certainly can be produced by TH like that:
On Wed, Feb 13, 2013 at 11:32 AM, Nicolas Bock nicolasb...@gmail.comwrote:
Since I have very little experience with Haskell and am not used to
Haskell-think yet, I don't quite understand your statement that regexes are
seen as foreign to Haskell-think. Could you elaborate? What would a more
I don't think you can do much about fails to match the input string -
indeed, that's often desired behavior... and matches the wrong thing you
can only catch with testing.
The simplest place template haskell could help with is when the expression
isn't a valid expression in the first place, and
The fact that parsec and attoparsec exist and can be pressed into service
with reasonable performance (I think?) on tasks for which regexps are
suitable is probably another big part of the reason no one's done it yet.
I expect much of the plumbing would wind up looking a lot like those,
actually.
On Wed, Feb 13, 2013 at 12:46 PM, David Thomas davidleotho...@gmail.comwrote:
The fact that parsec and attoparsec exist and can be pressed into service
with reasonable performance (I think?) on tasks for which regexps are
suitable is probably another big part of the reason no one's done it
On 10.02.2013 02:30, Nicolas Bock wrote:
Hi Aleksey,
could you show me how I would use ByteString? I can't get the script to
compile. It's complaining that:
No instance for (RegexContext
Regex Data.ByteString.ByteString
(AllTextSubmatches [] a0))
which is too cryptic
On 13.02.2013 21:41, Brandon Allbery wrote:
On Wed, Feb 13, 2013 at 11:32 AM, Nicolas Bock nicolasb...@gmail.com
mailto:nicolasb...@gmail.com wrote:
Since I have very little experience with Haskell and am not used to
Haskell-think yet, I don't quite understand your statement that
On 13.02.2013 21:41, Brandon Allbery wrote:
The native solution is a parser like parsec/attoparsec.
Aleksey Khudyakov alexey.sklad...@gmail.com replied
Regexps only have this problem if they are compiled from string. Nothing
prevents from building them using combinators. regex-applicative[1]
On Wed, Feb 13, 2013 at 5:45 PM, o...@cs.otago.ac.nz wrote:
On 13.02.2013 21:41, Brandon Allbery wrote:
The native solution is a parser like parsec/attoparsec.
Aleksey Khudyakov alexey.sklad...@gmail.com replied
Regexps only have this problem if they are compiled from string. Nothing
On 2/13/13 11:32 AM, Nicolas Bock wrote:
Since I have very little experience with Haskell and am not used to
Haskell-think yet, I don't quite understand your statement that regexes are
seen as foreign to Haskell-think. Could you elaborate? What would a more
native solution look like? From what I
wren ng thornton wrote:
Regexes are powerful and concise for recognizing regular languages. They
are not, however, very good for *parsing* regular languages; nor can
they handle non-regular languages (unless you're relying on the badness
of pcre). In other languages people press regexes
To: haskell-cafe@haskell.org
Subject: [Haskell-cafe] performance question
Hi list,
I wrote a script that reads matrix elements from standard input, parses
the input using a regular expression, and then bins the matrix elements by
magnitude. I wrote the same script in python (just to be sure
@haskell.org
Subject: [Haskell-cafe] performance question
Hi list,
I wrote a script that reads matrix elements from standard input, parses
the input using a regular expression, and then bins the matrix elements by
magnitude. I wrote the same script in python (just to be sure :) ) and find
)
--
From: nicolasb...@gmail.com javascript:;
Date: Fri, 8 Feb 2013 12:26:09 -0700
To: haskell-cafe@haskell.org javascript:;
Subject: [Haskell-cafe] performance question
Hi list,
I wrote a script that reads matrix elements from standard input, parses
the input
On Fri, Feb 8, 2013 at 1:23 PM, Aleksey Khudyakov alexey.sklad...@gmail.com
wrote:
On 08.02.2013 23:26, Nicolas Bock wrote:
Hi list,
I wrote a script that reads matrix elements from standard input, parses
the input using a regular expression, and then bins the matrix elements
by
On Fri, Feb 8, 2013 at 1:23 PM, Aleksey Khudyakov alexey.sklad...@gmail.com
wrote:
On 08.02.2013 23:26, Nicolas Bock wrote:
Hi list,
I wrote a script that reads matrix elements from standard input, parses
the input using a regular expression, and then bins the matrix elements
by
I've been playing with your example to optimize it a bit, I have to run but
here's what I have so far. It's about as fast as the Python code, I'll make
it faster when I have more time over the next few days.
See https://gist.github.com/etrepum/4747507 and
: [Haskell-cafe] performance question
Hi list,
I wrote a script that reads matrix elements from standard input, parses the
input using a regular expression, and then bins the matrix elements by
magnitude. I wrote the same script in python (just to be sure :) ) and find
that the python version
Hi list,
I wrote a script that reads matrix elements from standard input, parses the
input using a regular expression, and then bins the matrix elements by
magnitude. I wrote the same script in python (just to be sure :) ) and find
that the python version vastly outperforms the Haskell script.
On 08.02.2013 23:26, Nicolas Bock wrote:
Hi list,
I wrote a script that reads matrix elements from standard input, parses
the input using a regular expression, and then bins the matrix elements
by magnitude. I wrote the same script in python (just to be sure :) )
and find that the python
Do you mind posting createMatrixDump.py and printMatrixDecay.py? That would
certainly make it easier to help you.
On Fri, Feb 8, 2013 at 11:26 AM, Nicolas Bock nicolasb...@gmail.com wrote:
Hi list,
I wrote a script that reads matrix elements from standard input, parses
the input using a
Sorry, should have done this right away. Here are the other two scripts.
On Fri, Feb 8, 2013 at 1:45 PM, Bob Ippolito b...@redivi.com wrote:
Do you mind posting createMatrixDump.py and printMatrixDecay.py? That
would certainly make it easier to help you.
On Fri, Feb 8, 2013 at 11:26 AM,
On Fri, Feb 8, 2013 at 1:23 PM, Aleksey Khudyakov alexey.sklad...@gmail.com
wrote:
On 08.02.2013 23:26, Nicolas Bock wrote:
Hi list,
I wrote a script that reads matrix elements from standard input, parses
the input using a regular expression, and then bins the matrix elements
by
On 09.02.2013 01:02, Nicolas Bock wrote:
Yes, a histogram. The binning code is really a little awkward. I haven't
gotten used to thinking in terms of inmutable objects yet and this list
appending is really a pretty bad hack to kind of allow me to increment
the bin counts. How would one do this
(strataCounts[i])/N), total); }}
From: nicolasb...@gmail.com
Date: Fri, 8 Feb 2013 12:26:09 -0700
To: haskell-cafe@haskell.org
Subject: [Haskell-cafe] performance question
Hi list,
I wrote a script that reads matrix elements from standard input, parses the
input using a regular expression, and then bins
A lte reply, but if you still need to have circular module depency: 4.6.9.
How to compile mutually recursive modules in
http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation.html
On 21 March 2010 01:31, Arnoldo Muller arnoldomul...@gmail.com wrote:
Hello Daniel,
Hello Daniel,
Regarding your solution, can I apply {-# SPECIALISE ... #-} statements to
datatypes I define?
And if so, I am not able to import the datatypes to the module where
binarySearch is.
The problem is that if I import them a circular dependency is detected and
the compiler gives an error.
Hello!
I am trying to implement a binary search function that returns the index of
an
exact or the (index + 1) where the item should be inserted in an array if
the item to be searched is not found (I am not trying to insert data in the
array) .
Right now, the bottleneck of my program is in
Am Donnerstag 18 März 2010 19:59:33 schrieb Arnoldo Muller:
Hello!
I am trying to implement a binary search function that returns the index
of an
exact or the (index + 1) where the item should be inserted in an array
if the item to be searched is not found (I am not trying to insert data
in
Am Donnerstag 18 März 2010 20:49:30 schrieb Daniel Fischer:
Am Donnerstag 18 März 2010 19:59:33 schrieb Arnoldo Muller:
Hello!
I am trying to implement a binary search function that returns the
index of an
exact or the (index + 1) where the item should be inserted in an array
if the
Daniel Fischer wrote:
If it's called often, and the arrays are 0-based and Int-indexed,
import Data.Array.Base (unsafeAt)
and replacing ! with `unsafeAt` should give a speed-up, though probably not
terribly much. If you don't need the polymorphism and your array elements
are unboxable, using
Am Donnerstag 18 März 2010 21:57:34 schrieb Daniel Fischer:
Contrary to my expectations, however, using unboxed arrays is slower
than straight arrays (in my tests).
However, a few {-# SPECIALISE #-} pragmas set the record straight.
Specialising speeds up both, boxed and unboxed arrays,
On 19/03/2010, at 08:48, Daniel Fischer wrote:
Am Donnerstag 18 März 2010 21:57:34 schrieb Daniel Fischer:
Contrary to my expectations, however, using unboxed arrays is slower
than straight arrays (in my tests).
However, a few {-# SPECIALISE #-} pragmas set the record straight.
This is
Right now, the bottleneck of my program is in binarySearch', the function
must be called a few billion times.
Do you have any ideas on how to improve the performance of this function?
Bast solution for speeding up is to write it in assembler!
Ragards, Andrey
--
View this message in context:
On 2009 Feb 27, at 1:50, Ketil Malde wrote:
Lennart Augustsson lenn...@augustsson.net writes:
C's rand() function is very bad and should never be used really.
On Linux (really GNU libc, I suppose) it is the same as random(). But
for portability, one is encouraged to spend the two extra
The random() function is only marginally better than rand().
On Fri, Feb 27, 2009 at 6:50 AM, Ketil Malde ke...@malde.org wrote:
Lennart Augustsson lenn...@augustsson.net writes:
C's rand() function is very bad and should never be used really.
On Linux (really GNU libc, I suppose) it is the
Hi,
i have compared a C++ implementation with a Haskell implementation of the Monte
Carlo Pi approximation:
http://lennart.kudling.de/haskellPi/
The Haskell version is 100 times slower and i wonder whether i do something
obvious wrong.
Profiling says that the majority of the time is spend in
First thing I noticed, how about removing the sqrt in isInCircle:
isInCircle :: (Floating a, Ord a) = (a,a) - Bool
isInCircle (x,y) = x*x + y*y = 1.0
But you can remove sqrt from the C++ implementation as well, so it only
improves the relative performance if the C++ implementation of sqrt is
But you can remove sqrt from the C++ implementation as well, so it only
improves the relative performance if the C++ implementation of sqrt is
worse than its Haskell counterpart.
Oops, of course I mean, you only improve if Haskell's implementation is
worse than C++'s implementation :)
But you can remove sqrt from the C++ implementation as well, so it only
improves the relative performance if the C++ implementation of sqrt is
worse than its Haskell counterpart.
Oops, of course I mean, you only improve if Haskell's implementation is
worse than C++'s implementation :)
Yep, this program will crawl.
You can get reasonable numeric performance out of GHC, but you need to
work at it. There is some advice in the GHC manual at http://www.haskell.org/ghc/docs/latest/html/users_guide/faster.html
.
The first thing I would do is replace your
isInCircle ::
hask...@kudling.de writes:
Profiling says that the majority of the time is spend in main. But i have
no idea where.
Can someone give me a hint?
Yes. Lots of them, but somehow, I suspect nobody tried your code.
COST CENTRE MODULE
Hi,
thanks for your input.
You can get reasonable numeric performance out of GHC, but you need to
work at it. There is some advice in the GHC manual at
http://www.haskell.org/ghc/docs/latest/html/users_guide/faster.html
I am using -O2 and strictness already.
Currently i can only imagine to
On 26/02/2009, at 9:27 PM, hask...@kudling.de wrote:
Currently i can only imagine to define a data type in order to use
unboxed Ints instead of the accumulator tuple.
That would probably help a lot. It would also help to use two separate
Double# parameters instead of the tuple.
The
Ben Lippmeier wrote:
The first thing I would do is replace your isInCircle :: (Floating
a, Ord a) = (a,a) - Bool with isInCircle :: (Double, Double) -
Bool
Can you point me to why that matters?
At the machine level, GHC treats the (Floating a, Ord a) as an extra
argument to the
Here is a variant that uses mersenne-random-pure64 and works less than
2x slower than C++:
- You don't need to compute samples count an extra time
- You don't need to assemble double pairs from a list
- Notice the strictness in randomDoublePairs: it doubled performance
{-# LANGUAGE
I replaced the standard random number generated with the one from
mersenne-random. On my system this makes the resulting program about
14 times faster than the original. I also made a change to
accumulateHit because it doesn't need to count to total. That is
already known.
{-# LANGUAGE
accumulateHit because it doesn't need to count to total. That is
already known.
Well in theory i agree. But somone could feed a non-infite number of doubles.
Then the argument n would not necessarily be the same as the number of random
number pairs really used.
Do you think it would be feasable to replace the GHC implementation of
System.Random with something like System.Random.Mersenne?
Here is a variant that uses mersenne-random-pure64 and works less than
2x slower than C++:
- You don't need to compute samples count an extra time
- You don't need
I, personally, do, but I think that's more of a question to the GHC people :)
2009/2/26 hask...@kudling.de:
Do you think it would be feasable to replace the GHC implementation of
System.Random with something like System.Random.Mersenne?
Here is a variant that uses mersenne-random-pure64 and
On Thu, Feb 26, 2009 at 7:56 AM, Eugene Kirpichov ekirpic...@gmail.com wrote:
Here is a variant that uses mersenne-random-pure64 and works less than
2x slower than C++:
And I would like to notice that rand() is incredibly dumber than the
Mersenne twister, so probably if we took rand()'s code
C's rand() function is very bad and should never be used really.
On Thu, Feb 26, 2009 at 11:37 AM, Felipe Lessa felipe.le...@gmail.com wrote:
On Thu, Feb 26, 2009 at 7:56 AM, Eugene Kirpichov ekirpic...@gmail.com
wrote:
Here is a variant that uses mersenne-random-pure64 and works less than
hask...@kudling.de wrote:
Do you think it would be feasable to replace the GHC implementation
of System.Random with something like System.Random.Mersenne?
There's a problem with using the Mersenne Twister: System.Random's
interface has a split method:
class RandomGen g where
split:: g -
You can implement a reasonable split if you can fast-forward the generator.
There's no known method to fast-forward the MT, but other generators
like MRG32k3a can handle it.
-- Lennart
On Thu, Feb 26, 2009 at 12:08 PM, Bertram Felgenhauer
bertram.felgenha...@googlemail.com wrote:
On Thu, Feb 26, 2009 at 7:17 AM, Lennart Augustsson
lenn...@augustsson.netwrote:
You can implement a reasonable split if you can fast-forward the generator.
There's no known method to fast-forward the MT, but other generators
like MRG32k3a can handle it.
Are you aware of any existing
2009/2/26 Tracy Wadleigh tracy.wadle...@gmail.com:
On Thu, Feb 26, 2009 at 7:17 AM, Lennart Augustsson lenn...@augustsson.net
wrote:
You can implement a reasonable split if you can fast-forward the
generator.
There's no known method to fast-forward the MT, but other generators
like MRG32k3a
Awesome, Felipe. Thanks.
--Tracy
On Thu, Feb 26, 2009 at 11:07 AM, Felipe Lessa felipe.le...@gmail.comwrote:
2009/2/26 Tracy Wadleigh tracy.wadle...@gmail.com:
On Thu, Feb 26, 2009 at 7:17 AM, Lennart Augustsson
lenn...@augustsson.net
wrote:
You can implement a reasonable split if
Ben.Lippmeier:
On 26/02/2009, at 9:27 PM, hask...@kudling.de wrote:
Currently i can only imagine to define a data type in order to use
unboxed Ints instead of the accumulator tuple.
That would probably help a lot. It would also help to use two separate
Double# parameters instead of the
I looked at the core and the tuples were already unboxed IIRC.
2009/2/26 Don Stewart d...@galois.com:
Ben.Lippmeier:
On 26/02/2009, at 9:27 PM, hask...@kudling.de wrote:
Currently i can only imagine to define a data type in order to use
unboxed Ints instead of the accumulator tuple.
That
vandijk.roel:
I replaced the standard random number generated with the one from
mersenne-random. On my system this makes the resulting program about
14 times faster than the original. I also made a change to
accumulateHit because it doesn't need to count to total. That is
already known.
How about an FFI call to rand() and then measure the performance
On Thu, Feb 26, 2009 at 3:37 AM, Felipe Lessa felipe.le...@gmail.comwrote:
On Thu, Feb 26, 2009 at 7:56 AM, Eugene Kirpichov ekirpic...@gmail.com
wrote:
Here is a variant that uses mersenne-random-pure64 and works less than
On Thu, Feb 26, 2009 at 6:23 PM, Don Stewart d...@galois.com wrote:
But note the lazy list of Double pairs, so the inner loop still looks like
this though:
$wlgo :: Int# - [(Double, Double)] - Int
$wlgo =
\ (ww_s1pv :: Int#)
(w_s1px :: [(Double, Double)]) -
case
Lennart Augustsson lenn...@augustsson.net writes:
C's rand() function is very bad and should never be used really.
On Linux (really GNU libc, I suppose) it is the same as random(). But
for portability, one is encouraged to spend the two extra letters. I
don't understand the details, but I
On Mon, Jan 17, 2005 at 08:54:38PM -0800, Ben Rudiak-Gould wrote:
If performance is the main concern, I would flatten the data structure:
data Interval = IlII Double Double
| IlIE Double Double
| IlEI Double Double
| IlEE Double Double
Hello all,
A question on that most elusive of subjects performance in haskell (GHC 6.2)
Using the GHC profiler, I obtained the following analysis results (i
hope the code doesn't come out too ugly by mail):
total time =0.92 secs (46 ticks @ 20 ms)
total alloc =
Stijn De Saeger wrote:
data Bound = I Double | E Double deriving (Eq, Show, Ord)
data Interval = Il Bound Bound | Nil Bound Bound deriving (Eq,Ord)
isIn :: Double - Interval - Bool
isIn r (Nil x y) = not (isIn r (Il x y))
isIn r (Il (I x) (I y)) = r = x r = y
isIn r (Il (I x) (E y)) = r = x
76 matches
Mail list logo
