------=_Part_4835_1350853092.1464036149326
Content-Type: multipart/alternative;
 boundary="----=_Part_4836_288048766.1464036149326"

------=_Part_4836_288048766.1464036149326
Content-Type: text/plain; charset=UTF-8

Hi,

I've written a paper based on Melissa O'Neill's randutils.hpp
<https://gist.github.com/imneme/540829265469e673d045> (described here
<http://www.pcg-random.org/posts/ease-of-use-without-loss-of-power.html>),
proposing a simple wrapper class template for URNGs with various
convenience member functions and automatic nondeterministic seeding (for
random number engines):

https://github.com/timsong-cpp/stuff/blob/master/random_generator.md

Comments would be greatly appreciated.

Thanks,
Tim

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e8a6d787-83de-40e6-8f15-d5f5cd0e02f8%40isocpp.org.

------=_Part_4836_288048766.1464036149326
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><div><br></div><div>I&#39;ve written a paper=
 based on Melissa O&#39;Neill&#39;s<a href=3D"https://gist.github.com/imnem=
e/540829265469e673d045"> randutils.hpp</a> (described <a href=3D"http://www=
..pcg-random.org/posts/ease-of-use-without-loss-of-power.html">here</a>), pr=
oposing a simple wrapper class template for URNGs with various convenience =
member functions and automatic nondeterministic seeding (for random number =
engines):</div><div><br></div>https://github.com/timsong-cpp/stuff/blob/mas=
ter/random_generator.md<br><div><br></div><div>Comments would be greatly ap=
preciated.</div><div><br></div><div>Thanks,</div><div>Tim</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e8a6d787-83de-40e6-8f15-d5f5cd0e02f8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e8a6d787-83de-40e6-8f15-d5f5cd0e02f8=
%40isocpp.org</a>.<br />

------=_Part_4836_288048766.1464036149326--

------=_Part_4835_1350853092.1464036149326--

.

--001a1149dd5e1346ee053389214d
Content-Type: text/plain; charset=UTF-8

On Mon, May 23, 2016 at 1:42 PM, T. C. <rs2740@gmail.com> wrote:

> Hi,
>
> I've written a paper based on Melissa O'Neill's randutils.hpp
> <https://gist.github.com/imneme/540829265469e673d045> (described here
> <http://www.pcg-random.org/posts/ease-of-use-without-loss-of-power.html>),
> proposing a simple wrapper class template for URNGs with various
> convenience member functions and automatic nondeterministic seeding (for
> random number engines):
>
> https://github.com/timsong-cpp/stuff/blob/master/random_generator.md
>
> Comments would be greatly appreciated.
>

The new random algorithms here (choose, pick, ...) should be made available
as non-member functions that operate on URNGs, like sample and shuffle
already are -- it doesn't seem reasonable for these to exist in the
convenience wrapper but for the general case.

With that change made, the value of a separate class here is diminished.
Instead of

  std::random_generator<std::mt19937> rng; // nondeterministically seeded
  std::cout << rng.choose(some_list);

.... how would you feel about

  auto urng = std::seeded<std::mt19937>(); // returns a
nondeterministically seeded std::mt19937
  std::cout << choose(some_list, urng);

or similar?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3DJeZ6SQ41pt6GeHqOBJKQ_1NE91rmwL0qyc5Tdj31uGQ%40mail.gmail.com.

--001a1149dd5e1346ee053389214d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, May 23, 2016 at 1:42 PM, T. C. <span dir=3D"ltr">&lt;<a href=3D"mailto:=
rs2740@gmail.com" target=3D"_blank">rs2740@gmail.com</a>&gt;</span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:soli=
d;padding-left:1ex"><div dir=3D"ltr"><div>Hi,</div><div><br></div><div>I&#3=
9;ve written a paper based on Melissa O&#39;Neill&#39;s<a href=3D"https://g=
ist.github.com/imneme/540829265469e673d045" target=3D"_blank"> randutils.hp=
p</a> (described <a href=3D"http://www.pcg-random.org/posts/ease-of-use-wit=
hout-loss-of-power.html" target=3D"_blank">here</a>), proposing a simple wr=
apper class template for URNGs with various convenience member functions an=
d automatic nondeterministic seeding (for random number engines):</div><div=
><br></div><a href=3D"https://github.com/timsong-cpp/stuff/blob/master/rand=
om_generator.md" target=3D"_blank">https://github.com/timsong-cpp/stuff/blo=
b/master/random_generator.md</a><br><div><br></div><div>Comments would be g=
reatly appreciated.</div></div></blockquote><div><br></div><div>The new ran=
dom algorithms here (choose, pick, ...) should be made available as non-mem=
ber functions that operate on URNGs, like sample and shuffle already are --=
 it doesn&#39;t seem reasonable for these to exist in the convenience wrapp=
er but for the general case.</div><div><br></div><div>With that change made=
, the value of a separate class here is diminished. Instead of</div><div><b=
r></div><div>=C2=A0 std::random_generator&lt;std::mt19937&gt; rng; // nonde=
terministically seeded</div><div>=C2=A0 std::cout &lt;&lt; rng.choose(some_=
list);</div><div><br></div><div>... how would you feel about</div><div><br>=
</div><div><div>=C2=A0 auto urng =3D std::seeded&lt;std::mt19937&gt;(); // =
returns a nondeterministically seeded std::mt19937</div></div><div>=C2=A0 s=
td::cout &lt;&lt; choose(some_list, urng);</div><div><br></div><div>or simi=
lar?</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3DJeZ6SQ41pt6GeHqOBJKQ_1NE91r=
mwL0qyc5Tdj31uGQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3DJeZ6S=
Q41pt6GeHqOBJKQ_1NE91rmwL0qyc5Tdj31uGQ%40mail.gmail.com</a>.<br />

--001a1149dd5e1346ee053389214d--

.

------=_Part_1612_421723483.1464047131550
Content-Type: multipart/alternative;
 boundary="----=_Part_1613_2130670761.1464047131551"

------=_Part_1613_2130670761.1464047131551
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Monday, May 23, 2016 at 2:29:03 PM UTC-7, Richard Smith wrote:
>
> On Mon, May 23, 2016 at 1:42 PM, T. C. <rs2...@gmail.com <javascript:>>=
=20
> wrote:
>
>>
>> I've written a paper based on Melissa O'Neill's randutils.hpp=20
>> <https://gist.github.com/imneme/540829265469e673d045> (described here=20
>> <http://www.pcg-random.org/posts/ease-of-use-without-loss-of-power.html>=
),=20
>> proposing a simple wrapper class template for URNGs with various=20
>> convenience member functions and automatic nondeterministic seeding (for=
=20
>> random number engines):
>>
>> https://github.com/timsong-cpp/stuff/blob/master/random_generator.md
>>
>> Comments would be greatly appreciated.
>>
>
> The new random algorithms here (choose, pick, ...) should be made=20
> available as non-member functions that operate on URNGs, like sample and=
=20
> shuffle already are -- it doesn't seem reasonable for these to exist in t=
he=20
> convenience wrapper but [not] for the general case.
>
> With that change made, the value of a separate class here is diminished.=
=20
> Instead of
>
>   std::random_generator<std::mt19937> rng; // nondeterministically seeded
>   std::cout << rng.choose(some_list);
>
> ... how would you feel about
>
>   auto urng =3D std::seeded<std::mt19937>(); // returns a=20
> nondeterministically seeded std::mt19937
>   std::cout << choose(some_list, urng);
>

I was shocked to read in Tim's paper that C++1z currently requires some=20
variation on

// assuming that unsigned int is 32 bits
std::random_device rd;
std::seed_seq sseq {rd(), rd(), rd(), rd(), rd(), rd(), rd(), rd()};=20
std::mt19937 rng(sseq); // seeded with 256 bits of entropy from=20
random_device

I would have expected the following HYPOTHETICAL code to Do The Right Thing=
:

std::random_device rd;
std::mt19937 rng(rd);  // seeded with however much entropy it needs from=20
the provided random_device

(Notice that this is the "na=C3=AFve" code but with one pair of parentheses=
=20
removed.)
Does C++ really not allow that right now?  (Checked with Wandbox: it does=
=20
not.)
If C++ were amended to allow it, would a good chunk of the problem go away?=
=20
 Is there a good reason *not* to allow it?

I agree with Richard Smith's statement that the new algorithmic mechanisms=
=20
(pick, choose, uniform, shuffle, sample) should be proposed as plain old=20
library algorithms, *not* coupled tightly with the new seeding mechanism.

my $.02,
Arthur

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/d1c6b073-fcd8-4446-8cda-823236876720%40isocpp.or=
g.

------=_Part_1613_2130670761.1464047131551
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, May 23, 2016 at 2:29:03 PM UTC-7, Richard Smith=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><=
div class=3D"gmail_quote">On Mon, May 23, 2016 at 1:42 PM, T. C. <span dir=
=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"E9J8G9nlDQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;">rs2...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=
=3D"ltr"><div><br></div><div>I&#39;ve written a paper based on Melissa O&#3=
9;Neill&#39;s<a href=3D"https://gist.github.com/imneme/540829265469e673d045=
" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https:=
//www.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Fimneme%2F54082926=
5469e673d045\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF6RS5193dtcxe0-hcWaqox=
ZmvolA&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.google.co=
m/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Fimneme%2F540829265469e673d045\x2=
6sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF6RS5193dtcxe0-hcWaqoxZmvolA&#39;;ret=
urn true;"> randutils.hpp</a> (described <a href=3D"http://www.pcg-random.o=
rg/posts/ease-of-use-without-loss-of-power.html" target=3D"_blank" rel=3D"n=
ofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhtt=
p%3A%2F%2Fwww.pcg-random.org%2Fposts%2Fease-of-use-without-loss-of-power.ht=
ml\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG4LQiHXoMcO-a8jr4nndPIlcMOOg&#39=
;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x3d=
http%3A%2F%2Fwww.pcg-random.org%2Fposts%2Fease-of-use-without-loss-of-power=
..html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG4LQiHXoMcO-a8jr4nndPIlcMOOg&=
#39;;return true;">here</a>), proposing a simple wrapper class template for=
 URNGs with various convenience member functions and automatic nondetermini=
stic seeding (for random number engines):</div><div><br></div><a href=3D"ht=
tps://github.com/timsong-cpp/stuff/blob/master/random_generator.md" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.go=
ogle.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Ftimsong-cpp%2Fstuff%2Fblob%2Fm=
aster%2Frandom_generator.md\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEpfjRMu=
9tz7oo01VLhqcw_pUcpPg&#39;;return true;" onclick=3D"this.href=3D&#39;https:=
//www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Ftimsong-cpp%2Fstuff%2F=
blob%2Fmaster%2Frandom_generator.md\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjC=
NEpfjRMu9tz7oo01VLhqcw_pUcpPg&#39;;return true;">https://github.com/timsong=
-<wbr>cpp/stuff/blob/master/random_<wbr>generator.md</a><br><div><br></div>=
<div>Comments would be greatly appreciated.</div></div></blockquote><div><b=
r></div><div>The new random algorithms here (choose, pick, ...) should be m=
ade available as non-member functions that operate on URNGs, like sample an=
d shuffle already are -- it doesn&#39;t seem reasonable for these to exist =
in the convenience wrapper but [not] for the general case.</div><div><br></=
div><div>With that change made, the value of a separate class here is dimin=
ished. Instead of</div><div><br></div><div>=C2=A0 std::random_generator&lt;=
std::<wbr>mt19937&gt; rng; // nondeterministically seeded</div><div>=C2=A0 =
std::cout &lt;&lt; rng.choose(some_list);</div><div><br></div><div>... how =
would you feel about</div><div><br></div><div><div>=C2=A0 auto urng =3D std=
::seeded&lt;std::mt19937&gt;(); // returns a nondeterministically seeded st=
d::mt19937</div></div><div>=C2=A0 std::cout &lt;&lt; choose(some_list, urng=
);</div></div></div></div></blockquote><div><br></div><div>I was shocked to=
 read in Tim&#39;s paper that C++1z currently requires some variation on</d=
