You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since shape=Inf converges to the delta distribution for all finite scale, I wouldn't call it degenerate, but much simpler to express than Weibull variable.
Perhaps I'm oversimplifying the issue, but I'm again wondering if we should disallow these not exactly degenerate, but still special case parameter values. (There are other cases where 0 values cause this sort of behavior).
I don't think most people would pass Inf intentionally. Personally, if I knew that I would just implement the explicit behavior.
I'm expecting that most of the time, we're going to be handling infinities that occurred from floating point operations instead of literal infinities. Our implementations are the behavior we expect for when a caller passes literal float infinity, so maybe this isn't what we want.
I don't think you got a full response on #303, but perhaps disallowing inf parameters would have culled more options at the start.
Might be part of #102.
shape = +Inf
and0 < scale < 1
:scale_pow_shape_inv
(== scale.powf(-shape)
) will become+Inf
which causes all sorts of problemscdf
/sf
/pdf
/ln_pdf
start returning NaN for valid params1scale >= 1
, then cdf etc. generally behave well(?)scale = +Inf
will always makeinverse_cdf(0)
returnNaN
shape
is also+Inf
, then it returns 1...I believe this behaviour is unpredictable and unwanted, but I'm not sure for every single case listed here. And I might've missed something.
Are parameters set to
f64::INFINITY
degenerate for this distribution? If they are not, then they need special handling from what I can tell.Dirty testing code to find some things:
Footnotes
x.powf(shape)
will becomex.powf(+Inf)
which is zero for any x in(0, 1)
. Then it's0 * scale_pow_shape_inv
which is0 * Inf
which isNaN
↩The text was updated successfully, but these errors were encountered: