Conversation
bob-carpenter
left a comment
There was a problem hiding this comment.
This all looks pretty much OK.
I didn't see the need to convert one liner conditionals to two lines, but we should set a standard for these if you're going to spend time correcting them.
So it'd be great if you could include the style you converted to as guidelines in our style guide.
There are some performance issues (duplicated subexpressions) and things like 1.0 vs. 1 that could be cleaned up elsewhere. If you don't want to do it as part of this, would you mind creating an issue?
| values(k) = (Km1 - k - 1) * log_diagonals(k); | ||
| if ( (eta == 1.0) && | ||
| stan::is_constant<typename stan::scalar_type<T_shape> >::value) { | ||
| if ((eta == 1.0) && |
There was a problem hiding this comment.
Don't need the parens around the equality.
| if ( (eta == 1.0) && | ||
| stan::is_constant<typename stan::scalar_type<T_shape> >::value ) | ||
| if ((eta == 1.0) && | ||
| stan::is_constant<typename stan::scalar_type<T_shape> >::value) |
There was a problem hiding this comment.
don't need the stan:: qualification within the stan namespace unless there's ambiguity with another namespace.
There was a problem hiding this comment.
Created issue #594 for removing the stan:: qualification.
| || !stan::is_constant<typename scalar_type<T10>::type>::value | ||
| ) | ||
| value = (!propto | ||
| || !stan::is_constant<typename scalar_type<T1>::type>::value |
There was a problem hiding this comment.
don't need namespace qualification
|
|
||
| if (!(stan::length(n) | ||
| && stan::length(theta))) | ||
| if (!(stan::length(n) && stan::length(theta))) |
There was a problem hiding this comment.
don't need stan:: namespace qual; I'm going to stop noting this now, but it should really be done everywhere
|
|
||
| if (!(stan::length(y) && stan::length(alpha) | ||
| && stan::length(beta))) | ||
| if (!(stan::length(y) && stan::length(alpha) && stan::length(beta))) |
There was a problem hiding this comment.
Someone was just pointing out all the redundant code in our distributions (sorry, can't recall who). This is a case where we should have a function
template <typename T1, typename T2, typename T3>
bool non_empty(const T1& x1, const T2& x2, const T3& x3) {
return !(length(x1) && length(x2) && length(x3));
}
| const T_partials_return p_dbl = beta_dbl / (1.0 + beta_dbl); | ||
| const T_partials_return d_dbl = 1.0 / ( (1.0 + beta_dbl) | ||
| * (1.0 + beta_dbl) ); | ||
| const T_partials_return d_dbl = 1.0 / ((1.0 + beta_dbl) |
There was a problem hiding this comment.
same expression duplication issue
| if (!is_constant_struct<T_inv_scale>::value) | ||
| ops_partials.edge2_.partials_[i] += d_dbl * pow(1-p_dbl, n_dbl) | ||
| ops_partials.edge2_.partials_[i] += d_dbl * pow(1 - p_dbl, n_dbl) | ||
| * pow(p_dbl, alpha_dbl-1) / beta_func / Pi; |
There was a problem hiding this comment.
You missed the space around the operator in line 125. Also, efficiency of multiple division here.
| @@ -45,9 +45,7 @@ namespace stan { | |||
|
|
|||
| T_partials_return cdf(1.0); | |||
There was a problem hiding this comment.
This is a different order of return vs. all the other cases. Should we fix one? I don't think there's an efficiency concern either way, but I think having the return be a constant and the return defined afterwards is easier to understand (doesn't require you to go look back to find value of cdf being returned).
| if (!(stan::length(y) | ||
| && stan::length(alpha) | ||
| && stan::length(beta))) | ||
| if (!(stan::length(y) && stan::length(alpha) && stan::length(beta))) |
There was a problem hiding this comment.
This is an example of the pattern I think we should be using.
| const Eigen::Matrix<TB, CA, CB>& B) | ||
| : vari(0.0), | ||
| public: | ||
| int A_rows_, A_cols_, B_cols_, A_size_, B_size_; |
There was a problem hiding this comment.
Why double up some declarations and not others? It just looks inconsistent.
|
I still can't figure out how you do these massive updates. This kind of thing is dangerous as it has the potential to cause conflicts in lots of branches. I can cope, though, and would rather clean up our code. The jury's out on whether this is "best practices" or not. |
|
I can get these massive updates done because I only focus on one small problem at a time! And I want to get the number of issues assigned to me down (this comment was on one of my assigned issues). And it bothers me when things aren't consistent. I'll create new issues for all the other problems you spotted. For this pull request, the conflicts across branches should be minimal. It's spacing within mostly if statements and git's diff mechanism works pretty well. I can see it messing with @sakrejda's branch on the derivatives of the gamma distribution, but otherwise, there aren't too many branches that touch these error checks. Regarding the splitting of conditionals from one line to two, I did it for consistency with the rest of our code base. Those were the only places where they were on one line. Personally, I find it easier to follow the style of code in a code base when there aren't multiple styles in the code base. If there was a good rule to have it be on one line, we could change everything to that style and I'd be just as happy. |
|
I am going to split up that branch into smaller PR's now that I see how to
do it. Don't worry about that branch.
…On Tue, Aug 1, 2017, 2:25 PM Daniel Lee ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In stan/math/prim/mat/prob/lkj_corr_cholesky_lpdf.hpp
<#588 (comment)>:
> @@ -78,8 +78,8 @@ namespace stan {
Eigen::Matrix<lp_ret, Eigen::Dynamic, 1> values(Km1);
for (int k = 0; k < Km1; k++)
values(k) = (Km1 - k - 1) * log_diagonals(k);
- if ( (eta == 1.0) &&
- stan::is_constant<typename stan::scalar_type<T_shape> >::value) {
+ if ((eta == 1.0) &&
Created issue #593 <#593> for this.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#588 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAfA6UTnX0ouhHzCmhczAuiep0PUb6jyks5sT22wgaJpZM4OnPx1>
.
|
|
I can get these massive updates done because I only focus on one small problem at a time!
Aha! I think I finally get it. It's like the professional movers who just pack all your stuff without looking at it and it's done so fast it makes your head spin.
I'll create new issues for all the other problems you spotted.
Thanks.
For this pull request, the conflicts across branches should be minimal.
great
Regarding the splitting of conditionals from one line to two, I did it for consistency with the rest of our code base. Those were the only places where they were on one line. Personally, I find it easier to follow the style of code in a code base when there aren't multiple styles in the code base. If there was a good rule to have it be on one line, we could change everything to that style and I'd be just as happy.
OK, that makes sense. I'm happy putting them on a second line. (Recently, I've been putting things on one line if it'll fit---no other rhyme or reason.) Google style guide is OK with that, but they note it's a contentious issue :-)
|
|
Btw, @bob-carpenter, thank you for being so thorough in the review! It's the only way our code base will get better. |
|
@bob-carpenter, I've spawned new issues with the things you picked out. Want to approve this pull request so it can be merged? If you ever wanted to ignore white-space changes, you can add |
Submission Checklist
./runTests.py test/unitmake cpplintSummary:
Clean up part of the code base.
How to Verify:
Visually inspect.
Side Effects:
None.
Documentation:
None.
Copyright and Licensing
Please list the copyright holder for the work you are submitting (this will be you or your assignee, such as a university or company):
Stan Group
By submitting this pull request, the copyright holder is agreeing to license the submitted work under the following licenses: