Corner case in `dirichlet_lpdf`: error when both alpha - 1 = theta = 0
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 35/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- cpp
- Lĩnh vực
- machine-learning
Hướng nghiên cứu
Bắt đầu trong stan/math/prim/prob/dirichlet_lpdf.hpp tại phép tính theta_log được liên kết, sau đó kiểm tra cách xử lý partials_vec<1> tương ứng. Xác định xem trường hợp alpha - 1 = theta = 0 có nên đóng góp bằng không mà không phát sinh lỗi hay không, và đảm bảo hành vi autodiff liên quan là nhất quán.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
In the code there is currently:
const auto& theta_log
= to_ref_if<!is_constant_all<T_prior_size>::value>(theta_dbl.log());
if (include_summand<propto, T_prob, T_prior_size>::value) {
lp += (theta_log * alpha_m_1).sum();
}
I understand that by the convention (and also by Stan documentation) for Dirichlet distribution, we usually require theta > 0. But when you think about it, for the corner case when alpha -1 == theta == 0, it is reasonable to define the lpdf to be 0 by the same logic why we define pow(0,0)=1. This is relevant in my application, where I may have on input an information that certain index of theta is a forbidden state and may thus be represented as hard constrained to be equal to 0, but then the Dirichlet prior crashes no matter what. This would be very inefficient for me to workaround by deleting the offending array element as I need to do this over a matrix with many rows each of which may have different constraints, so currently I needed to make my custom implementation of dirichlet_lpdf just to deal with that. I thus propose we change the code to something like:
if (include_summand<propto, T_prob, T_prior_size>::value) {
lp += lmultiply(alpha_m_1, theta).sum();
}
The partials_vec<1> may need a corresponding adjustment.
- Ngôn ngữ chính
- C++
- Star
- 845
- Fork
- 225
- Merge trung bình
- 4 ngày 21 giờ
- Pull request đã merge (30 ngày)
- 13
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của stan-dev/math
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 54/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 54/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
Maintainer thường phản hồi trong vòng 1 ngày
-
numerics performance
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
stan-dev/math#3481 · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
`eigendecompose_sym`, `eigenvalues_sym` and `eigenvectors_sym` do not compile for complex matrices of `fvar<var>` or `fvar<fvar<double>>`Có thể làm lại được Pull request cho issue này đã bị đóng mà không được merge. Đang mởbug
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 55/100
stan-dev/math#3477 · 5 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của stan-dev/math
Issue tương tự
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
pocoproject/poco#5664 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
charmplusplus/charm#4210 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
cp-algorithms/cp-algorithms#1748 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
Maintainer thường phản hồi trong vòng 1 ngày