[Haskell-cafe] Cabal package bug?

hello all, I've used cabal to install package haskell-src-1.0.1.3 under ghc 6.10.1; Apparently, it worked fine! However, function parseModule has been given the type: parseModule :: String -> ParseResult haskell-src-1.0.1.3:Language.Haskell.Syntax.HsModule instead of simply parseModule :

Re: [Haskell-cafe] Status of Haskell under OsX

On Thu, Feb 26, 2009 at 2:31 AM, Manuel M T Chakravarty wrote: >> I'm planning to purchase a MacBookPro so I'm wondering how well >> Haskell is supported under this platform. > > At least two of the regular contributors to GHC work on Macs.  That should > ensure that Mac OS X is well supported.  I

Re: [Haskell-cafe] Re: Hoogle and Network.Socket

John Lato writes: > Brandon Allbery wrote: >> On 2009 Feb 21, at 20:47, Jonathan Cast wrote: >>> On Sat, 2009-02-21 at 07:25 -0700, John A. De Goes wrote: Not showing platform-specific packages by default *might* make package writers more likely to develop cross-platform packages.

Re: [Haskell-cafe] Re: base-4 + gtk2hs-0.10.0 licensing

Peter Hercek writes: >> Relinking against newer Gtk2Hs versions might not work. You have the option of recompiling the new Gtk2Hs with the old GHC and relinking, don't you? >> I want to repeat what I’ve said earlier on this list: For Haskell, >> there is no real difference between LGPL and GPL,

[Haskell-cafe] Cabal haskell-src-1.0.1.3 package bug?

[now with the name of the package on subject; appologies for multiple emails] hello all, I've used cabal to install package haskell-src-1.0.1.3 under ghc 6.10.1; Apparently, it worked fine! However, function parseModule has been given the type: parseModule :: String -> ParseResult haskel

Re: [Haskell-cafe] Data.Binary, strict reading

Hi > With binary 0.5, > >    src <- decodeFile "_make/_make" >    return $! src I'm pretty sure I was on the latest Cabal released version of binary, and the above trick did not work. It _usually_ worked, but every so often I'd get a locking error. > Shouldn't you use rnf[1]? Also, there seems

Re: [Haskell-cafe] Cabal package bug?

On Thu, 2009-02-26 at 08:00 +, jpa...@di.uminho.pt wrote: > hello all, > > I've used cabal to install package haskell-src-1.0.1.3 under ghc 6.10.1; > > Apparently, it worked fine! > > However, function parseModule has been given the type: > > parseModule :: >String >-> ParseResult h

Re: [Haskell-cafe] popularity context with Cabal

On Thu, 2009-02-26 at 00:56 -0500, Brandon S. Allbery KF8NH wrote: > On 2009 Feb 25, at 18:06, Manlio Perillo wrote: > > Debian some time ago introduced the popularity context, to find the > > most installed/used packages: > > http://popcon.debian.org/ > > > > Is it possible to do something simil

[Haskell-cafe] Performance question

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

Re: [Haskell-cafe] Performance question

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 i

Re: [Haskell-cafe] Performance question

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 :) __

Re: [Haskell-cafe] Performance question

>> 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 :)

