Re: [GSoC] Mir.random.flex - Generic non-uniform random sampling
On Tuesday, 23 August 2016 at 12:12:30 UTC, Seb wrote: On Tuesday, 23 August 2016 at 11:58:53 UTC, tn wrote: On Monday, 22 August 2016 at 15:34:47 UTC, Seb wrote: http://blog.mir.dlang.io/random/2016/08/22/transformed-density-rejection-sampling.html What are the columns "mu time" and "sigma^2 time" of the benchmark table in the Sampling subsection? In statistics mu is often used to describe the average, sigma the standard deviation and sigma^2 the variance. It was absolutely unnecessary to use this notation here (especially because standard deviation, not variance was measured). I fixed that and also added how many samples were generated per run (10M), thanks! Thanks for the clarification and the fix. (I am familiar with the usage of mu and sigma, but somehow I first thought that the columns corresponded to two different measurements. After the initial confusion I realized the correct meaning, but still wasn't sure about it due to contradiction between the name of the column (sigma^2, not sigma) and the values (ms, not ms^2 or something). So I thought that it would be better to ask.) Another question: You mention that statistical quality is important, but it is not clear if flex has better or worse quality than Box-Muller and Ziggurat in the case of sampling from normal distribution. Or is the difference negligible? (I realize that the real strength of flex is its versatility.)
Re: [GSoC] Mir.random.flex - Generic non-uniform random sampling
On Monday, 22 August 2016 at 15:34:47 UTC, Seb wrote: http://blog.mir.dlang.io/random/2016/08/22/transformed-density-rejection-sampling.html What are the columns "mu time" and "sigma^2 time" of the benchmark table in the Sampling subsection?
Re: DUB 0.9.22 released
On Friday, 26 September 2014 at 06:29:21 UTC, Dragos Carp wrote: Though you could use prerelease and/or build suffixes (1.2.3-0w / 1.2.3+0w). These are very close to what I would like to see. Though, if I understand correctly, build suffix wouldn't work, as for example 1.2.3+0w and 1.2.3+1w would be treated as equal: Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. (semver.org) I guess that prerelease suffixes would do the trick. The only problem is conceptual: A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. (semver.org)
Re: DUB 0.9.22 released
On Tuesday, 23 September 2014 at 06:22:27 UTC, Jacob Carlborg wrote: On 22/09/14 23:04, tn wrote: What is the recommended way of versioning bindings? If the binding of the target library 1.2.3 is versioned as 1.2.3 and a bug is fixed in the binding (no change in the target library), how should the new version of the binding for target version 1.2.3 be versioned? Using 1.2.4 is not an option because it potentially collides with the binding for the next version of the target. The problem is locking the version of the Dub package to the same version of the library the bindings are for. In you're example I would do something like 1.2.3+1.2.3. If you need fix a bug in the bindings you increment as usual to 1.2.4+1.2.3. Anything after the plus sign is basically metadata that is ignore by Dub In your suggestion, once version 1.2.4 of the target library is released, the first binding version targeting that would then be 1.2.4+1.2.4 or 1.2.5+1.2.4 or what? And more importantly, how can a user of the binding then depend on the latest binding version of a specific target library version (for example the latest bindings for 1.2.3)?
Re: DUB 0.9.22 released
On Monday, 22 September 2014 at 09:33:52 UTC, Sönke Ludwig wrote: If you can think of any potentially important and especially backwards-incompatible changes/additions, please mention them (ideally as GitHub tickets), so that we can include them before the 1.0.0 release. What is the recommended way of versioning bindings? If the binding of the target library 1.2.3 is versioned as 1.2.3 and a bug is fixed in the binding (no change in the target library), how should the new version of the binding for target version 1.2.3 be versioned? Using 1.2.4 is not an option because it potentially collides with the binding for the next version of the target. Derelict [1] has solved this problem in a clever way, which allows leaving the least significant number for the binding [2][3]. Take for example the bindings for SDL [4]: Bindings for target version 2.0.1 are versioned as 1.1.0, 1.1.1, 1.1.2 and so on. Correspondingly, for target version 2.0.2, the binding versions are 1.2.0, 1.2.1 and so on. I guess, that for for target 2.1.0, the binging would be versioned 2.0.0, 2.0.1, and so on. I think that this is quite confusing. Is there a better way? [1] https://github.com/DerelictOrg [2] http://dblog.aldacron.net/derelict-help/using-derelict/ [3] http://dblog.aldacron.net/important-derelictsdl2-updates/ [4] http://code.dlang.org/packages/derelict-sdl2