iv><div><br></div><div class=3D"prettyprint" style=3D"background-color: rgb=
(250, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: break-wor=
d;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #800;" class=3D"styled-by-prettify">// assuming that unsigned in=
t is 32 bits</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:=
:</span><span style=3D"color: #000;" class=3D"styled-by-prettify">random_de=
vice rd</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>std</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">seed_seq sseq </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">rd</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">(),</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> rd</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(),</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> rd</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">(),</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> rd</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(),=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> rd</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">(),</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> rd</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">(),</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> rd</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">(),</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> rd</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">()};</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> <br>std</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>mt19937 rng</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">sseq</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">// seeded with 256 bits of e=
ntropy from random_device</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span></div></code></div><div><br></div><div>I would ha=
ve expected the following HYPOTHETICAL code to Do The Right Thing:</div><di=
v><br></div><div class=3D"prettyprint" style=3D"background-color: rgb(250, =
250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: break-word;"><c=
ode class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">random_device rd</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br>std</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">mt19937 rng</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">rd</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> =C2=A0</span>=
<span style=3D"color: #800;" class=3D"styled-by-prettify">// seeded with ho=
wever much entropy it needs from the provided random_device</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></=
div><div><br>(Notice that this is the &quot;na=C3=AFve&quot; code but with =
one pair of parentheses removed.)</div><div>Does C++ really not allow that =
right now? =C2=A0(Checked with Wandbox: it does not.)</div><div>If C++ were=
 amended to allow it, would a good chunk of the problem go away? =C2=A0Is t=
here a good reason <i>not</i> to allow it?<br></div><div><br></div><div>I a=
gree with Richard Smith&#39;s statement that the new algorithmic mechanisms=
 (pick, choose, uniform, shuffle, sample) should be proposed as plain old l=
ibrary algorithms, <i>not</i> coupled tightly with the new seeding mechanis=
m.</div><div><br></div><div>my $.02,</div><div>Arthur</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d1c6b073-fcd8-4446-8cda-823236876720%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d1c6b073-fcd8-4446-8cda-823236876720=
%40isocpp.org</a>.<br />

------=_Part_1613_2130670761.1464047131551--

------=_Part_1612_421723483.1464047131550--

.

Richard Smith wrote:
> The new random algorithms here (choose, pick, ...) should be made availab=
le as non-member functions that operate on URNGs, like sample and shuffle a=
lready are -- it doesn't seem reasonable for these to exist in the convenie=
nce wrapper but for the general case.

FWIW, sample doesn't exist in the standard yet, it's a proposed addition.  =
When I wrote randutils it didn't exist.  So the only stand-alone function i=
n C++14 is shuffle, whose origins date back to random_shuffle (which predat=
es the C++11 <random> library and thus has a different flavor).  Thus pick,=
 choose, uniform, variate, and sample all don't exist right now.

To me there is a bit of a fork in the road here, let's look at the two fork=
s:

Option 1: Global functions, exemplified by the proposed sample algorithm, w=
hich take (optional) extra arguments to specify the engine.  To simply thin=
gs, there is a global state (actually per-thread) that holds some system-de=
fined random engine (i.e., the randint proposal).  But do you want a conste=
llation of thematically-related global helper functions (i.e., seeded, unif=
orm, variate, pick, choose, shuffle, and sample)?

Option 2: Random-generator objects, which tie together the <random> pieces =
but stay in the domain of object orientation.  There is far less reliance o=
n baked-in global state and only one new name in the std namespace.

The rest of the random number generation library is happy to use objects (e=
..g., the distributions, the engines, etc.), the second option retains the f=
lavor of the existing library while making it easier to use.=20

> ... how would you feel about
>=20
>   auto urng =3D std::seeded<std::mt19937>(); // returns a nondeterministi=
cally seeded std::mt19937
>   std::cout << choose(some_list, urng);

I don't like it.  I teach C++ (to smart people who already have some progra=
mming experience), and I don't want to to have to explain this.  If urng is=
 a std::mt19937, it looks like a band-aid around a design flaw (why doesn't=
 std::mt19937 know how to construct itself well in the first place? why doe=
s it need a helper function?  why doesn't it look like the rest of the rng =
library?).  And, did a std::mt19937 object get copied here?

If you presuppose that randint is a done deal and so is sample, then perhap=
s there isn't as much reason for this convenience class, but I don't think =
they are set in stone yet, and I think it's worthwhile to think through wha=
t really fits best with the random generation library we have.  In that vei=
n, it's shuffle that's the outlier.

The focus of this proposal is providing a tiny amount of glue to make all t=
he wonderful features of <random> actually easy to use.   There is pretty m=
uch no reason to provide pick as a helper function, or variate, or even sam=
ple, because they aren't really meaty *algorithms* at all, they're virtuall=
y one liners (choose is just a call to advance by an appropriate random amo=
unt, sample is just stable_partition with an appropriate random-based predi=
cate. etc.).   But there are a very good reasons to make these things somet=
hing a random-generator object can do, because it creates something cohesiv=
e.

Thoughts welcome,

    M.E.O.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/E197AA74-7F44-434C-B5E9-6DCC2FB12AF4%40cs.hmc.ed=
u.

.

------=_Part_1855_766157424.1464049420541
Content-Type: multipart/alternative;
 boundary="----=_Part_1856_936949258.1464049420541"

------=_Part_1856_936949258.1464049420541
Content-Type: text/plain; charset=UTF-8

On Monday, May 23, 2016 at 4:42:29 PM UTC-4, T. C. wrote:
>
> Hi,
>
> I've written a paper based on Melissa O'Neill's randutils.hpp
> <https://gist.github.com/imneme/540829265469e673d045> (described here
> <http://www.pcg-random.org/posts/ease-of-use-without-loss-of-power.html>),
> proposing a simple wrapper class template for URNGs with various
> convenience member functions and automatic nondeterministic seeding (for
> random number engines):
>
> https://github.com/timsong-cpp/stuff/blob/master/random_generator.md
>
> Comments would be greatly appreciated.
>
>
Be advised: there's already a proposal for improving the seeding of RNGs
<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0205r0.html>.

As for the idea, if you're interested in a do-everything RNG class, why
bother making the random number engine a template parameter? Why expose the
underlying engine at all?

That seems like an over-complication of the idea. If the goal is to be as
simple as Python, then just make it `random_generator`, and have
implementations decide on what the underlying engine is.

If you're serious about your random engine and distributions, about the
specific details of seeding and so forth, you're not going to use this
class. And if just want some randomness, then you *don't care* about the
details. You just want a quick, simple, braindead class that spits out
randomness in various ways upon request.

That being said, I see no reason why such a class needs member functions
for things we already have algorithms for (or will have, in the case of
range-generate). The sooner a C++ programmer is encouraged to look to
algorithms, the better. We may want to be as simple as Python, but we
should not pretend that C++ *is* Python.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5b72e2c8-e3af-446e-a286-b6f9d03a9cf4%40isocpp.org.

------=_Part_1856_936949258.1464049420541
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, May 23, 2016 at 4:42:29 PM UTC-4, T. C. wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Hi,</div>=
<div><br></div><div>I&#39;ve written a paper based on Melissa O&#39;Neill&#=
39;s<a href=3D"https://gist.github.com/imneme/540829265469e673d045" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.go=
ogle.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Fimneme%2F540829265469e673=
d045\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF6RS5193dtcxe0-hcWaqoxZmvolA&#=
39;;return true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\=
x3dhttps%3A%2F%2Fgist.github.com%2Fimneme%2F540829265469e673d045\x26sa\x3dD=
\x26sntz\x3d1\x26usg\x3dAFQjCNF6RS5193dtcxe0-hcWaqoxZmvolA&#39;;return true=
;"> randutils.hpp</a> (described <a href=3D"http://www.pcg-random.org/posts=
/ease-of-use-without-loss-of-power.html" target=3D"_blank" rel=3D"nofollow"=
 onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%=
2Fwww.pcg-random.org%2Fposts%2Fease-of-use-without-loss-of-power.html\x26sa=
\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG4LQiHXoMcO-a8jr4nndPIlcMOOg&#39;;return=
 true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%=
2F%2Fwww.pcg-random.org%2Fposts%2Fease-of-use-without-loss-of-power.html\x2=
6sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG4LQiHXoMcO-a8jr4nndPIlcMOOg&#39;;ret=
urn true;">here</a>), proposing a simple wrapper class template for URNGs w=
ith various convenience member functions and automatic nondeterministic see=
ding (for random number engines):</div><div><br></div><a href=3D"https://gi=
thub.com/timsong-cpp/stuff/blob/master/random_generator.md" target=3D"_blan=
k" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.com/=
url?q\x3dhttps%3A%2F%2Fgithub.com%2Ftimsong-cpp%2Fstuff%2Fblob%2Fmaster%2Fr=
andom_generator.md\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEpfjRMu9tz7oo01V=
Lhqcw_pUcpPg&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.goo=
gle.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Ftimsong-cpp%2Fstuff%2Fblob%2Fma=
ster%2Frandom_generator.md\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEpfjRMu9=
tz7oo01VLhqcw_pUcpPg&#39;;return true;">https://github.com/timsong-<wbr>cpp=
/stuff/blob/master/random_<wbr>generator.md</a><br><div><br></div><div>Comm=
ents would be greatly appreciated.</div><br></div></blockquote><div><br>Be =
advised: there&#39;s already a proposal for <a href=3D"http://www.open-std.=
org/JTC1/SC22/WG21/docs/papers/2016/p0205r0.html">improving the seeding of =
RNGs</a>.<br><br>As for the idea, if you&#39;re interested in a do-everythi=
ng RNG class, why bother making the random number engine a template paramet=
er? Why expose the underlying engine at all?<br><br>That seems like an over=
-complication of the idea. If the goal is to be as simple as Python, then j=
ust make it `random_generator`, and have implementations decide on what the=
 underlying engine is.<br><br>If you&#39;re serious about your random engin=
e and distributions, about the specific details of seeding and so forth, yo=
u&#39;re not going to use this class. And if just want some randomness, the=
n you <i>don&#39;t care</i> about the details. You just want a quick, simpl=
e, braindead class that spits out randomness in various ways upon request.<=
br><br>That being said, I see no reason why such a class needs member funct=
ions for things we already have algorithms for (or will have, in the case o=
f range-generate). The sooner a C++ programmer is encouraged to look to alg=
orithms, the better. We may want to be as simple as Python, but we should n=
ot pretend that C++ <i>is</i> Python.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5b72e2c8-e3af-446e-a286-b6f9d03a9cf4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5b72e2c8-e3af-446e-a286-b6f9d03a9cf4=
%40isocpp.org</a>.<br />

------=_Part_1856_936949258.1464049420541--

------=_Part_1855_766157424.1464049420541--

.

------=_Part_2381_1454160676.1464049925514
Content-Type: multipart/alternative;
 boundary="----=_Part_2382_256525655.1464049925514"