Re: [Haskell-cafe] Performance question

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 :: (Floating

Re: [Haskell-cafe] Performance question

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

Re: [Haskell-cafe] Performance question

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 t

[Haskell-cafe] Re: Performance question

hask...@kudling.de schrieb: 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. Hi, Nice benchmark, but I

Re: [Haskell-cafe] Performance question

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 thin

[Haskell-cafe] Grapefruit infrastructure

Hello, I just want to mention that the Grapefruit FRP library now has a mailing list and a Trac instance which contains a bug tracker. See: Please also note that the Grapefruit repositories have moved to code.haskell.org. Best wish

RE: [Haskell-cafe] Performance question

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 > arg

Re: [Haskell-cafe] Re: base-4 + gtk2hs-0.10.0 licensing

Hi all, > An easy thing to do here would be to get a written statement from the > author about the interpretation with regard to what you intend to do - > like Duncan posted. AFAIK this only works when the code has a single author (or, you get a written statement from each author). In practice, ma

Re: [Haskell-cafe] Performance question

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 BangPattern

Re: [Haskell-cafe] Performance question

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 BangPattern

Re: [Haskell-cafe] Performance question

>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. __

Re: [Haskell-cafe] Performance question

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 n

Re: [Haskell-cafe] Performance question

I, personally, do, but I think that's more of a question to the GHC people :) 2009/2/26 : > 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 tha

Re: [Haskell-cafe] Performance question

On Thu, Feb 26, 2009 at 7:56 AM, Eugene Kirpichov 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 from glibc and rewrot

[Haskell-cafe] seg-fault in mersenne-random with SSE2 (was Performance question)

> From: haskell-cafe-boun...@haskell.org > [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Roel van Dijk > > 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

Re: [Haskell-cafe] memory-efficient data type for Netflix data - UArray Int Int vs UArray Int Word8

Kenneth Hoste ha scritto: Hello, I'm having a go at the Netflix Prize using Haskell. Yes, I'm brave. [...] To see if I could efficiently represent the data set in this way, I wrote a small Haskell program (attached) which uses the following data type: From what I see, to append a new integ

Re: [Haskell-cafe] Performance question

C's rand() function is very bad and should never be used really. On Thu, Feb 26, 2009 at 11:37 AM, Felipe Lessa wrote: > On Thu, Feb 26, 2009 at 7:56 AM, Eugene Kirpichov > wrote: >> Here is a variant that uses mersenne-random-pure64 and works less than >> 2x slower than C++: > > And I would li

Re: [Haskell-cafe] Performance question

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

Re: [Haskell-cafe] Performance question

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 wrote: > hask...@kudling.de wrote: >> Do you think it w

[Haskell-cafe] Re: Hoogle and Network.Socket

> John Lato writes: > >> Brandon Allbery wrote: >>> On 2009 Feb 21, at 20:47, Jonathan Cast wrote: On Sat, 2009-02-21 at 07:25 -0700, John A. De Goes wrote: > > Not showing platform-specific packages by default *might* make > package writers more likely to develop cross-platform >

Re: [Haskell-cafe] Re: base-4 + gtk2hs-0.10.0 licensing

Am Mittwoch, 25. Februar 2009 23:38 schrieb Peter Hercek: > So my opinion (IAMNAL): > 1) source code under very limiting commercial license (just to allow > recompile with a newer LGPL lib and nothing else) is OK > 2) it is probable that only the *.o, *.hi files and a linking script are > OK too I

[Haskell-cafe] Re: grapefruit Grapefruit infrastructure

I'm Switzerland on open source licenses -- I use GPL3 on everything I write, because I like the default position, but I'm always happy to relicense on request (except maybe to companies like Fluffy Bunny Killer, Inc). My sister tells me I'm a control freak, and maybe I am :-) So BSD is just great

Re: [Haskell-cafe] Re: base-4 + gtk2hs-0.10.0 licensing

Am Donnerstag, 26. Februar 2009 09:17 schrieb Ketil Malde: > Peter Hercek writes: > >> Relinking against newer Gtk2Hs versions might not work. > > You have the option of recompiling the new Gtk2Hs with the old GHC and > relinking, don't you? Relinking is technically not possible because of inlini

Re: [Haskell-cafe] Status of Haskell under OsX

I'm planning to purchase a MacBookPro so I'm wondering how well Haskell is supported under this platform. At least two of the regular contributors to GHC work on Macs. That should ensure that Mac OS X is well supported. Installation is trivial with the Mac OS X installer package: http:

Re: [Haskell-cafe] Re: Hoogle and Network.Socket

Am Donnerstag, 26. Februar 2009 13:41 schrieb John Lato: > I didn't phrase this well. In the context of my argument, "design for > cross-platform" meant "avoid platform-limiting choices in the absence > of any compelling reasons otherwise", which really isn't the same. Could we sum that up as:

Re: [Haskell-cafe] Re: base-4 + gtk2hs-0.10.0 licensing

