You can subscribe to this list here.
2000 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}
(1) 
_{Jun}
(2) 
_{Jul}
(2) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}
(3) 

2001 
_{Jan}

_{Feb}

_{Mar}

_{Apr}
(1) 
_{May}
(8) 
_{Jun}

_{Jul}
(2) 
_{Aug}
(3) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}

2002 
_{Jan}

_{Feb}
(2) 
_{Mar}
(3) 
_{Apr}

_{May}
(5) 
_{Jun}

_{Jul}

_{Aug}
(2) 
_{Sep}
(3) 
_{Oct}

_{Nov}

_{Dec}
(8) 
2003 
_{Jan}
(5) 
_{Feb}
(4) 
_{Mar}
(14) 
_{Apr}

_{May}
(27) 
_{Jun}
(10) 
_{Jul}
(3) 
_{Aug}
(28) 
_{Sep}
(27) 
_{Oct}
(3) 
_{Nov}
(14) 
_{Dec}
(19) 
2004 
_{Jan}
(32) 
_{Feb}
(15) 
_{Mar}
(21) 
_{Apr}
(69) 
_{May}
(18) 
_{Jun}
(15) 
_{Jul}
(23) 
_{Aug}
(14) 
_{Sep}
(38) 
_{Oct}
(20) 
_{Nov}
(76) 
_{Dec}
(27) 
2005 
_{Jan}
(24) 
_{Feb}
(32) 
_{Mar}
(39) 
_{Apr}
(65) 
_{May}
(69) 
_{Jun}
(37) 
_{Jul}
(32) 
_{Aug}
(28) 
_{Sep}
(28) 
_{Oct}
(17) 
_{Nov}
(30) 
_{Dec}
(24) 
2006 
_{Jan}
(45) 
_{Feb}
(38) 
_{Mar}
(19) 
_{Apr}
(26) 
_{May}
(19) 
_{Jun}
(29) 
_{Jul}
(13) 
_{Aug}
(26) 
_{Sep}
(53) 
_{Oct}
(46) 
_{Nov}
(40) 
_{Dec}
(85) 
2007 
_{Jan}
(45) 
_{Feb}
(51) 
_{Mar}
(69) 
_{Apr}
(48) 
_{May}
(75) 
_{Jun}
(35) 
_{Jul}
(35) 
_{Aug}
(25) 
_{Sep}
(11) 
_{Oct}
(16) 
_{Nov}
(9) 
_{Dec}
(59) 
2008 
_{Jan}
(36) 
_{Feb}
(17) 
_{Mar}
(28) 
_{Apr}
(13) 
_{May}
(1) 
_{Jun}
(25) 
_{Jul}
(24) 
_{Aug}
(52) 
_{Sep}
(19) 
_{Oct}
(52) 
_{Nov}
(43) 
_{Dec}
(80) 
2009 
_{Jan}
(33) 
_{Feb}
(30) 
_{Mar}
(18) 
_{Apr}
(15) 
_{May}
(29) 
_{Jun}
(58) 
_{Jul}
(48) 
_{Aug}
(35) 
_{Sep}
(52) 
_{Oct}
(59) 
_{Nov}
(46) 
_{Dec}
(31) 
2010 
_{Jan}
(26) 
_{Feb}
(45) 
_{Mar}
(55) 
_{Apr}
(59) 
_{May}
(8) 
_{Jun}
(24) 
_{Jul}
(43) 
_{Aug}
(31) 
_{Sep}
(43) 
_{Oct}
(33) 
_{Nov}
(41) 
_{Dec}
(19) 
2011 
_{Jan}
(17) 
_{Feb}
(31) 
_{Mar}
(5) 
_{Apr}
(31) 
_{May}
(17) 
_{Jun}
(28) 
_{Jul}
(15) 
_{Aug}
(38) 
_{Sep}
(21) 
_{Oct}
(25) 
_{Nov}
(21) 
_{Dec}
(21) 
2012 
_{Jan}
(9) 
_{Feb}
(22) 
_{Mar}
(17) 
_{Apr}
(16) 
_{May}
(58) 
_{Jun}
(13) 
_{Jul}
(40) 
_{Aug}
(12) 
_{Sep}
(10) 
_{Oct}
(10) 
_{Nov}
(14) 
_{Dec}
(4) 
2013 
_{Jan}
(9) 
_{Feb}
(8) 
_{Mar}
(17) 
_{Apr}
(10) 
_{May}

