
Hi. I'm pleased to announce the availability of my random-stream package. The cabalized package is available at: http://haskell.mperillo.ath.cx/random-stream-0.0.1.tar.gz Note that I have not uploaded it on Hackage, and I do not plan to upload it in the near future, at least until I will repute the package mature enough. From package description: Portable interface for the operating system source of pseudo random data. Supported sources are Unix /dev/urandom, Win32 CryptGenRandom and OpenSSL pseudo random numbers generator. This package is based on idea from os.urandom implementation, in CPython. The idea is to view the system pseudo random generator as a stream of infinite random bytes. So, I have used a lazy bytestring, and unsafePerformIO/unsafeInterleaveIO. The underlying data is: newtype Stream = Stream L.ByteString and the constructor *is exposed*. The package configuration *must* be done using a flag to specify the "source" to use. As an example: runghc Setup.hs configure -O2 -fHAVE_URANDOM runghc Setup.hs configure -O2 -fHAVE_SSL runghc Setup.hs configure -O2 -fHAVE_WIN32_CRYPT If the flag is not specified, the compilation will fail. Note that Windows it not yet supported. The stream generator implements tha RandomGen interface. Some notes: 1) The system *pseudo* random generator is used. As an example, on Linux, /dev/random produces "true" random numbers, but it may block if there is not enough entropy in the system. More details on http://en.wikipedia.org/wiki//dev/random 2) When reading data, the lazy bytestring chunk size is used. The default chunk size, however, is fine when reading from a regular file, but may not be the best choice when reading pseudo random numbers. For SSL (and Windows) support, the chunk size can be easily changed; but for Unix support this seems to not be possible, unless I reimplement hGetContents. The Data.ByteString.Lazy module have an hGetContentsN function. Unfortunately it is not exposed. I find this annoying; is it possible to export the *N functions from Data.ByteString.Lazy.Internal? 3) I have tested the package on Debian Linux Etch, using GHC 6.8.2. Feedback will be appreciate. I not sure about some details. Usage example: module Main where import System.Random import System.Random.Stream gen = mkStream l :: [Int] l = randoms gen :: [Int] main = do print l Manlio Perillo

On Thu, Mar 19, 2009 at 11:55:16AM +0100, Manlio Perillo wrote:
Note that I have not uploaded it on Hackage, and I do not plan to upload it in the near future, at least until I will repute the package mature enough.
I would encourage you to upload it to Hackage regardless of its supposed maturity, especially if you want feedback. I'm not sure why you would be hesitant to upload your package; Hackage hosts an extremely wide range of packages in terms of maturity, and that's a good thing. It also provides a very convenient method (in combination with cabal-install) of disseminating libraries. I am several orders of magnitude more likely to try something out if I can just 'cabal install foo' than if I have to manually download and unpack a tarball myself, and I doubt I am alone in this. -Brent

Brent Yorgey ha scritto:
On Thu, Mar 19, 2009 at 11:55:16AM +0100, Manlio Perillo wrote:
Note that I have not uploaded it on Hackage, and I do not plan to upload it in the near future, at least until I will repute the package mature enough.
I would encourage you to upload it to Hackage regardless of its supposed maturity, especially if you want feedback. I'm not sure why you would be hesitant to upload your package;
Because I'm very strict with my code. I don't even release my Python packages on http://pypi.python.org/pypi, and I'm much more expert in Python ;-).
Hackage hosts an extremely wide range of packages in terms of maturity, and that's a good thing. It also provides a very convenient method (in combination with cabal-install) of disseminating libraries. I am several orders of magnitude more likely to try something out if I can just 'cabal install foo' than if I have to manually download and unpack a tarball myself, and I doubt I am alone in this.
It should be possible to do: cabal install http://haskell.mperillo.ath.cx/random-stream-0.0.1.tar.gz It's unfortunate that this is not supported. Thanks Manlio

Maybe the feature has been added, but not released, because somebody is strict about their code...
It should be possible to do: cabal install http://haskell.mperillo.ath.cx/random-stream-0.0.1.tar.gz
It's unfortunate that this is not supported.
Thanks Manlio _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Manlio Perillo
The stream generator implements tha RandomGen interface.
This is really cool, though I think 'split' is a must. Maybe all instances could share the same stream in the background, then it wouldn't cause resource issues. Also, IMHO mkStream should produce an IO Stream (like getStdGen), as current implementation isn't referentially transparent; let the library user decide whether to use unsafePerformIO.
3) I have tested the package on Debian Linux Etch, using GHC 6.8.2.
Tested with Gentoo Linux on a 64-bit machine using GHC 6.10.1. On my system, it is less than 2 times slower than StdGen. -- Gökhan San

Gökhan San ha scritto:
Manlio Perillo
writes: The stream generator implements tha RandomGen interface.
This is really cool, though I think 'split' is a must. Maybe all instances could share the same stream in the background, then it wouldn't cause resource issues.
I have thought about this, but is it safe? I feared that this would break referential transparency.
Also, IMHO mkStream should produce an IO Stream (like getStdGen), as current implementation isn't referentially transparent; let the library user decide whether to use unsafePerformIO.
The basic idea is that there is this system wide random number generator, that is always available. That's the reason why mkIOStream is hidden.
3) I have tested the package on Debian Linux Etch, using GHC 6.8.2.
Tested with Gentoo Linux on a 64-bit machine using GHC 6.10.1. On my system, it is less than 2 times slower than StdGen.
Thanks for the report. I have tested against the pure mersenne twister, on my 32 bit system, and it seems to have the same performances. I should check against StdGen, too. Manlio

Manlio Perillo
Gökhan San ha scritto:
Manlio Perillo
writes: The stream generator implements tha RandomGen interface.
This is really cool, though I think 'split' is a must. Maybe all instances could share the same stream in the background, then it wouldn't cause resource issues.
I have thought about this, but is it safe? I feared that this would break referential transparency.
You're absolutely right, my bad. To test locally, I wrote a split function by merging Stream with StdGen, but I'm not sure if it makes much sense statistically:
data Stream = Stream StdGen L.ByteString
instance RandomGen Stream where next (Stream t s) = (xor it (fromIntegral is), Stream t' s') where (it, t') = next t (is, s', _) = (runGetState getWordhost) s 0 split (Stream t s) = let (left, right) = split t in (Stream left s, Stream right s)
I'd love to test how it scales if you happen to implement split on the stream.
Also, IMHO mkStream should produce an IO Stream (like getStdGen), as current implementation isn't referentially transparent; let the library user decide whether to use unsafePerformIO.
The basic idea is that there is this system wide random number generator, that is always available. That's the reason why mkIOStream is hidden.
Ah, OK, I get it now. -- Gökhan San
participants (4)
-
Andrew Wagner
-
Brent Yorgey
-
gsan@stillpsycho.net
-
Manlio Perillo