The Mozilla Public License is superior to LGPL for this purpose: it still forces you to release any modifications, while clearly allowing bundling and commercial sales of software that includes MPL code. MPL is a good fit if you want to ensure improvements get contributed back to the comm

Re: [Haskell-cafe] Re: Hoogle and Network.Socket

Daniel provided the wisdom: > "Do not knowingly make your code unportable unless you have a good reason to" > > Are there any objections to that maxim? Thanks for bringing some sanity back. I notice very few people have bothered to comment on the wiki page Neil has setup. Incase anyone has fogot

Re: [Haskell-cafe] Re: Hoogle and Network.Socket

On Feb 25, 2009, at 7:49 PM, Achim Schneider wrote: "John A. De Goes" wrote: The problem is that PL research is probably not going to stop evolving in our lifetimes. Yes, that research needs a venue, but why should it be Haskell? Haskell is a good language and it's time to start benefiting fro

[Haskell-cafe] Incremental array updates

Hi, I seem to be a little stuck with incremental array updates... I've got an array of "few" (some thousand) integers, but have to do a calculation where I incrementally build up the array. For sake of simplicity, for now I don't use a State-Monad but simply pass the array as state down the

Re: [Haskell-cafe] Incremental array updates

You need to use STUArray. The Data.Array completely-immutable-and-boxed arrays are ok only for tasks where you build an array once and don't modify it, and where you need array elements to be lazy. The // operation creates a copy of the whole array with one element modified. It should probably be c

Re: [Haskell-cafe] Incremental array updates

On Thu, Feb 26, 2009 at 6:53 AM, Daniel Kraft wrote: > procOne (a + 1) (newarr `seq` newarr) The semantics of seq are: a `seq` b = _|_ if a = _|_, b otherwise. This implies that x `seq` x = x, and this seq is superfluous. Maybe you meant newarr `seq` procOne (a+1) newarr ? Luke __

[Haskell-cafe] Re: Incremental array updates

Eugene Kirpichov wrote: You need to use STUArray. The Data.Array completely-immutable-and-boxed arrays are ok only for tasks where you build an array once and don't modify it, and where you need array elements to be lazy. The // operation creates a copy of the whole array with one element modifie

Re: [Haskell-cafe] memory-efficient data type for Netflix data - UArray Int Int vs UArray Int Word8

On Feb 26, 2009, at 13:00 , Manlio Perillo wrote: Kenneth Hoste ha scritto: Hello, I'm having a go at the Netflix Prize using Haskell. Yes, I'm brave. [...] To see if I could efficiently represent the data set in this way, I wrote a small Haskell program (attached) which uses the following

Re: [Haskell-cafe] Incremental array updates

Am Donnerstag, 26. Februar 2009 14:53 schrieb Daniel Kraft: > Hi, > > I seem to be a little stuck with incremental array updates... I've got > an array of "few" (some thousand) integers, but have to do a calculation > where I incrementally build up the array. For sake of simplicity, for > now I d

Re: [Haskell-cafe] Incremental array updates

On Thursday 26 February 2009 15.07.34 Luke Palmer wrote: > On Thu, Feb 26, 2009 at 6:53 AM, Daniel Kraft wrote: > > procOne (a + 1) (newarr `seq` newarr) > > The semantics of seq are: a `seq` b = _|_ if a = _|_, b otherwise. This > implies that x `seq` x = x, and this seq is superfluous. >

[Haskell-cafe] Re: Incremental array updates

Daniel Fischer wrote: Am Donnerstag, 26. Februar 2009 14:53 schrieb Daniel Kraft: Hi, I seem to be a little stuck with incremental array updates... I've got an array of "few" (some thousand) integers, but have to do a calculation where I incrementally build up the array. For sake of simplicit

Re: [Haskell-cafe] Re: Hoogle and Network.Socket

On Thu, 2009-02-26 at 13:52 +0100, Daniel Fischer wrote: > Am Donnerstag, 26. Februar 2009 13:41 schrieb John Lato: > > I didn't phrase this well. In the context of my argument, "design for > > cross-platform" meant "avoid platform-limiting choices in the absence > > of any compelling reasons othe

