-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
<random>: Fix parameter initialization of piecewise_constant_distribution and piecewise_linear_distribution #1032
<random>: Fix parameter initialization of piecewise_constant_distribution and piecewise_linear_distribution #1032
Conversation
piecewise_linear_distribution
piecewise_linear_distribution
@@ -4571,20 +4575,15 @@ public: | |||
param_type(initializer_list<_Ty> _Ilist, _Fn _Func) : _Mypbase(_Noinit) { | |||
if (2 <= _Ilist.size()) { | |||
_Bvec.assign(_Ilist); | |||
|
|||
for (size_t _Idx = 0; _Idx < _Bvec.size() - 1; ++_Idx) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to reserve here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are several more occurrences in discrete_distribution
, piecewise_constant_distribution
and piecewise_linear_distribution
where we could have reserve
d before populating vector
s. Perhaps for another "performance" PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A separate performance PR would make sense. Cautionary note: a single reserve
after vector
construction is fine, but we should be careful to avoid reserve
in anything that the user can call in a loop for a single vector
, as that can trigger quadratic complexity. I'm specifically thinking about dist.param(const param_type&)
here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A pattern like this
Lines 247 to 251 in 1fef5f7
void _Construct(_InIt _First, _InIt _Last) { | |
for (; _First != _Last; ++_First) { | |
_Myvec.push_back(static_cast<unsigned int>(*_First)); | |
} | |
} |
is ideally replaced with range-based algorithm, which would result in transformed iterators, and the vector would reserve automatically at least for random-access iterator.
Maybe just create issue for now and wait for ranges?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs to work in C++14 mode and thus will not have ranges avaialble.
@@ -4771,20 +4777,15 @@ public: | |||
param_type(initializer_list<_Ty> _Ilist, _Fn _Func) : _Mypbase(_Noinit) { | |||
if (2 <= _Ilist.size()) { | |||
_Bvec.assign(_Ilist); | |||
|
|||
for (const auto& _Bval : _Bvec) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At work I would ask for std::transform but here meh
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And here, range-based transform would be too good for meh, since I expect it to be very short and clear, and enabling vector
to auto-reserve
warning C4244: conversion from 'long double' to 'double'
|
Thanks - I verified that your AB#nnn citation properly linked the MS-internal bug to this PR. 🎉 |
This comment has been minimized.
This comment has been minimized.
These random number generation tests are failing because their pass criteria is too strict. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! I think it's safe to say that you understand this code better than I do (and I've had a dozen years to learn). 😺 I've looked for inconsistencies, or anything that seems potentially ABI-concerning, and didn't find anything. (Also looked for sources of potential warnings, like float
being used as a type, and that all looks good.) Adding test coverage to TR1 is a reasonable choice here, given how it already has a lot of the necessary infrastructure - we generally don't extend the legacy test suite but this merits an exception. libcxx providing test coverage (sometimes overly strict as you found) helps too.
I've pushed a merge to resolve a conflict, accepting both changes to the libcxx skip lists (for random and lerp). |
I've pushed another merge, resolving #1119's |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@@ -486,9 +499,10 @@ static void tpiecewise_constant() { | |||
dist_t dist2(10, 1.0, 2.0, myfn); | |||
CHECK_INT(dist2.densities().size(), 10); | |||
|
|||
double arr[] = {1.0, 1.1, 1.2, 1.3, 1.4}; | |||
double arr[] = {1.0, 1.5, 2.0, 3.0, 4.0}; | |||
dist_t dist3(STD initializer_list<double>(&arr[0], &arr[5]), myfn); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could be Good First Issue other than update define
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A widespread problem #1184
Thanks for fixing these bugs! 😸 This will ship in VS 2019 16.8 Preview 3. |
Fixes #950 and fixes #1084.
Fixes AB#115939.