_{Jun}
(9) 
_{Jul}
(1) 
_{Aug}
(7) 
_{Sep}
(8) 
_{Oct}
(22) 
_{Nov}
(9) 
_{Dec}
(6) 
2014 
_{Jan}
(30) 
_{Feb}
(55) 
_{Mar}
(38) 
_{Apr}
(15) 
_{May}
(7) 
_{Jun}
(17) 
_{Jul}
(15) 
_{Aug}
(13) 
_{Sep}
(21) 
_{Oct}
(29) 
_{Nov}
(7) 
_{Dec}
(10) 
2015 
_{Jan}
(11) 
_{Feb}
(19) 
_{Mar}
(32) 
_{Apr}
(17) 
_{May}
(5) 
_{Jun}
(3) 
_{Jul}
(9) 
_{Aug}
(7) 
_{Sep}
(19) 
_{Oct}
(3) 
_{Nov}
(31) 
_{Dec}
(23) 
2016 
_{Jan}
(11) 
_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 

1
(1) 
2

3

4

5

6

7
(1) 
8
(5) 
9
(11) 
10
(5) 
11
(1) 
12
(6) 
13

14

15

16

17

18
(2) 
19

20

21

22

23

24

25

26

27

28

29

30
(8) 
31





From: Jeffrey Cunningham <jeffrey@jk...>  20120709 23:06:11

On 07/09/2012 01:07 PM, Waldek Hebisch wrote: > Of course, the user may do something stupid, like ... Real civil. Your a real asset to the help community. JC 
From: <m_mommer@ya...>  20120709 21:35:38

Christophe Rhodes <csr21@...> writes: > The issue at hand is whether the "extra" density of floats around 0 > should be used by the RNG. At first, it seems obvious that it should, > because well, why not? On the other hand, imagine a simple use of a RNG > to generate samples from a distribution using the CDF and a lookup > table: generate a float between 0 and 1 and transform according to the > inverse of the CDF. Ignoring for the moment the actual generation of > zeros, if the RNG exploits the wide range of floats around 0, the lower > tail of the distribution will be much, much more explored than the upper > tail, because the floating point resolution around 0 is far greater than > it is around 1. It explores everywhere at the highest available resolution. It doesn't explore "much, much more"  this must be a misunderstanding. With the patch, the distribution of the samples generated with an inversion method will resemble more faithfully the intended distribution. Why is this a disadvantage? > There are other issues, but this one was enough to convince me that I > didn't want to place too much emphasis on my own instinct, and that I'd > like to read "what every RNG maintainer should know about actual uses of > floating point random variates". Could you elaborate? I'm interested in hearing about those other issues. In particular, do you know of any code that would actually break with this patch? Regards, and thanks, Mario. 
From: Waldek Hebisch <hebisch@ma...>  20120709 20:39:30

Christophe Rhodes wrote: > The issue at hand is whether the "extra" density of floats around 0 > should be used by the RNG. At first, it seems obvious that it should, > because well, why not? One paradigm for floating point operations is that operation is first performed exactly and after that the result is rounded to a representable float. Sometimes doing so may cost a lot of compute time and a lot of coding effort (when we require "correct rounding"), so IMHO there are reasons to use approximations with higher error. But for RNG in single precision correct rounding seem to be obtainable with reasonable effort. Given that values close to zero have extremally small probablity one can use approximations (say rounding 64bit random integer scaled to the unit interval) that are close enough but cheaper to compute. So using extra precision around zero is fits well with philosopy of floating point. > On the other hand, imagine a simple use of a RNG > to generate samples from a distribution using the CDF and a lookup > table: generate a float between 0 and 1 and transform according to the > inverse of the CDF. Ignoring for the moment the actual generation of > zeros, if the RNG exploits the wide range of floats around 0, the lower > tail of the distribution will be much, much more explored than the upper > tail, because the floating point resolution around 0 is far greater than > it is around 1. I am not sure what you mean by "more explored". If you mean that floats close to zero have higher absolute precision, then it is what usualy is expected: taking log of uniform distribution one wants to get exponential distribution. When RNG uses uniform absolute precision in the interval (0, 1) the result is distorded tail of exponential distibution. When RNG makes good use of extra absolute precision available close to 0 then tail of transformed distribution is much closer to the true exponential distibution. Of course, the user may do something stupid, like using log(1  x) with x unifor in (0,1) to generate exponential distibution. Then extra effort spent close to 0 is wasted. Given the above I think that RNG which makes use of extra precision around 0 is better than one which does not. OTOH there are many uses of random numbers, some are content with low quality random source but are highly sensitive to speed, while other absolutely need high quality. It is likely that user will want different speed/quality tradeoff then the one provided by the default implementation. So I am ready to use my own or third party code if needed.  Waldek Hebisch hebisch@... 
From: Christophe Rhodes <csr21@ca...>  20120709 17:21:26