Re: [Haskell-cafe] ANN: gitit 0.5.1

Hi all, Under gitit 0.5.3 I always get "Prelude.read: no parse" when trying to load a configuration file. My previous file goes attached, but the sample config file from http://github.com/jgm/gitit/tree/master does not work also. Has anything changed that is not documented? Thanks, hugo On Sun,

Re: [Haskell-cafe] Re: Hoogle and Network.Socket

On Thu, 2009-02-26 at 06:30 -0700, John A. De Goes wrote: > On Feb 25, 2009, at 7:49 PM, Achim Schneider wrote: > > "John A. De Goes" wrote: > > > >> The problem is that PL research is probably not going to stop > >> evolving in our lifetimes. Yes, that research needs a venue, but why > >> should

Re: [Haskell-cafe] Re: Incremental array updates

STUArray is really a bit tricky to get used with: especially, if you do something wrong, the type errors will be rather dreadful. However, if you do everything right, it's OK and you sometimes even don't need to write the types at all. There are a couple of examples here http://www.google.com/codes

[Haskell-cafe] A foray into type-level programming, and getting stuck

Okay, so I've written a small library to generalize 'fst' and 'snd' to arbitrary tuples, but I'd like to extend it a bit. I'm using the type-level library to do the thinking :) Imports and defines first: > {-# LANGUAGE UnicodeSyntax, MultiParamTypeClasses, > FunctionalDependencies, FlexibleInstan

Re: [Haskell-cafe] ANN: gitit 0.5.1

On Thu, 26 Feb 2009 14:30:17 + Hugo Pacheco wrote: > Hi all, > > Under gitit 0.5.3 I always get "Prelude.read: no parse" when trying to > load a configuration file. > My previous file goes attached, but the sample config file from > http://github.com/jgm/gitit/tree/master does not work also.

Re: [Haskell-cafe] ANN: gitit 0.5.1

Still nothing. No matter which config file I try (deleting almost every fields, newlines, etc), I always get the no parse error. On Thu, Feb 26, 2009 at 5:47 AM, Robin Green wrote: > On Thu, 26 Feb 2009 14:30:17 + > Hugo Pacheco wrote: > >> Hi all, >> >> Under gitit 0.5.3 I always get "Prelu

Re: [Haskell-cafe] ANN: gitit 0.5.1

Are you by chance using OSX? The file you attached was not a plain text file -- it was an RTF file. If you made this file on OSX and forgot to invoke the Format > Make Plain Text command, it'll be an RTF file which I'm sure gitit will have no clue about. -Ross On Feb 26, 2009, at 10:21 A

[Haskell-cafe] Strict version of Data.Map.map

Hi, Is it possible to write a strict version of Data.Map.map (so that the Map becomes strict in the elements as well as the keys)? Thanks, Edsko ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANN: gitit 0.5.1

Yes I am. I just copy/pasted the text from the server where it is plain text, so that shall not be the problem. On Thu, Feb 26, 2009 at 3:23 PM, Ross Mellgren wrote: > Are you by chance using OSX? The file you attached was not a plain text file > -- it was an RTF file. > > If you made this file o

Re: [Haskell-cafe] Strict version of Data.Map.map

I'd advise you to see Control.Parallel.Strategies, specially the NFData class and the rnf function. HTH, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Hoogle and Network.Socket

On Thu, Feb 26, 2009 at 1:21 PM, Thomas DuBuisson wrote: > Daniel provided the wisdom: >> "Do not knowingly make your code unportable unless you have a good reason to" >> >> Are there any objections to that maxim? > > Thanks for bringing some sanity back.  I notice very few people have > bothered

Re: [Haskell-cafe] Performance question

On Thu, Feb 26, 2009 at 7:17 AM, Lennart Augustsson 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 can handle it. > Are you aware of any existing (C/C++/Haskell) library im

Re: [Haskell-cafe] Performance question

2009/2/26 Tracy Wadleigh : > On Thu, Feb 26, 2009 at 7:17 AM, Lennart Augustsson > 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 can handle it. > > Are you aware o

