Add epsilon to PositiveDefinite

[simsurace]

In contrast to Positive, the current PositiveDefinite type is not guaranteed to stay strictly positive as the unconstrained parameter goes to zero. This PR changes that to make the behavior of PositiveDefinite analogous to Positive, and introduces a new type for the existing behavior. Open questions:

• What is a good default value for epsilon? Positive uses sqrt(eps(T)), not sure where this is coming from. I picked eps(T) for now as the other one seemed too big.
• Is this considered breaking and if yes, is this a problem? Personally, I think that although this is technically breaking, this would not be too disruptive. If it is considered too breaking or a breaking release is not desirable, I would be perfectly happy to change naming such that the strict one becomes the one with a new name (e.g. StrictlyPositiveDefinite) and the existing name keeps behavior.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.43%. Comparing base (902fbe2) to head (0c5a728).

Additional details and impacted files

@@            Coverage Diff             @@
##           master      #72      +/-   ##
==========================================
+ Coverage   97.41%   97.43%   +0.02%     
==========================================
  Files           8        8              
  Lines         232      234       +2     
==========================================
+ Hits          226      228       +2     
  Misses          6        6              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[willtebbutt]

This is a really good point -- I'm kind of surprised we'd not encountered this before. Could we maybe just stick with a single positive definite type, but incorporate your change, rather than having two types? I think basically we're doing positive-definiteness incorrectly at the minute.

What is a good default value for epsilon? Positive uses sqrt(eps(T)), not sure where this is coming from. I picked eps(T) for now as the other one seemed too big.

No idea to be honest. I'm not aware of a way to pick a really good value. eps(T) seems fine -- users just have to make sure to pick it big enough for their problem.

Is this considered breaking and if yes, is this a problem? Personally, I think that although this is technically breaking, this would not be too disruptive. If it is considered too breaking or a breaking release is not desirable, I would be perfectly happy to change naming such that the strict one becomes the one with a new name (e.g. StrictlyPositiveDefinite) and the existing name keeps behavior.

If you're happy with modifying the existing PositiveDefinite type to make it actually positive definite and not adding an additional type, then I'm in favour of just tagging a breaking release.

[simsurace]

Ok, I removed the additional type and bumped the version.

[willtebbutt]

Great. Thanks! Please feel free to merge.