------=_Part_2382_256525655.1464049925514
Content-Type: text/plain; charset=UTF-8

Oh and a couple of other things about the proposal:

How do you implement `choose` with ForwardIterators? Does it involve
`std::distance` calling, so that it can determine how many items to choose
from?

What's the point of `pick`? Is it *really* that important to have a
function that does `*choose`?

ForwardIterators can't be subtracted. `sample`'s description seems to rely
on that. You probably meant `std::distance`.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ddcbb55e-bb0c-4730-8d91-d68434814b45%40isocpp.org.

------=_Part_2382_256525655.1464049925514
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Oh and a couple of other things about the proposal:<br><br=
>How do you implement `choose` with ForwardIterators? Does it involve `std:=
:distance` calling, so that it can determine how many items to choose from?=
<br><br>What&#39;s the point of `pick`? Is it *really* that important to ha=
ve a function that does `*choose`?<br><br>ForwardIterators can&#39;t be sub=
tracted. `sample`&#39;s description seems to rely on that. You probably mea=
nt `std::distance`.<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ddcbb55e-bb0c-4730-8d91-d68434814b45%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ddcbb55e-bb0c-4730-8d91-d68434814b45=
%40isocpp.org</a>.<br />

------=_Part_2382_256525655.1464049925514--

------=_Part_2381_1454160676.1464049925514--

.

------=_Part_2173_1692852240.1464051747373
Content-Type: multipart/alternative;
 boundary="----=_Part_2174_556197755.1464051747373"

------=_Part_2174_556197755.1464051747373
Content-Type: text/plain; charset=UTF-8

On Monday, May 23, 2016 at 7:48:09 PM UTC-4, M.E. O'Neill wrote:
>
> Richard Smith wrote:
> > The new random algorithms here (choose, pick, ...) should be made
> available as non-member functions that operate on URNGs, like sample and
> shuffle already are -- it doesn't seem reasonable for these to exist in the
> convenience wrapper but for the general case.
>
> FWIW, sample doesn't exist in the standard yet, it's a proposed addition.
>  When I wrote randutils it didn't exist.  So the only stand-alone function
> in C++14 is shuffle, whose origins date back to random_shuffle (which
> predates the C++11 <random> library and thus has a different flavor).  Thus
> pick, choose, uniform, variate, and sample all don't exist right now.
>
> To me there is a bit of a fork in the road here, let's look at the two
> forks:
>
> Option 1: Global functions, exemplified by the proposed sample algorithm,
> which take (optional) extra arguments to specify the engine.  To simply
> things, there is a global state (actually per-thread) that holds some
> system-defined random engine (i.e., the randint proposal).  But do you want
> a constellation of thematically-related global helper functions (i.e.,
> seeded, uniform, variate, pick, choose, shuffle, and sample)?
>

Have you not looked at Chapter 25 of the C++ Standard? That's how we do
things in C++.

`uniform` is not a function that should be an algorithm. If you have an
engine, and you want to get a uniform value in a range, we have a whole
class for that. Seeding likewise is being looked into for an overhaul.
`variate` is not something we need as an algorithm. And `pick` is rather
silly.

But the rest... why not make them algorithms? There's absolutely nothing to
be lost by providing these as global functions that *any* RNG engine can be
used with. It would be extremely silly to see people wrap an RNG engine in
one of these classes for the sole purpose of making use of these algorithms.

And yet, if you don't offer them the obvious choice of a `std` algorithm,
they *will* do it.

And no, we don't need "global state (actually per-thread) that holds some
system-defined random engine (i.e., the randint proposal)". That's a *horrible
idea*. As far as I'm concerned, I have no problem with saying that *all*
C++ random functions must be provided an engine by the user.


> Option 2: Random-generator objects, which tie together the <random> pieces
> but stay in the domain of object orientation.  There is far less reliance
> on baked-in global state and only one new name in the std namespace.
>

Names in the `std` namespace are not at a premium. They're not going
anywhere. And as previously stated, we need no "baked-in global state".

The rest of the random number generation library is happy to use objects
> (e.g., the distributions, the engines, etc.), the second option retains the
> flavor of the existing library while making it easier to use.
>
> > ... how would you feel about
> >
> >   auto urng = std::seeded<std::mt19937>(); // returns a
> nondeterministically seeded std::mt19937
> >   std::cout << choose(some_list, urng);
>
> I don't like it.  I teach C++ (to smart people who already have some
> programming experience), and I don't want to to have to explain this.  If
> urng is a std::mt19937, it looks like a band-aid around a design flaw (why
> doesn't std::mt19937 know how to construct itself well in the first place?


Because "construct itself well" is a matter of opinion, so we require users
to be specific about how it gets built.


> why does it need a helper function?


Your students must *hate* `make_shared` and `make_unique`...

 why doesn't it look like the rest of the rng library?).  And, did a
> std::mt19937 object get copied here?
>

If you haven't told them about how move semantics and copy elision works
yet, then that's not a question they ought to be concerned about yet.

If you presuppose that randint is a done deal and so is sample, then
> perhaps there isn't as much reason for this convenience class, but I don't
> think they are set in stone yet, and I think it's worthwhile to think
> through what really fits best with the random generation library we have.
>  In that vein, it's shuffle that's the outlier.
>
> The focus of this proposal is providing a tiny amount of glue to make all
> the wonderful features of <random> actually easy to use.   There is pretty
> much no reason to provide pick as a helper function, or variate, or even
> sample, because they aren't really meaty *algorithms* at all, they're
> virtually one liners (choose is just a call to advance by an appropriate
> random amount, sample is just stable_partition with an appropriate
> random-based predicate. etc.).


`std::generate` is not exactly "meaty" either; neither are `for_each` and
many more. We add these things because they're repeatedly used, convenient,
and potentially bug-prone. Not because they're hard to write.

Also, it should be noted that writing an efficient `choose` for
non-RandomAccessIterators very much is tricky. You *don't* want to call
`std::distance` on the range, so it'd be best to find a different way. And
that can be complicated.

But there are a very good reasons to make these things something a
> random-generator object can do, because it creates something cohesive.
>

No, they should not.

I should not have to implement `choose` for every single RNG engine I
write. The purpose of an RNG engine is to produce randomness; `choose` is
about how you *use* randomness.

Just like the purpose of a `vector` is to store and manage elements. `sort`
is about the order of those elements, without affecting the storage or
management of them. One is a class, the other an algorithm.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9afb9271-cc52-49b5-8717-36ac701e7849%40isocpp.org.

------=_Part_2174_556197755.1464051747373
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, May 23, 2016 at 7:48:09 PM UTC-4, M.E. O&#39;Ne=
ill wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Richard Smith wrote:
<br>&gt; The new random algorithms here (choose, pick, ...) should be made =
available as non-member functions that operate on URNGs, like sample and sh=
uffle already are -- it doesn&#39;t seem reasonable for these to exist in t=
he convenience wrapper but for the general case.
<br>
<br>FWIW, sample doesn&#39;t exist in the standard yet, it&#39;s a proposed=
 addition. =C2=A0When I wrote randutils it didn&#39;t exist. =C2=A0So the o=
nly stand-alone function in C++14 is shuffle, whose origins date back to ra=
ndom_shuffle (which predates the C++11 &lt;random&gt; library and thus has =
a different flavor). =C2=A0Thus pick, choose, uniform, variate, and sample =
all don&#39;t exist right now.
<br>
<br>To me there is a bit of a fork in the road here, let&#39;s look at the =
two forks:
<br>
<br>Option 1: Global functions, exemplified by the proposed sample algorith=
m, which take (optional) extra arguments to specify the engine. =C2=A0To si=
mply things, there is a global state (actually per-thread) that holds some =
system-defined random engine (i.e., the randint proposal). =C2=A0But do you=
 want a constellation of thematically-related global helper functions (i.e.=
, seeded, uniform, variate, pick, choose, shuffle, and sample)?
<br></blockquote><div><br>Have you not looked at Chapter 25 of the C++ Stan=
dard? That&#39;s how we do things in C++.<br><br>`uniform` is not a functio=
n that should be an algorithm. If you have an engine, and you want to get a=
 uniform value in a range, we have a whole class for that. Seeding likewise=
 is being looked into for an overhaul. `variate` is not something we need a=
s an algorithm. And `pick` is rather silly.<br><br>But the rest... why not =
make them algorithms? There&#39;s absolutely nothing to be lost by providin=
g these as global functions that <i>any</i> RNG engine can be used with. It=
 would be extremely silly to see people wrap an RNG engine in one of these =
classes for the sole purpose of making use of these algorithms.<br><br>And =
yet, if you don&#39;t offer them the obvious choice of a `std` algorithm, t=
hey <i>will</i> do it.<br><br>And no, we don&#39;t need &quot;global state =
(actually per-thread) that holds some system-defined random engine (i.e., t=
he randint proposal)&quot;. That&#39;s a <i>horrible idea</i>. As far as I&=
#39;m concerned, I have no problem with saying that <i>all</i> C++ random f=
unctions must be provided an engine by the user.<br>=C2=A0</div><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;">
Option 2: Random-generator objects, which tie together the &lt;random&gt; p=
ieces but stay in the domain of object orientation. =C2=A0There is far less=
 reliance on baked-in global state and only one new name in the std namespa=
ce.<br></blockquote><div><br>Names in the `std` namespace are not at a prem=
ium. They&#39;re not going anywhere. And as previously stated, we need no &=
quot;baked-in global state&quot;.<br><br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;">
The rest of the random number generation library is happy to use objects (e=
..g., the distributions, the engines, etc.), the second option retains the f=
lavor of the existing library while making it easier to use.=20
<br>
<br>&gt; ... how would you feel about
<br>&gt;=20
<br>&gt; =C2=A0 auto urng =3D std::seeded&lt;std::mt19937&gt;(); // returns=
 a nondeterministically seeded std::mt19937
<br>&gt; =C2=A0 std::cout &lt;&lt; choose(some_list, urng);
<br>
<br>I don&#39;t like it. =C2=A0I teach C++ (to smart people who already hav=
e some programming experience), and I don&#39;t want to to have to explain =
this. =C2=A0If urng is a std::mt19937, it looks like a band-aid around a de=
sign flaw (why doesn&#39;t std::mt19937 know how to construct itself well i=
n the first place?</blockquote><div><br>Because &quot;construct itself well=
&quot; is a matter of opinion, so we require users to be specific about how=
 it gets built.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
> why does it need a helper function?</blockquote><div><br>Your students mu=
st <i>hate</i> `make_shared` and `make_unique`...<br><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"> =C2=A0why doesn&#39;t it look like the re=
st of the rng library?). =C2=A0And, did a std::mt19937 object get copied he=
re?<br></blockquote><div><br>If you haven&#39;t told them about how move se=
mantics and copy elision works yet, then that&#39;s not a question they oug=
ht to be concerned about yet.<br><br></div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;">
If you presuppose that randint is a done deal and so is sample, then perhap=
s there isn&#39;t as much reason for this convenience class, but I don&#39;=
t think they are set in stone yet, and I think it&#39;s worthwhile to think=
 through what really fits best with the random generation library we have. =
=C2=A0In that vein, it&#39;s shuffle that&#39;s the outlier.
<br>
<br>The focus of this proposal is providing a tiny amount of glue to make a=
ll the wonderful features of &lt;random&gt; actually easy to use. =C2=A0 Th=
ere is pretty much no reason to provide pick as a helper function, or varia=
te, or even sample, because they aren&#39;t really meaty *algorithms* at al=
l, they&#39;re virtually one liners (choose is just a call to advance by an=
 appropriate random amount, sample is just stable_partition with an appropr=