Re: [Haskell-cafe] Performance question

Awesome, Felipe. Thanks. --Tracy On Thu, Feb 26, 2009 at 11:07 AM, Felipe Lessa wrote: > 2009/2/26 Tracy Wadleigh : > > 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 > >> gener

Re: [Haskell-cafe] Incremental array updates

On Thu, Feb 26, 2009 at 02:53:42PM +0100, Daniel Kraft wrote: > I seem to be a little stuck with incremental array updates... I've got > an array of "few" (some thousand) integers, but have to do a calculation > where I incrementally build up the array. For sake of simplicity, for > now I d

Re: [Haskell-cafe] Performance question

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 inst

[Haskell-cafe] Re: seg-fault in mersenne-random with SSE2 (was Performance question)

Alistair.Bayley: > > From: haskell-cafe-boun...@haskell.org > > [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Roel van Dijk > > > > I replaced the standard random number generated with the one from > > mersenne-random. On my system this makes the resulting program about > > 14 times fast

[Haskell-cafe] Re: Incremental array updates

Ross Paterson wrote: On Thu, Feb 26, 2009 at 02:53:42PM +0100, Daniel Kraft wrote: I seem to be a little stuck with incremental array updates... I've got an array of "few" (some thousand) integers, but have to do a calculation where I incrementally build up the array. For sake of simplicity

Re: [Haskell-cafe] Performance question

I looked at the core and the tuples were already unboxed IIRC. 2009/2/26 Don Stewart : > 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. >> >> Tha

Re: [Haskell-cafe] Re: Incremental array updates

On Thu, Feb 26, 2009 at 05:31:34PM +0100, Daniel Kraft wrote: > Well, my main problem was the lazy evaluation... No, your main problem was that you were creating 100,000 arrays, each only a little different from the one before. > For this example program... yes of course :) I'm trying to do so w

Re: [Haskell-cafe] Re: seg-fault in mersenne-random with SSE2 (was Performance question)

Might also mean bad alignment of data structures, maybe when marshalling data between the GHC runtime and the C implementation? If I recall correctly SSE2 requires 16-byte alignment. On Thu, Feb 26, 2009 at 5:24 PM, Don Stewart wrote: > Alistair.Bayley: > > > From: haskell-cafe-boun...@haskell.or

[Haskell-cafe] Performance Issue

i'm implementing a benchmark which includes a detailed specification for a random number generator. for any of the kernels outlined in the benchmark, i might have to generate a set of random numbers R, which has a length n, using the following formulas: R[k] = ((2^-46)(X[k])) mod 2^46, where X[k

Re: [Haskell-cafe] Strict version of Data.Map.map

On Thu, Feb 26, 2009 at 12:45:09PM -0300, Felipe Lessa wrote: > I'd advise you to see Control.Parallel.Strategies, specially the > NFData class and the rnf function. What is the time complexity of running rnf on a Data.Map? If it is O(n), then surely running rnf on my map after every 'map' operati

Re: [Haskell-cafe] Performance question

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. >

Re: [Haskell-cafe] Strict version of Data.Map.map

On Thu, Feb 26, 2009 at 2:13 PM, Edsko de Vries wrote: > On Thu, Feb 26, 2009 at 12:45:09PM -0300, Felipe Lessa wrote: >> I'd advise you to see Control.Parallel.Strategies, specially the >> NFData class and the rnf function. > > What is the time complexity of running rnf on a Data.Map? If it is O(

Re: [Haskell-cafe] Performance Issue

james.swaine: > i'm implementing a benchmark which includes a detailed specification for a > random number generator. for any of the kernels outlined in the benchmark, i > might have to generate a set of random numbers R, which has a length n, using > the following formulas: > > R[k] = ((2^-46)(X

Re: [Haskell-cafe] Performance Issue

2009/2/26 James Swaine > --gets r[k], which is the value at the kth > --position in the overall sequence of > --pseudorandom numbers > getRandAt :: Int64 -> Int64 -> Float > getRandAt 0 seed = multiplier * (fromIntegral seed) > getRandAt k seed = multiplier * (fromIntegral x_next) > where >

