Re: Efficiencies of containers
On Fri, 4 Dec 1998, Fergus Henderson wrote: ... > I think your understanding is gravely mistaken. > > The intent, I believe, is that Haskell Arrays should be > implemented as contiguous memory, at least for optimizing compilers. > Implementations using association lists would IMHO only be > suitable only for non-optimizing compilers. > Well, this was only my understanding and was qualified as one of the things that were not clear to me. I still have my doubts and I would really like to find some authoritative answer instead of heresays about slugishness of Haskell arrays that I see here and there on the net. See for example, "Implementing the conjugate gradient algorithm" by P.R. Serrarens, http://www.cs.kun.nl/~pascalrs/ He very definitely dismisses Haskell arrays as unsuitable for scientific computations. He used GHC - optimized compiler after all. On the other hand, he speaks highly of Haskell lists. Which prompted me to do my little tests in Hugs. Also favouring the lists.. Jan
Re: library for bitwise operation?
Wishnu Prasetya <[EMAIL PROTECTED]> writes: | Is there somewhere a Haskell library for words and bitwise operations on | words (like XOR, shifts, bit permutations)? (bitwise operations are used | a lot in cryptography) nhc13 comes with such a library. See http://www.cs.york.ac.uk/fp/nhc13/libs/Bit.html It is implemented using GreenCard, so it should be reasonably portable to ghc and Hugs. For cryptographic applications, you might also be interested in nhc13's Binary library which gives more general unbounded bit-stream operations. This Binary library is also available for ghc. Regards, Malcolm -- The nhc13 Haskell compiler: http://www.cs.york.ac.uk/fp/nhc13/
Re: Random comments
| First: I had forgotten that what the Random module actually | gives you is [Integer], not [Int], but the same reasoning | applies. What's the range for the Integers? I guess Int is better suited. | Well, you naturally need functions that convert a list of | [Integer] to what you need. I'm not at all against such functions, | and I think they should be included, e.g. | toDouble :: [Integer] -> [Double] | toInt :: [Integer] -> [Int] | etc. So I might write | let mis = take n (random ss1) | is = take n (toInt (random ss2)) | ds = take n (toDouble (random ss3)) | in ... | where ss1, ss2, ss3 are the seeds. You can get them from an initial | call to randomIO or use some known values if you need to repeat the sequence. My problem with your solution is that you must supply a seed for every call (perhaps you don't know how many do you require) and that you may end up with pseudo-random numbers which are not random at all. Because you choose the seeds badly. That's why I thread the (current) seed through all those value generators. Of course, instead of threadening a seed one could thread an infinite list of Ints. | I think using monads, and specially a powerful one like IO, everywhere is | a mistake. I can't see the need for most uses of random numbers. I agree that the IO monad is not necessary. However, a monad for random values seems perfectly reasonable. Ralf
Re: Random comments
> I guess you would end up with nearly the same code (unless I overlook > an obvious alternative in which case I would love to see the simple and > straightforward solution ;-). Let's be concrete: say you need n > Integers within range (l, r), m Ints and p Doubles. Using a monad-based > approach one writes > > ... > mis <- accumulate [ randomInteger (l, r) | i <- [1 .. n] ] > is <- accumulate [ randomInt | i <- [1 .. m] ] > ds <- accumulate [ randomDouble | i <- [1 .. p] ] > return (mis, is, ds) > > What's your solution based on an [Int] list of random numbers? First: I had forgotten that what the Random module actually gives you is [Integer], not [Int], but the same reasoning applies. Well, you naturally need functions that convert a list of [Integer] to what you need. I'm not at all against such functions, and I think they should be included, e.g. toDouble :: [Integer] -> [Double] toInt :: [Integer] -> [Int] etc. So I might write let mis = take n (random ss1) is = take n (toInt (random ss2)) ds = take n (toDouble (random ss3)) in ... where ss1, ss2, ss3 are the seeds. You can get them from an initial call to randomIO or use some known values if you need to repeat the sequence. I think using monads, and specially a powerful one like IO, everywhere is a mistake. I can't see the need for most uses of random numbers. -- Lennart
Re: Conditional Deriving
I wrote: |It would be better if something like: | |instance deriving Eq a => Eq (Queue a) |instance deriving Ord a => Ord (Queue a) | |was allowed, which derived the methods _if possible_ but otherwise |does not restrict the use of the types. Ralf Hinze pointed out to me that: > data Queue a = ... deriving (Eq,Ord) will suffice. I thought that this would give an error! Looking closer at the Haskell report, I even find an example that fits this pattern: > data Pair a b = Pair a b deriving Bounded D'oh! I'll go crawl into a corner and hide... Graeme.
Re: Random comments
| > The stream-based approach has its problems if one requires random | > values of different types. If this is vital one automatically starts to | > use functions of type Seed -> (value, Seed). | I don't understand at all. Why would random values of different types | require that signature? Why can you use an infinite list of these | other values? Why can't you take the [Int] list of random numbers | and transform it into whatever you want? That's what I do. I guess you would end up with nearly the same code (unless I overlook an obvious alternative in which case I would love to see the simple and straightforward solution ;-). Let's be concrete: say you need n Integers within range (l, r), m Ints and p Doubles. Using a monad-based approach one writes ... mis <- accumulate [ randomInteger (l, r) | i <- [1 .. n] ] is <- accumulate [ randomInt | i <- [1 .. m] ] ds <- accumulate [ randomDouble | i <- [1 .. p] ] return (mis, is, ds) What's your solution based on an [Int] list of random numbers? Ralf
Re: Random comments
> The stream-based approach has its problems if one requires random > values of different types. If this is vital one automatically starts to > use functions of type Seed -> (value, Seed). I don't understand at all. Why would random values of different types require that signature? Why can you use an infinite list of these other values? Why can't you take the [Int] list of random numbers and transform it into whatever you want? That's what I do. -- Lennart
Re: Random comments
| Could somebody - perhaps outside this list - provide a serious | example showing the *necessity* for RandomIO() - the Monadic, | "side-effect" version? In a pure functional language? Well, I'm not outside this list ;-). Honestly, there is no necessity for using the IO monad, it is just a matter of convenience, see below. | I use random numbers from time to time. | I have always used sequences, lazily generated. No problem | with the seed injection/restoring, and - what is *much* more | important: | | No problem with having *several* generators within the program. The stream-based approach has its problems if one requires random values of different types. If this is vital one automatically starts to use functions of type Seed -> (value, Seed). Sooner or later you recognize that you are programming in a state monad. Now, one could define a specialized monad or misuse (if you like) IO. | In a serious application this is useful for generating random | vectors, or for using one generator to decorrelate another. | I agree with the comments of David Tweed. Please give the | People the Power to plug-in several generators, instead of | eine Sprache, eine Kirche, ein ZufallsZahlGeneratorIO()... I don't see why this should be a problem. The dilegent user is always free to plug in new generators, simply by supplying modules which have the same signature as `Random'. | You might answer that a primitive is more efficient. But in | typical simulations or other applications which use random | numbers (Monte-Carlo, etc.) this is usually not as important. It's probably both more efficient and more convenient ;-). Cheers, Ralf
library for bitwise operation?
Hi all, i just want to ask: Is there somewhere a Haskell library for words and bitwise operations on words (like XOR, shifts, bit permutations)? (bitwise operations are used a lot in cryptography) Thanks. --Wishnu
Re: Random comments
| I think using monads, and specially a powerful one like IO, everywhere is | a mistake. I can't see the need for most uses of random numbers. | | -- Lennart Besides that, isn't the name "randomIO" a bit unfortunate? It sounds like it contrasts with "sequentialIO". --Joe Joseph H. Fasel, Ph.D. email: [EMAIL PROTECTED] Technology Modeling and Analysisphone: +1 505 667 7158 University of Californiafax:+1 505 667 2960 Los Alamos National Laboratory postal: TSA-7 MS F609 Los Alamos, NM 87545
Random comments
Could somebody - perhaps outside this list - provide a serious example showing the *necessity* for RandomIO() - the Monadic, "side-effect" version? In a pure functional language? I use random numbers from time to time. I have always used sequences, lazily generated. No problem with the seed injection/restoring, and - what is *much* more important: No problem with having *several* generators within the program. In a serious application this is useful for generating random vectors, or for using one generator to decorrelate another. I agree with the comments of David Tweed. Please give the People the Power to plug-in several generators, instead of eine Sprache, eine Kirche, ein ZufallsZahlGeneratorIO()... You might answer that a primitive is more efficient. But in typical simulations or other applications which use random numbers (Monte-Carlo, etc.) this is usually not as important. Best regards Jerzy Karczmarczuk Caen, France.