iate random-based predicate. etc.).</blockquote><div><br>`std::generate` is=
 not exactly &quot;meaty&quot; either; neither are `for_each` and many more=
.. We add these things because they&#39;re repeatedly used, convenient, and =
potentially bug-prone. Not because they&#39;re hard to write.<br><br>Also, =
it should be noted that writing an efficient `choose` for non-RandomAccessI=
terators very much is tricky. You <i>don&#39;t</i> want to call `std::dista=
nce` on the range, so it&#39;d be best to find a different way. And that ca=
n be complicated.<br><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
>But there are a very good reasons to make these things something a random-=
generator object can do, because it creates something cohesive.<br></blockq=
uote><div><br>No, they should not.<br><br>I should not have to implement `c=
hoose` for every single RNG engine I write. The purpose of an RNG engine is=
 to produce randomness; `choose` is about how you <i>use</i> randomness.<br=
><br>Just like the purpose of a `vector` is to store and manage elements. `=
sort` is about the order of those elements, without affecting the storage o=
r management of them. One is a class, the other an algorithm.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9afb9271-cc52-49b5-8717-36ac701e7849%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9afb9271-cc52-49b5-8717-36ac701e7849=
%40isocpp.org</a>.<br />

------=_Part_2174_556197755.1464051747373--

------=_Part_2173_1692852240.1464051747373--

.

Nicol Bolas wrote (across three messages):
> Be advised: there's already a proposal for improving the seeding of RNGs.

That's good to know.  (One issue with encouraging std::random_device though=
 is that std::random_device is not currently required to be in any way nond=
eterministic.  It is allowed to produce the same output on every run of the=
 program.)

> As for the idea, if you're interested in a do-everything RNG class, why b=
other making the random number engine a template parameter? Why expose the =
underlying engine at all?

Although it's not part of this proposal draft, in my original version I did=
 provide some typedefs for common generators precisely so that people didn'=
t need to specify an engine as a parameter.

> That seems like an over-complication of the idea. If the goal is to be as=
 simple as Python, then just make it `random_generator`, and have implement=
ations decide on what the underlying engine is.
>=20
> If you're serious about your random engine and distributions, about the s=
pecific details of seeding and so forth, you're not going to use this class=
.. And if just want some randomness, then you don't care about the details. =
You just want a quick, simple, braindead class that spits out randomness in=
 various ways upon request.

The whole point of this proposal is that it enhances rather than subverts t=
he library we have.  Consider this code:

 mt19937_gen rng;
 double x =3D rng.variate<std::normal_distribution<double>>(17,3);

it's using the beauty of the library we have while being much easer to use.

The key idea is that it's easy enough for a beginner, but still handy for a=
n expert, and provides a good stepping stone to the facilities that still e=
xist.  It's not a dumbing down, it's handy glue to avoid annoying and error=
-prone boilerplate, boilerplate that's confusing to beginners and a hassle =
for experts.

> That being said, I see no reason why such a class needs member functions =
for things we already have algorithms for (or will have, in the case of ran=
ge-generate). The sooner a C++ programmer is encouraged to look to algorith=
ms, the better. We may want to be as simple as Python, but we should not pr=
etend that C++ is Python.

As I said above and in another post, it's best to see this class as very he=
lpful glue to provide something cohesive.

> `uniform` is not a function that should be an algorithm. If you have an e=
ngine, and you want to get a uniform value in a range, we have a whole clas=
s for that. Seeding likewise is being looked into for an overhaul. `variate=
` is not something we need as an algorithm.=20

EXACTLY!  You hit the nail on the head.  These are *NOT* algorithms.  They =
are far too simple.  They are in fact, basically trivial, they just call ou=
t to the classes that we already have, that's the point.  It's about ease o=
f use.

My claim is that people don't use the distribution classes because producin=
g a number in the range [0,9] by saying:

 std::uniform_int_distribution mydist(0,9)
 std::cout << mydist(myengine);

feels cumbersome to a lot of people to the point that people would rather w=
rite myengine() % 10 instead.  That's also one reason why randint got propo=
sed.

> What's the point of `pick`? Is it *really* that important to have a funct=
ion that does `*choose`?

Pick is passed a container and gives you an element, because it always give=
s you an element it makes no sense to return an iterator.  Choose is passed=
 two iterators and gives you an iterator.

But yes, pick is trivially implemented as *choose, much as a[i] is triviall=
y *(a+i) and front() and back() on containers are trivial (e.g., foo.front(=
) is *(foo.begin())).

> How do you implement `choose` with ForwardIterators? Does it involve `std=
::distance` calling, so that it can determine how many items to choose from=
?

Yes.  With a ForwardIterator it'll be O(n) but it would be O(n) expected an=
yway.

> ForwardIterators can't be subtracted. `sample`'s description seems to rel=
y on that. You probably meant `std::distance`.

Yes, my implementation actually uses std::distance; when Tim turned it into=
 a proposal, I think he tried to simplify the description but this wasn't a=
 valid simplification.  Good catch, thanks.


If there is one takeaway here, the point of this class was not to do anythi=
ng fundamentally new (although it did have to work around the current broke=
nness in seeding), but to make the facilities we already have easy to use r=
ight for beginners and experts alike.   The fact that the randint proposal =
exists is proof enough that as things stand right now is *NOT* good enough =
in that regard.

Best regards,

    M.E.O.


--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/BD8932D6-6956-4E58-B717-48AB9A65B8A7%40cs.hmc.ed=
u.

.

------=_Part_2_193682611.1464054340777
Content-Type: multipart/alternative;
 boundary="----=_Part_3_1836390082.1464054340777"

------=_Part_3_1836390082.1464054340777
Content-Type: text/plain; charset=UTF-8



On Monday, May 23, 2016 at 9:24:02 PM UTC-4, M.E. O'Neill wrote:
>
>
> > ForwardIterators can't be subtracted. `sample`'s description seems to
> rely on that. You probably meant `std::distance`.
>
> Yes, my implementation actually uses std::distance; when Tim turned it
> into a proposal, I think he tried to simplify the description but this
> wasn't a valid simplification.  Good catch, thanks.
>

Actually, there's blanket wording in [algorithms.general]/12 that defines +
and - for non-random-access iterators for specification purposes. I should
have added a cross reference.

That said, we have the RNG-taking version of sample in the working draft
now; it may make more sense to accept an output iterator and/or return a
container instead of rearranging the range in place. Then I can just define
the behavior with the "equivalent to" magic word used elsewhere.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/99071d54-dd59-425a-809e-783b195a54d9%40isocpp.org.

------=_Part_3_1836390082.1464054340777
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, May 23, 2016 at 9:24:02 PM UTC-4, M.E. =
O&#39;Neill wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>&gt; For=
wardIterators can&#39;t be subtracted. `sample`&#39;s description seems to =
rely on that. You probably meant `std::distance`.
<br>
<br>Yes, my implementation actually uses std::distance; when Tim turned it =
into a proposal, I think he tried to simplify the description but this wasn=
&#39;t a valid simplification. =C2=A0Good catch, thanks.
<br></blockquote><div><br></div><div>Actually, there&#39;s blanket wording =
in [algorithms.general]/12 that defines + and - for non-random-access itera=
tors for specification purposes. I should have added a cross reference.</di=
v><div><br></div><div>That said, we have the RNG-taking version of sample i=
n the working draft now; it may make more sense to accept an output iterato=
r and/or return a container instead of rearranging the range in place. Then=
 I can just define the behavior with the &quot;equivalent to&quot; magic wo=
rd used elsewhere.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/99071d54-dd59-425a-809e-783b195a54d9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/99071d54-dd59-425a-809e-783b195a54d9=
%40isocpp.org</a>.<br />

------=_Part_3_1836390082.1464054340777--

------=_Part_2_193682611.1464054340777--

.

On Mon, May 23, 2016 at 8:24 PM, M.E. O'Neill <oneill@cs.hmc.edu> wrote:
>
>
> The whole point of this proposal is that it enhances rather than subverts=
 the library we have.  Consider this code:
>
>         mt19937_gen rng;
>         double x =3D rng.variate<std::normal_distribution<double>>(17,3);
>
> it's using the beauty of the library we have while being much easer to us=
e.
>

I'm seeing a problem with this code.  std::normal_distribution
caches results, so does other distributions internally using it.
But here it looks like that a normal_distribution object will be
created for each run of `variate`, wasting both CPU cycles and
bits from the engine.

I would suggest to remove `variate`.

`uniform` is fine because those two distributions do not cache,
albeit theoretically they could.

And I don't like the interface to forward params for
construction.  It doesn't save typing, and breaks the
information about the distribution into two sides of the
expression:

  g.generate<std::normal_distribution>(first, last, 0.5);

An optional argument for distribution will do the work:

  g.generate(std::normal_distribution(0.5), first, last);

>> That being said, I see no reason why such a class needs member functions=
 for things we already have algorithms for (or will have, in the case of ra=
nge-generate). The sooner a C++ programmer is encouraged to look to algorit=
hms, the better. We may want to be as simple as Python, but we should not p=
retend that C++ is Python.

OT: I would be happy to see a utility which is really as simple
as Python, meaning type-erased the engines and allow
assigning from any engines.  Actually I tried modifying Melissa's
code to experiment this idea and it just works :)

--=20
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://blog.miator.net/

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAGsORuCdttrGsDOTURqxwV5u5NOjBXVL7ysnYQKgBZWk19i=
8jw%40mail.gmail.com.

.

--001a113fc41a6720730533948f50
Content-Type: text/plain; charset=UTF-8

On Mon, May 23, 2016 at 10:42 PM, T. C. <rs2740@gmail.com> wrote:

> Hi,
>
> I've written a paper based on Melissa O'Neill's randutils.hpp
> <https://gist.github.com/imneme/540829265469e673d045> (described here
> <http://www.pcg-random.org/posts/ease-of-use-without-loss-of-power.html>),
> proposing a simple wrapper class template for URNGs with various
> convenience member functions and automatic nondeterministic seeding (for
> random number engines):
>
> https://github.com/timsong-cpp/stuff/blob/master/random_generator.md
>

Adding to what the others have said.

This proposal tries to address two related but different issues.

1. Correct use of random facilities (to obtain good quality random numbers).

2. Easy use of random facilities.

Part one is mostly about seeding PRNGs. It has already been said that there
is a proposal addressing just that, and, I think, it is something that we
definitely need *regardless of* #2.

But, in the context of #2, I take issue with the very motivation in your
proposal. It assumes that the user is *both* naive* and* technical enough
to bother specifying the Mersenne Twister PRNG. This seems somewhat
schizophrenic to me. Why would the naive user even want to have all the
complexity of using a PRNG seeded by a (hopefully) non-deterministic RNG?
Why would the naive user not write something like:

std::random_device rng; for (int i = 2; i <= 27; ++i) std::cout << "\t" <<
std::uniform_int_distribution<>(1, i)(rng) << std::endl;


And if the user is technical enough to have valid reasons *not* to use
std::random_device
in that way, then, as said earlier, the technical user needs a better way
to use the random_device as a good seed generator, but that need not be
coupled with #2 at this point.

Cheers,
V.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3EGHM80tePCMXKXTtYkz6xmAJyWmFVPjwi72R1Ltuvcg%40mail.gmail.com.

--001a113fc41a6720730533948f50
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, May 23, 2016 at 10:42 PM, T. C. <span dir=3D"ltr">&lt;<a href=3D"mailto=
:rs2740@gmail.com" target=3D"_blank">rs2740@gmail.com</a>&gt;</span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,20=
4);padding-left:1ex"><div dir=3D"ltr"><div>Hi,</div><div><br></div><div>I&#=
39;ve written a paper based on Melissa O&#39;Neill&#39;s<a href=3D"https://=
gist.github.com/imneme/540829265469e673d045" target=3D"_blank"> randutils.h=
pp</a> (described <a href=3D"http://www.pcg-random.org/posts/ease-of-use-wi=
thout-loss-of-power.html" target=3D"_blank">here</a>), proposing a simple w=
rapper class template for URNGs with various convenience member functions a=
nd automatic nondeterministic seeding (for random number engines):</div><di=
v><br></div><a href=3D"https://github.com/timsong-cpp/stuff/blob/master/ran=
dom_generator.md" target=3D"_blank">https://github.com/timsong-cpp/stuff/bl=
ob/master/random_generator.md</a></div></blockquote><div><br></div><div>Add=
ing to what the others have said.</div><div><br></div><div>This proposal tr=
ies to address two related but different issues.</div><div><br></div><div>1=
.. Correct use of random facilities (to obtain good quality random numbers).=
</div><div><br></div><div>2. Easy use of random facilities.</div><div><br><=
/div><div>Part one is mostly about seeding PRNGs. It has already been said =
that there is a proposal addressing just that, and, I think, it is somethin=
g that we definitely need <i>regardless of</i>=C2=A0#2.</div><div><br></div=
><div>But, in the context of #2, I take issue with the very motivation in y=
our proposal. It assumes that the user is <i>both</i>=C2=A0naive<i>=C2=A0an=
d</i>=C2=A0technical enough to bother specifying the Mersenne Twister PRNG.=
 This seems somewhat schizophrenic to me. Why would the naive user even wan=
t to have all the complexity of using a PRNG seeded by a (hopefully) non-de=
terministic RNG? Why would the naive user not write something like:</div><d=
iv><br></div><div><span style=3D"white-space:pre">std::random_device rng;
for (int i =3D 2; i &lt;=3D 27; ++i)
 std::cout &lt;&lt; &quot;\t&quot; &lt;&lt; std::uniform_int_distribution&l=
t;&gt;(1, i)(rng) &lt;&lt; std::endl;</span>=C2=A0<div><br></div><div><br><=
/div><div>And if the user is technical enough to have valid reasons <i>not<=
/i>=C2=A0to use=C2=A0<span style=3D"white-space:pre">std::random_device in =
that way</span>, then, as said earlier, the technical user needs a better w=
ay to use the random_device as a good seed generator, but that need not=C2=
=A0be coupled with #2 at this point.<br></div></div><div><br></div><div>Che=
ers,<br></div><div>V.</div><div><br></div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3EGHM80tePCMXKXTtYkz6xmAJyWmFV=
Pjwi72R1Ltuvcg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3EGHM80teP=
CMXKXTtYkz6xmAJyWmFVPjwi72R1Ltuvcg%40mail.gmail.com</a>.<br />

--001a113fc41a6720730533948f50--

.

------=_Part_3591_1845859615.1464111137786
Content-Type: multipart/alternative;
 boundary="----=_Part_3592_1769423851.1464111137787"

------=_Part_3592_1769423851.1464111137787
Content-Type: text/plain; charset=UTF-8



On Monday, May 23, 2016 at 9:24:02 PM UTC-4, M.E. O'Neill wrote:
>
> Nicol Bolas wrote (across three messages):
> > Be advised: there's already a proposal for improving the seeding of
> RNGs.
>
> That's good to know.  (One issue with encouraging std::random_device
> though is that std::random_device is not currently required to be in any
> way nondeterministic.  It is allowed to produce the same output on every
> run of the program.)
>

The reason for that is so that implementation of C++ are not *required* to
have access to the ability to produce non-deterministic random numbers.
Because some of them simply can't do that.

If an implementation doesn't implement `random_device`
non-deterministically, there's no reason to expect it to be able to do so
for your class either.


>
> > As for the idea, if you're interested in a do-everything RNG class, why
> bother making the random number engine a template parameter? Why expose the
> underlying engine at all?
>
> Although it's not part of this proposal draft, in my original version I
> did provide some typedefs for common generators precisely so that people
> didn't need to specify an engine as a parameter.
>
> > That seems like an over-complication of the idea. If the goal is to be
> as simple as Python, then just make it `random_generator`, and have
> implementations decide on what the underlying engine is.
> >
> > If you're serious about your random engine and distributions, about the
> specific details of seeding and so forth, you're not going to use this
> class. And if just want some randomness, then you don't care about the
> details. You just want a quick, simple, braindead class that spits out
> randomness in various ways upon request.
>
> The whole point of this proposal is that it enhances rather than subverts
> the library we have.  Consider this code:
>
>         mt19937_gen rng;
>         double x = rng.variate<std::normal_distribution<double>>(17,3);
>
> it's using the beauty of the library we have while being much easer to
> use.
>

>
The key idea is that it's easy enough for a beginner, but still handy for
> an expert, and provides a good stepping stone to the facilities that still
> exist.  It's not a dumbing down, it's handy glue to avoid annoying and
> error-prone boilerplate, boilerplate that's confusing to beginners and a
> hassle for experts.
>

And how is that any easier than:

mt19937 rng(/*seed*/);
double x = std::normal_distribution<double>(17, 3)(rng);

I see no reason why a beginner would be unable to write that, but able to
write your `variate` version. The *only* difference between them is that
it's a member function, rather than directly creating an external class.
You still have to type `normal_distribution<typename>`, so the user still
must know that this class exists. You still have to provide the RNG, so you
still must know that your rng object exists. And so forth.

Your version reads "random generator, select from, normal distribution,
with distribution params". The current version reads "normal distribution,
with distribution params, select from, random generator". I don't see that
yours reads any better than the other.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d41a8135-ce11-48b0-9ba6-a03f4321ed53%40isocpp.org.

------=_Part_3592_1769423851.1464111137787
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, May 23, 2016 at 9:24:02 PM UTC-4, M.E. =
O&#39;Neill wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Nicol Bolas =
wrote (across three messages):
<br>&gt; Be advised: there&#39;s already a proposal for improving the seedi=
ng of RNGs.
<br>
<br>That&#39;s good to know. =C2=A0(One issue with encouraging std::random_=
device though is that std::random_device is not currently required to be in=
 any way nondeterministic. =C2=A0It is allowed to produce the same output o=
n every run of the program.)<br></blockquote><div><br>The reason for that i=
s so that implementation of C++ are not <i>required</i> to have access to t=
he ability to produce non-deterministic random numbers. Because some of the=
m simply can&#39;t do that.<br><br>If an implementation doesn&#39;t impleme=
nt `random_device` non-deterministically, there&#39;s no reason to expect i=
t to be able to do so for your class either.<br>=C2=A0</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;">
<br>&gt; As for the idea, if you&#39;re interested in a do-everything RNG c=
lass, why bother making the random number engine a template parameter? Why =
expose the underlying engine at all?
<br>
<br>Although it&#39;s not part of this proposal draft, in my original versi=
on I did provide some typedefs for common generators precisely so that peop=
le didn&#39;t need to specify an engine as a parameter.
<br>
<br>&gt; That seems like an over-complication of the idea. If the goal is t=
o be as simple as Python, then just make it `random_generator`, and have im=
plementations decide on what the underlying engine is.
<br>&gt;=20
<br>&gt; If you&#39;re serious about your random engine and distributions, =
about the specific details of seeding and so forth, you&#39;re not going to=
 use this class. And if just want some randomness, then you don&#39;t care =
about the details. You just want a quick, simple, braindead class that spit=
s out randomness in various ways upon request.
<br>
<br>The whole point of this proposal is that it enhances rather than subver=
ts the library we have. =C2=A0Consider this code:
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0mt19937_gen rng;
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0double x =3D rng.variat=
e&lt;std::normal_<wbr>distribution&lt;double&gt;&gt;(17,3);
<br>
<br>it&#39;s using the beauty of the library we have while being much easer=
 to use.
<br></blockquote><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-lef=
t: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">=
<div>=C2=A0</div></blockquote><blockquote style=3D"margin: 0px 0px 0px 0.8e=
x; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"=
gmail_quote"><div>The key idea is that it&#39;s easy enough for a beginner,=
 but still handy=20
for an expert, and provides a good stepping stone to the facilities that
 still exist. =C2=A0It&#39;s not a dumbing down, it&#39;s handy glue to avo=
id=20
annoying and error-prone boilerplate, boilerplate that&#39;s confusing to=
=20
beginners and a hassle for experts.=C2=A0
<br></div></blockquote><div><br>And how is that any easier than:<br><br><di=
v class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bord=
er-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-=
wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint=
"><span style=3D"color: #000;" class=3D"styled-by-prettify">mt19937 rng</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #800;" class=3D"styled-by-prettify">/*seed*/</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">double</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> x </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">normal_distribution</span><span style=3D"color: #080;" class=3D"styled-=
by-prettify">&lt;double&gt;</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(</span><span style=3D"color: #066;" class=3D"styled-by-pr=
ettify">17</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #066;" class=3D"styled-by-prettify">3</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">)(</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">rng</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">);</span></div></code></div><br>I see no r=
eason why a beginner would be unable to write that, but able to write your =
`variate` version. The <i>only</i> difference between them is that it&#39;s=
 a member function, rather than directly creating an external class. You st=
ill have to type `normal_distribution&lt;typename&gt;`, so the user still m=
ust know that this class exists. You still have to provide the RNG, so you =
still must know that your rng object exists. And so forth.<br><br>Your vers=
ion reads &quot;random generator, select from, normal distribution, with di=
stribution params&quot;. The current version reads &quot;normal distributio=
n, with distribution params, select from, random generator&quot;. I don&#39=
;t see that yours reads any better than the other.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d41a8135-ce11-48b0-9ba6-a03f4321ed53%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d41a8135-ce11-48b0-9ba6-a03f4321ed53=
%40isocpp.org</a>.<br />

------=_Part_3592_1769423851.1464111137787--

------=_Part_3591_1845859615.1464111137786--

.

--089e013d0deedbca4805339a2ad3
Content-Type: text/plain; charset=UTF-8

On Mon, May 23, 2016 at 11:38 PM, Zhihao Yuan <zy@miator.net> wrote:

> On Mon, May 23, 2016 at 8:24 PM, M.E. O'Neill <oneill@cs.hmc.edu> wrote:
> >
> >
> > The whole point of this proposal is that it enhances rather than
> subverts the library we have.  Consider this code:
> >
> >         mt19937_gen rng;
> >         double x = rng.variate<std::normal_distribution<double>>(17,3);
> >
> > it's using the beauty of the library we have while being much easer to
> use.
> >
>
> I'm seeing a problem with this code.  std::normal_distribution
> caches results, so does other distributions internally using it.
> But here it looks like that a normal_distribution object will be
> created for each run of `variate`, wasting both CPU cycles and
> bits from the engine.
>

I think that's fine. It's true that folks wanting to get the last ounce of
performance will need to store a distribution object and re-use it, but we
can provide the convenient spelling for folks who don't need that. I
believe it doesn't even cost that much in the grand scheme of things: it's
on the order of a couple extra generated numbers, which is generally less
than the cost of a memory allocation, right?

We do similar things when we write functions to return vectors instead of
taking pre-allocated storage as an argument.

Jeffrey

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXk95fvQMS%2B7WaNUoaDuguWb6OhdDf3k9V%2BRyhEpyhjUaw%40mail.gmail.com.

--089e013d0deedbca4805339a2ad3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, May 23, 2016 at 11:38 PM, Zhihao Yuan <span dir=3D"ltr">&lt;<a href=3D"=
mailto:zy@miator.net" target=3D"_blank" class=3D"cremed">zy@miator.net</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Mon=
, May 23, 2016 at 8:24 PM, M.E. O&#39;Neill &lt;<a href=3D"mailto:oneill@cs=
..hmc.edu" class=3D"cremed">oneill@cs.hmc.edu</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; The whole point of this proposal is that it enhances rather than subve=
rts the library we have.=C2=A0 Consider this code:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mt19937_gen rng;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0double x =3D rng.variate&lt;std::norm=
al_distribution&lt;double&gt;&gt;(17,3);<br>
&gt;<br>
&gt; it&#39;s using the beauty of the library we have while being much ease=
r to use.<br>
&gt;<br>
<br>
</span>I&#39;m seeing a problem with this code.=C2=A0 std::normal_distribut=
ion<br>
caches results, so does other distributions internally using it.<br>
But here it looks like that a normal_distribution object will be<br>
created for each run of `variate`, wasting both CPU cycles and<br>
bits from the engine.<br></blockquote><div><br></div><div>I think that&#39;=
s fine. It&#39;s true that folks wanting to get the last ounce of performan=
ce will need to store a distribution object and re-use it, but we can provi=
de the convenient spelling for folks who don&#39;t need that. I believe it =
doesn&#39;t even cost that much in the grand scheme of things: it&#39;s on =
the order of a couple extra generated numbers, which is generally less than=
 the cost of a memory allocation, right?</div><div><br></div><div>We do sim=
ilar things when we write functions to return vectors instead of taking pre=
-allocated storage as an argument.</div></div><br></div><div class=3D"gmail=
_extra">Jeffrey</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh-dXk95fvQMS%2B7WaNUoaDuguWb6OhdDf=
3k9V%2BRyhEpyhjUaw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXk95fvQ=
MS%2B7WaNUoaDuguWb6OhdDf3k9V%2BRyhEpyhjUaw%40mail.gmail.com</a>.<br />

--089e013d0deedbca4805339a2ad3--

.

------=_Part_3498_759562376.1464112671993
Content-Type: multipart/alternative;
 boundary="----=_Part_3499_1045198529.1464112671993"

------=_Part_3499_1045198529.1464112671993
Content-Type: text/plain; charset=UTF-8

On Tuesday, May 24, 2016 at 1:48:42 PM UTC-4, Jeffrey Yasskin wrote:
>
> On Mon, May 23, 2016 at 11:38 PM, Zhihao Yuan <z...@miator.net
> <javascript:>> wrote:
>
>> On Mon, May 23, 2016 at 8:24 PM, M.E. O'Neill <one...@cs.hmc.edu
>> <javascript:>> wrote:
>> >
>> >
>> > The whole point of this proposal is that it enhances rather than
>> subverts the library we have.  Consider this code:
>> >
>> >         mt19937_gen rng;
>> >         double x = rng.variate<std::normal_distribution<double>>(17,3);
>> >
>> > it's using the beauty of the library we have while being much easer to
>> use.
>> >
>>
>> I'm seeing a problem with this code.  std::normal_distribution
>> caches results, so does other distributions internally using it.
>> But here it looks like that a normal_distribution object will be
>> created for each run of `variate`, wasting both CPU cycles and
>> bits from the engine.
>>
>
> I think that's fine. It's true that folks wanting to get the last ounce of
> performance will need to store a distribution object and re-use it, but we
> can provide the convenient spelling for folks who don't need that. I
> believe it doesn't even cost that much in the grand scheme of things: it's
> on the order of a couple extra generated numbers, which is generally less
> than the cost of a memory allocation, right?
>
> We do similar things when we write functions to return vectors instead of
> taking pre-allocated storage as an argument.
>

Whatever happened to "pay only for what you use"? I thought that was
supposed to be a design goal of C++.

I can understand if you don't want that to be *your* design goal in your
library. But what goes into the standard really ought to conform to that.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8f50dfe5-366c-4074-905f-27c2e1743f48%40isocpp.org.

------=_Part_3499_1045198529.1464112671993
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, May 24, 2016 at 1:48:42 PM UTC-4, Jeffrey Yass=
kin wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><di=
v><div class=3D"gmail_quote">On Mon, May 23, 2016 at 11:38 PM, Zhihao Yuan =
<span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"XKBPYmcoDgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#3=
9;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#3=
9;;return true;">z...@miator.net</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><span>On Mon, May 23, 2016 at 8:24 PM, M.E. O&#39;Neill &lt;<=
a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"XKBPYmcoD=
gAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;retu=
rn true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">one...=
@cs.hmc.edu</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; The whole point of this proposal is that it enhances rather than subve=
rts the library we have.=C2=A0 Consider this code:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mt19937_gen rng;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0double x =3D rng.variate&lt;std::norm=
al_<wbr>distribution&lt;double&gt;&gt;(17,3);<br>
&gt;<br>
&gt; it&#39;s using the beauty of the library we have while being much ease=
r to use.<br>
&gt;<br>
<br>
</span>I&#39;m seeing a problem with this code.=C2=A0 std::normal_distribut=
ion<br>
caches results, so does other distributions internally using it.<br>
But here it looks like that a normal_distribution object will be<br>
created for each run of `variate`, wasting both CPU cycles and<br>
bits from the engine.<br></blockquote><div><br></div><div>I think that&#39;=
s fine. It&#39;s true that folks wanting to get the last ounce of performan=
ce will need to store a distribution object and re-use it, but we can provi=
de the convenient spelling for folks who don&#39;t need that. I believe it =
doesn&#39;t even cost that much in the grand scheme of things: it&#39;s on =
the order of a couple extra generated numbers, which is generally less than=
 the cost of a memory allocation, right?</div><div><br></div><div>We do sim=
ilar things when we write functions to return vectors instead of taking pre=
-allocated storage as an argument.<br></div></div></div></div></blockquote>=
<div><br>Whatever happened to &quot;pay only for what you use&quot;? I thou=
ght that was supposed to be a design goal of C++.<br><br>I can understand i=
f you don&#39;t want that to be <i>your</i> design goal in your library. Bu=
t what goes into the standard really ought to conform to that.<br></div></d=
iv>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8f50dfe5-366c-4074-905f-27c2e1743f48%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8f50dfe5-366c-4074-905f-27c2e1743f48=
%40isocpp.org</a>.<br />

------=_Part_3499_1045198529.1464112671993--

------=_Part_3498_759562376.1464112671993--

.

--001a113ffd64279caf05339a5432
Content-Type: text/plain; charset=UTF-8

On Tue, May 24, 2016 at 10:57 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Tuesday, May 24, 2016 at 1:48:42 PM UTC-4, Jeffrey Yasskin wrote:
>>
>> On Mon, May 23, 2016 at 11:38 PM, Zhihao Yuan <z...@miator.net> wrote:
>>
>>> On Mon, May 23, 2016 at 8:24 PM, M.E. O'Neill <one...@cs.hmc.edu> wrote:
>>> >
>>> >
>>> > The whole point of this proposal is that it enhances rather than
>>> subverts the library we have.  Consider this code:
>>> >
>>> >         mt19937_gen rng;
>>> >         double x = rng.variate<std::normal_distribution<double>>(17,3);
>>> >
>>> > it's using the beauty of the library we have while being much easer to
>>> use.
>>> >
>>>
>>> I'm seeing a problem with this code.  std::normal_distribution
>>> caches results, so does other distributions internally using it.
>>> But here it looks like that a normal_distribution object will be
>>> created for each run of `variate`, wasting both CPU cycles and
>>> bits from the engine.
>>>
>>
>> I think that's fine. It's true that folks wanting to get the last ounce
>> of performance will need to store a distribution object and re-use it, but
>> we can provide the convenient spelling for folks who don't need that. I
>> believe it doesn't even cost that much in the grand scheme of things: it's
>> on the order of a couple extra generated numbers, which is generally less
>> than the cost of a memory allocation, right?
>>
>> We do similar things when we write functions to return vectors instead of
>> taking pre-allocated storage as an argument.
>>
>
> Whatever happened to "pay only for what you use"? I thought that was
> supposed to be a design goal of C++.
>
> I can understand if you don't want that to be *your* design goal in your
> library. But what goes into the standard really ought to conform to that.
>

If you're using these convenience functions, "pay only for what you use"
means the library can let you pay for them. We shouldn't _remove_ the
ability to use the cheaper things, but that design goal doesn't prevent us
from including more expensive things too.

Jeffrey

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dX%3D7ParKmWMSYHDXXApBn%3D_YHwro%2ByF9Jw%3D5dskq53o8cQ%40mail.gmail.com.

--001a113ffd64279caf05339a5432
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, May 24, 2016 at 10:57 AM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"=
mailto:jmckesson@gmail.com" target=3D"_blank" class=3D"cremed">jmckesson@gm=
ail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"ltr">On Tuesday, May 24, 2016 at 1:48:42 PM UTC-4, Jeffrey Yasskin wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"=
gmail_quote">On Mon, May 23, 2016 at 11:38 PM, Zhihao Yuan <span dir=3D"ltr=
">&lt;<a rel=3D"nofollow" class=3D"cremed">z...@miator.net</a>&gt;</span> w=
rote:<span class=3D""><br><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Mon, May =
23, 2016 at 8:24 PM, M.E. O&#39;Neill &lt;<a rel=3D"nofollow" class=3D"crem=
ed">one...@cs.hmc.edu</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; The whole point of this proposal is that it enhances rather than subve=
rts the library we have.=C2=A0 Consider this code:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mt19937_gen rng;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0double x =3D rng.variate&lt;std::norm=
al_distribution&lt;double&gt;&gt;(17,3);<br>
&gt;<br>
&gt; it&#39;s using the beauty of the library we have while being much ease=
r to use.<br>
&gt;<br>
<br>
</span>I&#39;m seeing a problem with this code.=C2=A0 std::normal_distribut=
ion<br>
caches results, so does other distributions internally using it.<br>
But here it looks like that a normal_distribution object will be<br>
created for each run of `variate`, wasting both CPU cycles and<br>
bits from the engine.<br></blockquote><div><br></div><div>I think that&#39;=
s fine. It&#39;s true that folks wanting to get the last ounce of performan=
ce will need to store a distribution object and re-use it, but we can provi=
de the convenient spelling for folks who don&#39;t need that. I believe it =
doesn&#39;t even cost that much in the grand scheme of things: it&#39;s on =
the order of a couple extra generated numbers, which is generally less than=
 the cost of a memory allocation, right?</div><div><br></div><div>We do sim=
ilar things when we write functions to return vectors instead of taking pre=
-allocated storage as an argument.<br></div></span></div></div></div></bloc=
kquote><div><br>Whatever happened to &quot;pay only for what you use&quot;?=
 I thought that was supposed to be a design goal of C++.<br><br>I can under=
stand if you don&#39;t want that to be <i>your</i> design goal in your libr=
ary. But what goes into the standard really ought to conform to that.<br></=
div></div></blockquote><div></div></div><br></div><div class=3D"gmail_extra=
">If you&#39;re using these convenience functions, &quot;pay only for what =
you use&quot; means the library can let you pay for them. We shouldn&#39;t =
_remove_ the ability to use the cheaper things, but that design goal doesn&=
#39;t prevent us from including more expensive things too.</div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Jeffrey</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh-dX%3D7ParKmWMSYHDXXApBn%3D_YHwro=
%2ByF9Jw%3D5dskq53o8cQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dX%3=
D7ParKmWMSYHDXXApBn%3D_YHwro%2ByF9Jw%3D5dskq53o8cQ%40mail.gmail.com</a>.<br=
 />

--001a113ffd64279caf05339a5432--

.

------=_Part_2977_2125159779.1464117239008
Content-Type: multipart/alternative;
 boundary="----=_Part_2978_379602098.1464117239009"

------=_Part_2978_379602098.1464117239009
Content-Type: text/plain; charset=UTF-8

On Tuesday, May 24, 2016 at 2:00:15 PM UTC-4, Jeffrey Yasskin wrote:
>
> On Tue, May 24, 2016 at 10:57 AM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> On Tuesday, May 24, 2016 at 1:48:42 PM UTC-4, Jeffrey Yasskin wrote:
>>>
>>> On Mon, May 23, 2016 at 11:38 PM, Zhihao Yuan <z...@miator.net> wrote:
>>>
>>>> On Mon, May 23, 2016 at 8:24 PM, M.E. O'Neill <one...@cs.hmc.edu>
>>>> wrote:
>>>> >
>>>> >
>>>> > The whole point of this proposal is that it enhances rather than
>>>> subverts the library we have.  Consider this code:
>>>> >
>>>> >         mt19937_gen rng;
>>>> >         double x =
>>>> rng.variate<std::normal_distribution<double>>(17,3);
>>>> >
>>>> > it's using the beauty of the library we have while being much easer
>>>> to use.
>>>> >
>>>>
>>>> I'm seeing a problem with this code.  std::normal_distribution
>>>> caches results, so does other distributions internally using it.
>>>> But here it looks like that a normal_distribution object will be
>>>> created for each run of `variate`, wasting both CPU cycles and
>>>> bits from the engine.
>>>>
>>>
>>> I think that's fine. It's true that folks wanting to get the last ounce
>>> of performance will need to store a distribution object and re-use it, but
>>> we can provide the convenient spelling for folks who don't need that. I
>>> believe it doesn't even cost that much in the grand scheme of things: it's
>>> on the order of a couple extra generated numbers, which is generally less
>>> than the cost of a memory allocation, right?
>>>
>>> We do similar things when we write functions to return vectors instead
>>> of taking pre-allocated storage as an argument.
>>>
>>
>> Whatever happened to "pay only for what you use"? I thought that was
>> supposed to be a design goal of C++.
>>
>> I can understand if you don't want that to be *your* design goal in your
>> library. But what goes into the standard really ought to conform to that.
>>
>
> If you're using these convenience functions, "pay only for what you use"
> means the library can let you pay for them. We shouldn't _remove_ the
> ability to use the cheaper things, but that design goal doesn't prevent us
> from including more expensive things too.
>

But we shouldn't make the expensive things be more convenient than cheap
things. That's what's nice about move support and elision: it encourages
doing the convenient thing (returning/passing types by value) and *makes*
it cheap (relatively).

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/75e3a696-5a37-4165-b1e7-78771f3f574e%40isocpp.org.

------=_Part_2978_379602098.1464117239009
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, May 24, 2016 at 2:00:15 PM UTC-4, Jeffrey Yass=
kin wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><di=
v><div class=3D"gmail_quote">On Tue, May 24, 2016 at 10:57 AM, Nicol Bolas =
<span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"0v8hwTQrDgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#3=
9;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#3=
9;;return true;">jmck...@gmail.com</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr">On Tuesday, May 24, 2016 at 1:48:42 PM UTC=
-4, Jeffrey Yasskin wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote">On Mon, May 23, 2016 at 11:38 PM, =
Zhihao Yuan <span dir=3D"ltr">&lt;<a rel=3D"nofollow">z...@miator.net</a>&g=
t;</span> wrote:<span><br><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Mon, May =
23, 2016 at 8:24 PM, M.E. O&#39;Neill &lt;<a rel=3D"nofollow">one...@cs.hmc=
..edu</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; The whole point of this proposal is that it enhances rather than subve=
rts the library we have.=C2=A0 Consider this code:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mt19937_gen rng;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0double x =3D rng.variate&lt;std::norm=
al_<wbr>distribution&lt;double&gt;&gt;(17,3);<br>
&gt;<br>
&gt; it&#39;s using the beauty of the library we have while being much ease=
r to use.<br>
&gt;<br>
<br>
</span>I&#39;m seeing a problem with this code.=C2=A0 std::normal_distribut=
ion<br>
caches results, so does other distributions internally using it.<br>
But here it looks like that a normal_distribution object will be<br>
created for each run of `variate`, wasting both CPU cycles and<br>
bits from the engine.<br></blockquote><div><br></div><div>I think that&#39;=
s fine. It&#39;s true that folks wanting to get the last ounce of performan=
ce will need to store a distribution object and re-use it, but we can provi=
de the convenient spelling for folks who don&#39;t need that. I believe it =
doesn&#39;t even cost that much in the grand scheme of things: it&#39;s on =
the order of a couple extra generated numbers, which is generally less than=
 the cost of a memory allocation, right?</div><div><br></div><div>We do sim=
ilar things when we write functions to return vectors instead of taking pre=
-allocated storage as an argument.<br></div></span></div></div></div></bloc=
kquote><div><br>Whatever happened to &quot;pay only for what you use&quot;?=
 I thought that was supposed to be a design goal of C++.<br><br>I can under=
stand if you don&#39;t want that to be <i>your</i> design goal in your libr=
ary. But what goes into the standard really ought to conform to that.<br></=
div></div></blockquote><div></div></div><br></div><div>If you&#39;re using =
these convenience functions, &quot;pay only for what you use&quot; means th=
e library can let you pay for them. We shouldn&#39;t _remove_ the ability t=
o use the cheaper things, but that design goal doesn&#39;t prevent us from =
including more expensive things too.</div></div></blockquote><div><br>But w=
e shouldn&#39;t make the expensive things be more convenient than cheap thi=
ngs. That&#39;s what&#39;s nice about move support and elision: it encourag=
es doing the convenient thing (returning/passing types by value) and <i>mak=
es</i> it cheap (relatively).<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/75e3a696-5a37-4165-b1e7-78771f3f574e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/75e3a696-5a37-4165-b1e7-78771f3f574e=
%40isocpp.org</a>.<br />

------=_Part_2978_379602098.1464117239009--

------=_Part_2977_2125159779.1464117239008--

.

--001a113ffd64f92c1f05339c24a1
Content-Type: text/plain; charset=UTF-8

First, thanks for proposing an improvement to <random>. We need more people
to do things like that.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4582.pdf is the
most recent draft of C++17, and what you find in there is very likely to be
in the final standard, unless folks find significant problems. So you
should assume sample(PopulationIterator first, PopulationIterator last,
SampleIterator out, Distance n, UniformRandomNumberGenerator&& g) will
stick around.

The per-thread engine is only in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4584.html, the
Library Fundamentals TS, and I understand there's some objection to having
it at all. I think it'll probably make it into C++20, but there's
definitely time to replace it with something better.

I think it's totally defensible to have a library that wraps up a bunch of
useful algorithms into a class type. However, in C++ we got burned with the
std::string interface, and so tend toward writing the non-essential
algorithms as non-member functions, so that it's just as easy to call
extensions as it is to call the functions the library author anticipated.

So, pick(), choose(), uniform(), and variate() should probably all be added
as non-member algorithms. (I'm a little skeptical of variate(), and maybe
choose(range) should return the element, but those are minor details.)

And I do think they're algorithms, even if they're one line each. It takes
some ingenuity to write or, more importantly, read that line, and you don't
need it as much if it's a function with a good name.

I don't really mind making the design flaws in the standard library stand
out. We do make mistakes, and we shouldn't contort later interfaces to
disguise those mistakes. We do often change the shape of things to be
consistent with older styles, but I'm trying to push folks away from doing
that when the older style was actually wrong, and not just out of fashion.

Jeffrey

On Mon, May 23, 2016 at 4:48 PM, M.E. O'Neill <oneill@cs.hmc.edu> wrote:

> Richard Smith wrote:
> > The new random algorithms here (choose, pick, ...) should be made
> available as non-member functions that operate on URNGs, like sample and
> shuffle already are -- it doesn't seem reasonable for these to exist in the
> convenience wrapper but for the general case.
>
> FWIW, sample doesn't exist in the standard yet, it's a proposed addition.
> When I wrote randutils it didn't exist.  So the only stand-alone function
> in C++14 is shuffle, whose origins date back to random_shuffle (which
> predates the C++11 <random> library and thus has a different flavor).  Thus
> pick, choose, uniform, variate, and sample all don't exist right now.
>
> To me there is a bit of a fork in the road here, let's look at the two
> forks:
>
> Option 1: Global functions, exemplified by the proposed sample algorithm,
> which take (optional) extra arguments to specify the engine.  To simply
> things, there is a global state (actually per-thread) that holds some
> system-defined random engine (i.e., the randint proposal).  But do you want
> a constellation of thematically-related global helper functions (i.e.,
> seeded, uniform, variate, pick, choose, shuffle, and sample)?
>
> Option 2: Random-generator objects, which tie together the <random> pieces
> but stay in the domain of object orientation.  There is far less reliance
> on baked-in global state and only one new name in the std namespace.
>
> The rest of the random number generation library is happy to use objects
> (e.g., the distributions, the engines, etc.), the second option retains the
> flavor of the existing library while making it easier to use.
>
> > ... how would you feel about
> >
> >   auto urng = std::seeded<std::mt19937>(); // returns a
> nondeterministically seeded std::mt19937
> >   std::cout << choose(some_list, urng);
>
> I don't like it.  I teach C++ (to smart people who already have some
> programming experience), and I don't want to to have to explain this.  If
> urng is a std::mt19937, it looks like a band-aid around a design flaw (why
> doesn't std::mt19937 know how to construct itself well in the first place?
> why does it need a helper function?  why doesn't it look like the rest of
> the rng library?).  And, did a std::mt19937 object get copied here?
>
> If you presuppose that randint is a done deal and so is sample, then
> perhaps there isn't as much reason for this convenience class, but I don't
> think they are set in stone yet, and I think it's worthwhile to think
> through what really fits best with the random generation library we have.
> In that vein, it's shuffle that's the outlier.
>
> The focus of this proposal is providing a tiny amount of glue to make all
> the wonderful features of <random> actually easy to use.   There is pretty
> much no reason to provide pick as a helper function, or variate, or even
> sample, because they aren't really meaty *algorithms* at all, they're
> virtually one liners (choose is just a call to advance by an appropriate
> random amount, sample is just stable_partition with an appropriate
> random-based predicate. etc.).   But there are a very good reasons to make
> these things something a random-generator object can do, because it creates
> something cohesive.
>
> Thoughts welcome,
>
>     M.E.O.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/E197AA74-7F44-434C-B5E9-6DCC2FB12AF4%40cs.hmc.edu
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXm28qDZQxt4G3M35nmiQ-ifB0HeVXX9muLrbzhBeYcgaw%40mail.gmail.com.

--001a113ffd64f92c1f05339c24a1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">First, thanks for proposing an improvement to &lt;random&g=
t;. We need more people to do things like that.<div><br></div><div><a href=
=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4582.pdf">http=
://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4582.pdf</a> is the mo=
st recent draft of C++17, and what you find in there is very likely to be i=
n the final standard, unless folks find significant problems. So you should=
 assume=C2=A0sample(PopulationIterator first, PopulationIterator last, Samp=
leIterator out, Distance n, UniformRandomNumberGenerator&amp;&amp; g) will =
stick around.</div><div><br></div><div>The per-thread engine is only in <a =
href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4584.html"=
>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4584.html</a>, th=
e Library Fundamentals TS, and I understand there&#39;s some objection to h=
aving it at all. I think it&#39;ll probably make it into C++20, but there&#=
39;s definitely time to replace it with something better.</div><div><br></d=
iv><div>I think it&#39;s totally defensible to have a library that wraps up=
 a bunch of useful algorithms into a class type. However, in C++ we got bur=
ned with the std::string interface, and so tend toward writing the non-esse=
ntial algorithms as non-member functions, so that it&#39;s just as easy to =
call extensions as it is to call the functions the library author anticipat=
ed.</div><div><br></div><div>So, pick(), choose(), uniform(), and variate()=
 should probably all be added as non-member algorithms. (I&#39;m a little s=
keptical of variate(), and maybe choose(range) should return the element, b=
ut those are minor details.)</div><div><br></div><div>And I do think they&#=
39;re algorithms, even if they&#39;re one line each. It takes some ingenuit=
y to write or, more importantly, read that line, and you don&#39;t need it =
as much if it&#39;s a function with a good name.<br><div><br></div><div>I d=
on&#39;t really mind making the design flaws in the standard library stand =
out. We do make mistakes, and we shouldn&#39;t contort later interfaces to =
disguise those mistakes. We do often change the shape of things to be consi=
stent with older styles, but I&#39;m trying to push folks away from doing t=
hat when the older style was actually wrong, and not just out of fashion.</=
div></div><div><br></div><div>Jeffrey</div><div class=3D"gmail_extra"><br><=
div class=3D"gmail_quote">On Mon, May 23, 2016 at 4:48 PM, M.E. O&#39;Neill=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:oneill@cs.hmc.edu" class=3D"gmail-=
cremed gmail-cremed gmail-cremed gmail-cremed cremed">oneill@cs.hmc.edu</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-co=
lor:rgb(204,204,204);padding-left:1ex">Richard Smith wrote:<br>
&gt; The new random algorithms here (choose, pick, ...) should be made avai=
lable as non-member functions that operate on URNGs, like sample and shuffl=
e already are -- it doesn&#39;t seem reasonable for these to exist in the c=
onvenience wrapper but for the general case.<br>
<br>
FWIW, sample doesn&#39;t exist in the standard yet, it&#39;s a proposed add=
ition.=C2=A0 When I wrote randutils it didn&#39;t exist.=C2=A0 So the only =
stand-alone function in C++14 is shuffle, whose origins date back to random=
_shuffle (which predates the C++11 &lt;random&gt; library and thus has a di=
fferent flavor).=C2=A0 Thus pick, choose, uniform, variate, and sample all =
don&#39;t exist right now.<br>
<br>
To me there is a bit of a fork in the road here, let&#39;s look at the two =
forks:<br>
<br>
Option 1: Global functions, exemplified by the proposed sample algorithm, w=
hich take (optional) extra arguments to specify the engine.=C2=A0 To simply=
 things, there is a global state (actually per-thread) that holds some syst=
em-defined random engine (i.e., the randint proposal).=C2=A0 But do you wan=
t a constellation of thematically-related global helper functions (i.e., se=
eded, uniform, variate, pick, choose, shuffle, and sample)?<br>
<br>
Option 2: Random-generator objects, which tie together the &lt;random&gt; p=
ieces but stay in the domain of object orientation.=C2=A0 There is far less=
 reliance on baked-in global state and only one new name in the std namespa=
ce.<br>
<br>
The rest of the random number generation library is happy to use objects (e=
..g., the distributions, the engines, etc.), the second option retains the f=
lavor of the existing library while making it easier to use.<br>
<span class=3D"gmail-"><br>
&gt; ... how would you feel about<br>
&gt;<br>
&gt;=C2=A0 =C2=A0auto urng =3D std::seeded&lt;std::mt19937&gt;(); // return=
s a nondeterministically seeded std::mt19937<br>
&gt;=C2=A0 =C2=A0std::cout &lt;&lt; choose(some_list, urng);<br>
<br>
</span>I don&#39;t like it.=C2=A0 I teach C++ (to smart people who already =
have some programming experience), and I don&#39;t want to to have to expla=
in this.=C2=A0 If urng is a std::mt19937, it looks like a band-aid around a=
 design flaw (why doesn&#39;t std::mt19937 know how to construct itself wel=
l in the first place? why does it need a helper function?=C2=A0 why doesn&#=
39;t it look like the rest of the rng library?).=C2=A0 And, did a std::mt19=
937 object get copied here?<br>
<br>
If you presuppose that randint is a done deal and so is sample, then perhap=
s there isn&#39;t as much reason for this convenience class, but I don&#39;=
t think they are set in stone yet, and I think it&#39;s worthwhile to think=
 through what really fits best with the random generation library we have.=
=C2=A0 In that vein, it&#39;s shuffle that&#39;s the outlier.<br>
<br>
The focus of this proposal is providing a tiny amount of glue to make all t=
he wonderful features of &lt;random&gt; actually easy to use.=C2=A0 =C2=A0T=
here is pretty much no reason to provide pick as a helper function, or vari=
ate, or even sample, because they aren&#39;t really meaty *algorithms* at a=
ll, they&#39;re virtually one liners (choose is just a call to advance by a=
n appropriate random amount, sample is just stable_partition with an approp=
riate random-based predicate. etc.).=C2=A0 =C2=A0But there are a very good =
reasons to make these things something a random-generator object can do, be=
cause it creates something cohesive.<br>
<br>
Thoughts welcome,<br>
<br>
=C2=A0 =C2=A0 M.E.O.<br>
<span class=3D"gmail-"><br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" class=3D"=
gmail-cremed gmail-cremed gmail-cremed gmail-cremed cremed">std-proposals+u=
nsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"gmail-cremed gmail-cremed gmail-cremed gmail-cremed cremed">=
std-proposals@isocpp.org</a>.<br>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/E197AA74-7F44-434C-B5E9-6DCC2F=
B12AF4%40cs.hmc.edu" rel=3D"noreferrer" class=3D"gmail-cremed gmail-cremed =
gmail-cremed gmail-cremed cremed">https://groups.google.com/a/isocpp.org/d/=
msgid/std-proposals/E197AA74-7F44-434C-B5E9-6DCC2FB12AF4%40cs.hmc.edu</a>.<=
br>
</blockquote></div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh-dXm28qDZQxt4G3M35nmiQ-ifB0HeVXX9=
muLrbzhBeYcgaw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXm28qDZQxt4=
G3M35nmiQ-ifB0HeVXX9muLrbzhBeYcgaw%40mail.gmail.com</a>.<br />

--001a113ffd64f92c1f05339c24a1--

.

--001a113ffd6402892205339c2794
Content-Type: text/plain; charset=UTF-8

On Mon, May 23, 2016 at 6:02 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> Have you not looked at Chapter 25 of the C++ Standard? That's how we do
> things in C++.
>

Please be more respectful on this list.

Jeffrey

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXkxQ_xVvNdS00LkFhKqyFXQza0n3bnDJyzZpWgAX2wLkg%40mail.gmail.com.

--001a113ffd6402892205339c2794
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, May 23, 2016 at 6:02 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank" class=3D"cremed">jmckesson@gma=
il.com</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div>Have you not looked at Chapter 25 of the C++ Standard? That&#39;s how=
 we do things in C++.</div></div></blockquote><div>=C2=A0</div><div>Please =
be more respectful on this list.</div><div><br></div><div>Jeffrey</div></di=
v><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh-dXkxQ_xVvNdS00LkFhKqyFXQza0n3bnD=
JyzZpWgAX2wLkg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXkxQ_xVvNdS=
00LkFhKqyFXQza0n3bnDJyzZpWgAX2wLkg%40mail.gmail.com</a>.<br />

--001a113ffd6402892205339c2794--

.

On Tue, May 24, 2016 at 3:09 PM, 'Jeffrey Yasskin' via ISO C++
Standard - Future Proposals <std-proposals@isocpp.org> wrote:
>
> I think it's totally defensible to have a library that wraps up a bunch of
> useful algorithms into a class type. However, in C++ we got burned with the
> std::string interface, and so tend toward writing the non-essential
> algorithms as non-member functions, so that it's just as easy to call
> extensions as it is to call the functions the library author anticipated.
>

This is not as same as the std::string case IMO.  For std::string,

  1. There are just too many overloads, because only std::string
    uses indices.  <random> doesn't.

  2. Many code bases have their own String types.  random_-
    generator is just a wrapper; if with my type-erasing suggestion,
    there will be only one type.

  3. The concepts of find/replace apply to non-characters well.  But
    uniform(), choose(), etc. are not so outside the context of random
    numbers.  At least, this generate() is not that generate().

==x cut ==x cut ==

I implemented my idea of a type-erased random_generator
and added some benchmarks, and it turns out to be working
fine.  Detailed changes are:

  - // using unpredictably seeded default_random_generator
    random_generator g;
  - g = mt19937();         // using default seeded mt19937
  - g.use<mt19937>();  // using unpredictably seeded mt19937
  - // distribution object as argument to variate is required
    g.variate(std::normal_distribution<double>(0.0, 1.0));
  - // distribution object as argument to generate is optional
    g.generate(begin(v), end(v));
    g.generate(std::normal_distribution<double>(), begin(v),
        end(v));

And I added a new method, gauss, modeled after uniform(),
so that the result_type is deduced,

    g.gauss(0.0, 1.0);

Also gives me a chance to make uniform variate perform better
using the Kinderman and Monahan method copied from Python.
It kind of works under clang 3.6 + libstdc++:

type-erased generate
: 0.0107519s

type-erased variate
: 0.0203656s  <==

type-erased Gaussian
: 0.0137261s  <==

direct generate
: 0.014665s  <== but what is this?!

Cannot neglect the cost of calling the underlying engine
twice at all under gcc 4.9:

type-erased generate
: 0.00691891s

type-erased variate
: 0.0136719s  <==

type-erased Gaussian
: 0.0120535s  <==

direct generate
: 0.00603833s

The code is here https://github.com/lichray/randutils .

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://blog.miator.net/

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuBCBhRzE9Fv_avQ6u%3D%3DUwr16hGwf4GW5MC6nEaRzuCApA%40mail.gmail.com.

.

On Tue, May 24, 2016 at 11:26 PM, Zhihao Yuan <zy@miator.net> wrote:
> Cannot neglect the cost of calling the underlying engine
> twice at all under gcc 4.9

Err, forgot generate_canonical.  Now saner:

type-erased generate
: 0.00681946s
0.996832
type-erased variate
: 0.013105s  <==
0.999598
type-erased Gaussian
: 0.00926815s  <==
0.998747
direct generate
: 0.00600034s
1.00041

And it's as fast as the type-erased generate case in clang now.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://blog.miator.net/

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuCJEH%3D6sM4OBH5OdcWJMHh1zeQs0M97XPdAHN5UJSpyKw%40mail.gmail.com.

.