Jeffrey Cunningham <jeffrey@...> writes: > Isn't an "extra density of floats around 0"  by definition  a > nonuniform distribution? Not in the sense that I mean. Or possibly "yes", but welcome to the world of floating point: because floating point numbers are a discrete set, not a continuum, there's no such thing as a continuous uniform distribution using floats, only particular approximations. Briefly, a floating point number is represented by sign, mantissa and exponent. Sign is always +1 or 1. What remains is the mantissa, which is a representation of the bits after the decimal point in the binary number 1.xxxxxxxxxxxxxx..., and the exponent, which indicates the power to which 2 must be raised to get you the number you want. (I am eliding lots of details here; there are references where you can read them). So for example, 0.5 is represented as the sign/mantissa/exponent triple (1, 0, 1); 0.75 is (1, 10000000..._2, 1), 0.875 is (1, 11000000..._2, 1), and so on. The point here is that the density of representable floating points /changes/ as the exponent changes: there are as many machine floats between 0.25 and 0.5 as there are between 0.5 and 1, and this isn't some kind of transfinite sleight of hand, this is a finite, countable set. So, near zero, there are more possible floats than there are near 1. Obviously, the RNG compensates for that, by having the possible floats near zero be generated with lower probability than those near one. But the point is that there is more than one way of performing that compensation: the appropriate probability mass could be distributed evenly over all possible floats within an evenlyspaced region, or a single representative in a region could be selected as an archetype  and if so, which representative? SBCL's strategy for generating numbers between 0 and 1 isn't so utterly stupid as you seem to think; it makes one particular choice, by selecting floats between 1 and 2 (which does have a uniform density of representable floats), and then subtracting 1. This has the effect of emphasizing the probability of generating 0 compared with the floating point numbers which are in fact representable in the region of 0, but that effect has potential virtues too (such as preserving the basic symmetry of the region near 0 and near 1 in the conceptual uniform distribution). > I would think this is highly undesirable behavior in a uniform RNG and > should be corrected. Tell you what: please specify unambiguously, paying reference to the hardware representations, the behaviour of the RNG when given a singlefloat 1.0 argument, and justify why the specified behaviour is better than all other behaviours in all circumstances. Cheers, Christophe 
From: Jeffrey Cunningham <jeffrey@jk...>  20120709 16:45:40

On 07/09/2012 07:56 AM, Christophe Rhodes wrote: > Jeffrey Cunningham <jeffrey@...> writes: > >> That is very flawed behavior in a random number generator you are >> describing. What is the status of your patch? > That (that the RNG was flawed) was my instinct too, initially, but I > think I've been convinced out of it: that instead, lots that relates to > floating point is not as obvious as it first seems. > > The issue at hand is whether the "extra" density of floats around 0 > should be used by the RNG. At first, it seems obvious that it should, > because well, why not? On the other hand, imagine a simple use of a RNG > to generate samples from a distribution using the CDF and a lookup > table: generate a float between 0 and 1 and transform according to the > inverse of the CDF. Ignoring for the moment the actual generation of > zeros, if the RNG exploits the wide range of floats around 0, the lower > tail of the distribution will be much, much more explored than the upper > tail, because the floating point resolution around 0 is far greater than > it is around 1. Isn't an "extra density of floats around 0"  by definition  a nonuniform distribution? I would think this is highly undesirable behavior in a uniform RNG and should be corrected. Regards, Jeff Cunningham 
From: Christophe Rhodes <csr21@ca...>  20120709 14:56:28

