Skip to content

relfm_tabular

relationalai.semantics.reasoners.predictive.estimators

RelFMTabular: standalone flat-table RelFM — single Concept, no relational joins.

Deliberately independent of PredictiveEstimator/RelFM’s Concept+Relationship task abstraction. That shared abstraction requires context/validation to reference the same Concept (validate_task’s schema-match check compares field names, which default to the concept’s own name) — this class instead takes each split as its own Concept directly, with no requirement that they share an identity, since there is no join to align: each Concept’s full row set (identity + features + label, when present) is the flat table.

Forecasting: — forecast(domain=...) does need domain to carry pre-populated future (item_id, time) skeleton rows (no label column), same convention as predictions(domain=...). The forecast lands exactly on domain’s own (item_id, time) rows — there is no horizon parameter, each series may ask for its own dates. Output properties on prediction_concept: predicted_value (point estimate) plus, when quantile_levels is set, one quantile_<level> property per level (e.g. quantile_10) — plain attribute access.

Classification/regression and forecasting have disjoint constructor parameters (clamp_min/clamp_max/regression_output vs. time_column/ item_id_column/max_context_length) and disjoint validation (single natural key vs. composite (item_id, time) identity), so they’re split into RelFMTabularPredictor and RelFMTabularForecaster — two subclasses of a shared _RelFMTabularBase — rather than one class branching on task_type throughout. RelFMTabular(...) is a thin factory that dispatches to whichever one matches task_type, so existing call sites don’t need to know about the split.

Submodules: base (shared plumbing), predictor/forecaster (the two concrete estimators), factory (the RelFMTabular(...) dispatcher).

Functions

Functions exposed by this module.

Classes

Classes exposed by this module.