Skip to content

Normalize scalar types for prior, likelihood, and posterior in Link#69

Open
marie-cloet2000 wants to merge 1 commit intomikkelbue:mainfrom
marie-cloet2000:link-input-type
Open

Normalize scalar types for prior, likelihood, and posterior in Link#69
marie-cloet2000 wants to merge 1 commit intomikkelbue:mainfrom
marie-cloet2000:link-input-type

Conversation

@marie-cloet2000
Copy link
Copy Markdown

Fixes #68

Summary

This PR normalizes the types of prior and likelihood in the Link class to ensure they are always scalar values. This prevents downstream failures in diagnostics (specifically to_inference_data) caused by mixing Python scalars
and 1‑element NumPy arrays.

Motivation

While Link.prior, Link.likelihood, and Link.posterior are documented as floats, in practice prior (and therefore posterior) can be passed in as a 1‑element NumPy array depending on the prior implementation. This leads to
inconsistent types:

  • prior: np.ndarray with shape (1,)
  • likelihood: Python float
  • posterior: np.ndarray with shape (1,)

When diagnostics attempt to stack these values into a NumPy array, this results in a ValueError due to inhomogeneous shapes.

Changes

  • Explicitly normalize prior and likelihood to scalar values in Link.__init__
  • Raise a clear error if non‑scalar values are provided
  • Use NumPy‑recommended scalar extraction (.item()) to avoid deprecation warnings

Impact

  • Backward‑compatible for existing code
  • Preserves current semantics of log‑densities as scalars
  • Makes to_inference_data robust to different prior implementations

Notes

I used Microsoft Copilot for suggestions on how to improve the code and to write this PR message.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Inconsistent scalar vs. array types for prior / likelihood / posterior in Link cause to_inference_data to fail

2 participants