Skip to content
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

Conversation

statementreply
Copy link
Contributor

@statementreply statementreply commented Jul 11, 2020

Fixes #950 and fixes #1084.
Fixes AB#115939.

@statementreply statementreply requested a review from a team as a code owner July 11, 2020 09:11
@statementreply statementreply changed the title Fix parameter initialization of piecewise_constant_distribution and piecewise_linear_distribution <random>: Fix parameter initialization of piecewise_constant_distribution and piecewise_linear_distribution Jul 11, 2020
@statementreply statementreply marked this pull request as draft July 11, 2020 11:36
stl/inc/random Outdated Show resolved Hide resolved
@@ -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) {
Copy link
Contributor

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?

Copy link
Contributor Author

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 reserved before populating vectors. Perhaps for another "performance" PR?

Copy link
Member

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A pattern like this

STL/stl/inc/random

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?

Copy link
Member

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) {
Copy link
Contributor

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

Copy link
Contributor

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

@statementreply statementreply marked this pull request as ready for review July 11, 2020 13:45
stl/inc/random Outdated Show resolved Hide resolved
stl/inc/random Outdated Show resolved Hide resolved
@statementreply
Copy link
Contributor Author

Could that be _Count==0 or even _Count = _STD min(_Count, 1u);

_STD max(_Count, size_t{1}) 😃

@StephanTLavavej StephanTLavavej added the bug Something isn't working label Jul 12, 2020
@StephanTLavavej
Copy link
Member

Thanks - I verified that your AB#nnn citation properly linked the MS-internal bug to this PR. 🎉

@statementreply

This comment has been minimized.

@statementreply
Copy link
Contributor Author

std/numerics/rand/rand.dis/rand.dist.samp/rand.dist.samp.pconst/eval.pass.cpp FAIL
std/numerics/rand/rand.dis/rand.dist.samp/rand.dist.samp.plinear/eval_param.pass.cpp FAIL
std/numerics/rand/rand.dis/rand.dist.samp/rand.dist.samp.plinear/eval.pass.cpp FAIL

These random number generation tests are failing because their pass criteria is too strict.

@StephanTLavavej StephanTLavavej self-assigned this Jul 25, 2020
Copy link
Member

@StephanTLavavej StephanTLavavej left a 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.

@StephanTLavavej StephanTLavavej removed their assignment Jul 29, 2020
@CaseyCarter CaseyCarter self-assigned this Jul 29, 2020
@StephanTLavavej
Copy link
Member

I've pushed a merge to resolve a conflict, accepting both changes to the libcxx skip lists (for random and lerp).

@StephanTLavavej
Copy link
Member

I've pushed another merge, resolving #1119's STD changes in tr1.

@StephanTLavavej

This comment has been minimized.

@azure-pipelines

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);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ugh, using unrelated library internals in a test for no reason at all: tr1 things. (No change requested.)

image

Copy link
Contributor

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A widespread problem #1184

@CaseyCarter CaseyCarter removed their assignment Aug 12, 2020
@StephanTLavavej StephanTLavavej self-assigned this Aug 12, 2020
@StephanTLavavej StephanTLavavej merged commit 3224307 into microsoft:master Aug 12, 2020
@StephanTLavavej
Copy link
Member

Thanks for fixing these bugs! 😸 This will ship in VS 2019 16.8 Preview 3.

@statementreply statementreply deleted the fix_piecewise_linear_distribution branch April 17, 2021 11:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
6 participants