Jeffrey Cunningham <jeffrey@...> writes: > That is very flawed behavior in a random number generator you are > describing. What is the status of your patch? That (that the RNG was flawed) was my instinct too, initially, but I think I've been convinced out of it: that instead, lots that relates to floating point is not as obvious as it first seems. The issue at hand is whether the "extra" density of floats around 0 should be used by the RNG. At first, it seems obvious that it should, because well, why not? On the other hand, imagine a simple use of a RNG to generate samples from a distribution using the CDF and a lookup table: generate a float between 0 and 1 and transform according to the inverse of the CDF. Ignoring for the moment the actual generation of zeros, if the RNG exploits the wide range of floats around 0, the lower tail of the distribution will be much, much more explored than the upper tail, because the floating point resolution around 0 is far greater than it is around 1. There are other issues, but this one was enough to convince me that I didn't want to place too much emphasis on my own instinct, and that I'd like to read "what every RNG maintainer should know about actual uses of floating point random variates". Cheers, Christophe 
From: Jeffrey Cunningham <jeffrey@jk...>  20120709 14:33:47

On 07/09/2012 05:24 AM, Mario S. Mommer wrote: > Jeffrey Cunningham <jeffrey@...> writes: >> Have you looked at a distribution of the outputs? I'm wondering if there's >> something else wrong. You really shouldn't see zero show up as an argument to >> log except once in a blue moon. > When using single floats, the probability of obtaining a zero is not so > low, at least with the usual way of generating random floats. > > The following code usually returns in less than a second on my home > desktop. > > (let ((i 0)) (loop while (> (random 1.0s0) 0) do (incf i)) i) > > This one takes a lot longer: > > (let ((i 0)) (loop while (> (random 1.0d0) 0) do (incf i)) i) > > There are other, arguably better, ways to generate random floats, and > then zeros are really unlikely to happen. With this patch, > > http://comments.gmane.org/gmane.lisp.steelbank.devel/16674 > > a singlefloat zero appears on average every (expt 2 150) calls to > (random 1.0s0), which for practical purposes means never. > > Regards, > Mario > That is very flawed behavior in a random number generator you are describing. What is the status of your patch? Regards, Jeff Cunningham 
From: <m_mommer@ya...>  20120709 12:25:12

Jeffrey Cunningham <jeffrey@...> writes: > Have you looked at a distribution of the outputs? I'm wondering if there's > something else wrong. You really shouldn't see zero show up as an argument to > log except once in a blue moon. When using single floats, the probability of obtaining a zero is not so low, at least with the usual way of generating random floats. The following code usually returns in less than a second on my home desktop. (let ((i 0)) (loop while (> (random 1.0s0) 0) do (incf i)) i) This one takes a lot longer: (let ((i 0)) (loop while (> (random 1.0d0) 0) do (incf i)) i) There are other, arguably better, ways to generate random floats, and then zeros are really unlikely to happen. With this patch, http://comments.gmane.org/gmane.lisp.steelbank.devel/16674 a singlefloat zero appears on average every (expt 2 150) calls to (random 1.0s0), which for practical purposes means never. Regards, Mario 
From: Jeffrey Cunningham <jeffrey@jk...>  20120709 04:11:43

On 07/08/2012 08:39 PM, Burton Samograd wrote: > That was the problem. I'm running a simulation with hundreds of > thousands of agents and that blue moon shows up pretty frequently. I > tried your idea of subtracting from 1 on CCL (SBCL is being too > finicky right now) and it doesn't seem to follow the standard of > [0.0...1.0). I ended up just adding 1E32 to (random 1.0); I really > don't think it will make a difference (famous last words). >> It might be very small numbers will kill log also. If that's the case, >> then you could figure out the threshold for smallest argument to log, >> and put some logic in there to exclude those cases (regen another >> uniform variate). > Maybe but since my tiny addition I haven't had the problem so I'm > satisfied with it as a solution for now. >> Jeff Cunningham >> >  > Burton Samograd > > Careful that U+epsilon doesn't exceed 1.0 or you will mess up the distribution where it counts. It probably would be better to throw away U's that are less than epsilon. All your doing then is cutting off the tails way out there somewhere. Jeff Cunningham 
From: Burton Samograd <burton.samograd@gm...>  20120709 03:39:34