Re: [Haskell-cafe] Performance question

How about an FFI call to rand() and then measure the performance On Thu, Feb 26, 2009 at 3:37 AM, Felipe Lessa wrote: > On Thu, Feb 26, 2009 at 7:56 AM, Eugene Kirpichov > wrote: > > Here is a variant that uses mersenne-random-pure64 and works less than > > 2x slower than C++: > > And I would li

Re: [Haskell-cafe] Memoization local to a function

Thanks for all the hints and code provided, nevertheless, it implied another questions: 1) Am I right that MemoCombinators can be hardly ever used with hugs? If not, which guidelines to be used for installation... 2) Is there any paper/tutorial/wiki that describes, which local definitions/expr

Re: [Haskell-cafe] Memoization local to a function

Thanks for all the hints and code provided, nevertheless, it implied another questions: 1) Am I right that MemoCombinators can be hardly ever used with hugs? If not, which guidelines to be used for installation... 2) Is there any paper/tutorial/wiki that describes, which local definitions/expr

[Haskell-cafe] Re: Incremental array updates

Ross Paterson wrote: On Thu, Feb 26, 2009 at 05:31:34PM +0100, Daniel Kraft wrote: Well, my main problem was the lazy evaluation... No, your main problem was that you were creating 100,000 arrays, each only a little different from the one before. Here I have to disagree (in my particular sit

[Haskell-cafe] Re: Performance question

Ketil Malde wrote: > So it seems we're just tremendously lousy at generating random > Doubles. > We had this a while ago, and Don was kind enough to post some bindings to dSFMT: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/mersenne-random-pure64-0.2.0.2 which could have a purer int

Re: [Haskell-cafe] Re: Incremental array updates

Hello Daniel, Thursday, February 26, 2009, 9:27:10 PM, you wrote: > It was about this: I needed to generate "all possibilities" for some > combinations and each of those had a numeric property, say from 1 to > 1; I then had to count how many of the possibilities were of a given > "category"

Re: [Haskell-cafe] Performance Issue

Am Donnerstag, 26. Februar 2009 18:48 schrieb Luke Palmer: > 2009/2/26 James Swaine > > > --gets r[k], which is the value at the kth > > --position in the overall sequence of > > --pseudorandom numbers > > getRandAt :: Int64 -> Int64 -> Float > > getRandAt 0 seed = multiplier * (fromIntegral seed)

Re: [Haskell-cafe] Re: Incremental array updates

On Thu, Feb 26, 2009 at 07:27:10PM +0100, Daniel Kraft wrote: > It was about this: I needed to generate "all possibilities" for some > combinations and each of those had a numeric property, say from 1 to > 1; I then had to count how many of the possibilities were of a given > "category".

Re: [Haskell-cafe] Re: Incremental array updates

On Thu, Feb 26, 2009 at 06:45:27PM +, Ross Paterson wrote: > Yes, bucketing problems like this are a common case that the standard > functions cannot handle. Perhaps the libraries need a canned solution. Stratch that -- as Bulat points out, accumArray is such a canned solution. __

Re: [Haskell-cafe] Re: Incremental array updates

On Thu, Feb 26, 2009 at 09:36:17PM +0300, Bulat Ziganshin wrote: > Thursday, February 26, 2009, 9:27:10 PM, you wrote: > > It was about this: I needed to generate "all possibilities" for some > > combinations and each of those had a numeric property, say from 1 to > > 1; I then had to count h

Re[2]: [Haskell-cafe] Re: Incremental array updates

Hello Ross, Thursday, February 26, 2009, 9:54:23 PM, you wrote: >> the same loop using STArray, but accumArray provide you pure API for >> such computations > And accumArray can also be used with UArray if laziness is a problem. to be exact, for Array, STArray used internally for U

Re[2]: [Haskell-cafe] Re: Incremental array updates

Hello Eugene, Thursday, February 26, 2009, 5:32:14 PM, you wrote: look at http://haskell.org/haskellwiki/Library/ArrayRef it contains reimplementation of arrays library according to Oleg&Simon idea: - Unboxed arrays now can be used in polymorphic functions, they are defined for every element typ

[Haskell-cafe] statep haskell-lang [was: Re: Hoogle and Network.Socket]

"John A. De Goes" wrote: > Partial functions and dependent typing do not seem to play well together, > for instance. > Well, sure, they do, as long as you don't expect the typechecker to terminate if some type it checks is formulated in unterminating code. GHC already has this problem if you enab

[Haskell-cafe] Re: base-4 + gtk2hs-0.10.0 licensing

Wolfgang Jeltsch wrote: > Am Donnerstag, 26. Februar 2009 09:17 schrieb Ketil Malde: > > Peter Hercek writes: > > >> Relinking against newer Gtk2Hs versions might not work. > > > > You have the option of recompiling the new Gtk2Hs with the old GHC > > and relinking, don't you? > > Relinking is

[Haskell-cafe] Re: statep haskell-lang [was: Re: Hoogle and Network.Socket]

Achim Schneider wrote: > -calculus > PiSigma calculus, that is. I really shouldn't attempt to send unicode via US-ascii. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of

Re: [Haskell-cafe] statep haskell-lang [was: Re: Hoogle and Network.Socket]

On Feb 26, 2009, at 12:12 PM, Achim Schneider wrote: I think that arguing that Haskell is _obsolete_ because it isn't yet fully dependently typed is vastly mistaken. I never said it was obsolete. Far from it. But I did say that choices already made and codified into H98 have implications on t

Re: Re[2]: [Haskell-cafe] Re: Incremental array updates

Hello, Thanks, I'll have a look at these. Treating unboxed stuff polymorphically is anyways very interesting and would be good to use in collections API that has been recently discussed (and which I occasionally try to continue inventing with scarce success :-/ ). 2009/2/26 Bulat Ziganshin : > Hel

Re: [Haskell-cafe] Performance question

On Thu, Feb 26, 2009 at 6:23 PM, Don Stewart 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 w_s1

[Haskell-cafe] Re: statep haskell-lang [was: Re: Hoogle and Network.Socket]

"John A. De Goes" wrote: > What do you mean by "progress"? I noted before that there are > tradeoffs. Constraining the evolution of the language in backward > compatible ways leads to substantial improvements in tools, > libraries, and the speed of compiled code. That's progress in several >

Re: [Haskell-cafe] Re: statep haskell-lang [was: Re: Hoogle and Network.Socket]

Are you saying has been no progress since K&R C in the number of libraries available to C programmers? And that C programmers still have to edit files with vi and compile and link by specifying all files on the command-line? You may disagree, but the evidence points in the opposite direct

Re: [Haskell-cafe] Re: statep haskell-lang [was: Re: Hoogle and Network.Socket]

On Thu, 2009-02-26 at 13:18 -0700, John A. De Goes wrote: > Are you saying has been no progress since K&R C in the number of > libraries available to C programmers? And that C programmers still > have to edit files with vi and compile and link by specifying all > files on the command-line? >

Re: [Haskell-cafe] Re: statep haskell-lang [was: Re: Hoogle and Network.Socket]

No, I hate C and will never use it again in my entire life unless forced to at the point of a gun. You're point? :-P Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 26, 2009, at 1:17 PM, Jonathan Cast wrote:

[Haskell-cafe] Re: base-4 + gtk2hs-0.10.0 licensing

Wolfgang Jeltsch wrote: Am Mittwoch, 25. Februar 2009 23:38 schrieb Peter Hercek: So my opinion (IAMNAL): 1) source code under very limiting commercial license (just to allow recompile with a newer LGPL lib and nothing else) is OK 2) it is probable that only the *.o, *.hi files and a linking

Re: [Haskell-cafe] Re: statep haskell-lang [was: Re: Hoogle and Network.Socket]

On Thu, 2009-02-26 at 13:25 -0700, John A. De Goes wrote: > No, I hate C and will never use it again in my entire life unless > forced to at the point of a gun. Why? Its libraries are far better, its editors are far better [1], its compilers are far better, its tool support is far better, it's

  1   2   >