Domain violation in transform

[andreasnoack]

E.g.

julia> t = as((σ = asℝ₊,));

julia> transform(t, [-746])
(σ = 0.0,)

This is causing problems in some optimization code where we optimize over the Vector representation and have to convert back and forth. That causes errors similar to

julia> inverse(t, transform(t, [-746]))
ERROR: DomainError with x > shift must hold. Got
x => 0.0
shift => 0.0:

[tpapp]

I wonder if a less strict domain checking (allow 0, map it to -Inf) would solve this.

[andreasnoack]

Possibly. After filing the issue, I thought a bit more about the problem and I'm not sure what the right solution is. My problem clear wants to set σ to zero so the problem might just move somewhere else if this issue is fixed one way or the other.

[tpapp]

Can you please provide more context?

Eg in a Bayesian model if there is mass around σ = 0 (and it is some kind of a standard deviation/scale parameter) then I would suspect a misspecified model, or try to keep it away from zero with a prior. I am not saying that your model is wrong in this way but the solution can be context-dependent.

[andreasnoack]

It's traditional maximum likelihood optimization and most likely the model that triggered this is wrong. However, people will try to fit wrong models it's a matter of failing in a reasonable way.

[tpapp]

I am very happy to fix this issue, I just need help with what you or other users would consider reasonable.

Personally, since an invariant is violated, I prefer failure so that I can learn about it early and investigate.

Eg for ML, I would do penalized ML/MAP. Is it a hierarchical model?

[andreasnoack]

I am very happy to fix this issue, I just need help with what you or other users would consider reasonable.

I understand

Personally, since an invariant is violated

Yes but the invariant is violated already in

julia> transform(t, [-746])
(σ = 0.0,)

so that might be where the exception should be thrown from.

Is it a hierarchical model?

Yes indeed it's a hierarchical model. What we are planning to try out is to use constraints instead of transformations for ML. The optimization folks tell us that it is much better. We'll continue to use transformations for Bayesian but the issue here will probably not show up there.