On 120708 06:01 PM, Jeffrey Cunningham wrote: > > On 07/07/2012 08:02 PM, Jeffrey Cunningham wrote: >> >> On 07/07/2012 07:23 PM, Burton Samograd wrote: >>> On 120707 07:03 PM, Kevin Reid wrote: >>>> On Jul 7, 2012, at 17:44, Burton Samograd wrote: >>>> >>>>> Here is the definition of normal, which has no divisions: >>>>> >>>>> (defun normal (&optional (a 1.0) (s 0.5)) >>>>> (+ a (* (sqrt (* 2 (log (random 1.0)))) (cos (* 2 pi (random 1.0))) s))) >>>>> >>>>> Any idea where this division by zero error might be coming from? >>>> RANDOM may return 0.0 in which case LOG will (on SBCL) signal DIVISIONBYZERO. >>>> >>> Ah, I had a feeling it was something like that but the division by zero >>> was throwing me off. >>> >>> Thanks. I got that line from Rosetta Code; maybe it should be fixed. >>> What is a good fix for this? I'm thinking that adding a very small value >>> to the result of random might suffice but I don't like it. >>> >>>  >>> Burton Samograd >> >> Adding a small amount would warp the distribution (a tiny amount). >> But this will work and won't: >> >> (defun normal (&optional (a 1.0) (s 0.5)) >> (+ a (* (sqrt (* 2 (log ( 1.0 (random 1.0))))) (cos (* 2 pi >> (random 1.0))) >> s))) >> >> According to the spec, random produces numbers always less than the >> limit so it will never hit zero. And its a uniform distribution so >> you haven't changed its statistical properties. >> >> Jeff Cunningham >> > Have you looked at a distribution of the outputs? I'm wondering if > there's something else wrong. You really shouldn't see zero show up as > an argument to log except once in a blue moon. That was the problem. I'm running a simulation with hundreds of thousands of agents and that blue moon shows up pretty frequently. I tried your idea of subtracting from 1 on CCL (SBCL is being too finicky right now) and it doesn't seem to follow the standard of [0.0...1.0). I ended up just adding 1E32 to (random 1.0); I really don't think it will make a difference (famous last words). > It might be very small numbers will kill log also. If that's the case, > then you could figure out the threshold for smallest argument to log, > and put some logic in there to exclude those cases (regen another > uniform variate). Maybe but since my tiny addition I haven't had the problem so I'm satisfied with it as a solution for now. > > Jeff Cunningham >  Burton Samograd 
From: Jeffrey Cunningham <jeffrey@jk...>  20120709 00:01:27

On 07/07/2012 08:02 PM, Jeffrey Cunningham wrote: > > On 07/07/2012 07:23 PM, Burton Samograd wrote: >> On 120707 07:03 PM, Kevin Reid wrote: >>> On Jul 7, 2012, at 17:44, Burton Samograd wrote: >>> >>>> Here is the definition of normal, which has no divisions: >>>> >>>> (defun normal (&optional (a 1.0) (s 0.5)) >>>> (+ a (* (sqrt (* 2 (log (random 1.0)))) (cos (* 2 pi (random 1.0))) s))) >>>> >>>> Any idea where this division by zero error might be coming from? >>> RANDOM may return 0.0 in which case LOG will (on SBCL) signal DIVISIONBYZERO. >>> >> Ah, I had a feeling it was something like that but the division by zero >> was throwing me off. >> >> Thanks. I got that line from Rosetta Code; maybe it should be fixed. >> What is a good fix for this? I'm thinking that adding a very small value >> to the result of random might suffice but I don't like it. >> >>  >> Burton Samograd > > Adding a small amount would warp the distribution (a tiny amount). But > this will work and won't: > > (defun normal (&optional (a 1.0) (s 0.5)) > (+ a (* (sqrt (* 2 (log ( 1.0 (random 1.0))))) (cos (* 2 pi > (random 1.0))) > s))) > > According to the spec, random produces numbers always less than the > limit so it will never hit zero. And its a uniform distribution so you > haven't changed its statistical properties. > > Jeff Cunningham > Have you looked at a distribution of the outputs? I'm wondering if there's something else wrong. You really shouldn't see zero show up as an argument to log except once in a blue moon. It might be very small numbers will kill log also. If that's the case, then you could figure out the threshold for smallest argument to log, and put some logic in there to exclude those cases (regen another uniform variate). Jeff Cunningham 