Skip to content

docs update on tendency inference#174

Open
DaanVanVugt wants to merge 1 commit into
iterorganization:developfrom
DaanVanVugt:feature/infer-tendency-type
Open

docs update on tendency inference#174
DaanVanVugt wants to merge 1 commit into
iterorganization:developfrom
DaanVanVugt:feature/infer-tendency-type

Conversation

@DaanVanVugt

Copy link
Copy Markdown
Contributor

When a tendency entry has no explicit type, infer it from its keys
instead of always defaulting to linear: to -> linear, time ->
piecewise, value -> constant. Anything else falls back to linear, so a linear tendency does not require to (a from-only/rate-only/bare segment is still linear and takes its endpoints from its neighbours).

A segment whose distinguishing key is absent must name its type explicitly: the periodic shapes, smooth, and a value-less constant (a bare {duration} is read as a linear ramp).

Documents the behaviour (yaml_format + tendencies) and tests the inference, the linear-without-to forms, the value-less ambiguity, and that an explicit type takes precedence.

@SBlokhuizen SBlokhuizen left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! I just have 2 minor comments about the documentation.

Comment thread docs/source/tendencies.rst Outdated
Comment thread docs/source/yaml_format.rst Outdated
@DaanVanVugt

Copy link
Copy Markdown
Contributor Author

later prs introduce new tendencies, we should remember to include new auto-identification for these

@DaanVanVugt
DaanVanVugt requested a review from SBlokhuizen June 25, 2026 12:48
Point the type-inference refs at the per-tendency sections (added
labels for constant/linear/smooth/periodic) instead of the page-top
anchor, and drop the duplicated inference description in yaml_format
in favour of the Available Tendencies page.
@DaanVanVugt
DaanVanVugt force-pushed the feature/infer-tendency-type branch from d6e8744 to 4dbbc5d Compare July 10, 2026 09:48
@DaanVanVugt DaanVanVugt changed the title Infer tendency type from keys when type is omitted docs update on tendency inference Jul 10, 2026
Each tendency defines the behavior of the signal over a specific time interval. You can chain multiple tendencies together to create complex waveforms.

If ``type`` is omitted it is inferred from the entry's keys: ``ref`` → :ref:`import <import-tendency>`, ``to`` → linear, ``time`` → :ref:`piecewise <piecewise-linear-tendency>`, ``value`` → constant; anything else defaults to ``linear`` (so a ``from``-only, ``rate``-only, or bare segment is still a linear ramp). Tendencies with no distinguishing key -- the periodic shapes, ``smooth``, and a value-less ``constant`` -- must name their ``type`` explicitly.
If ``type`` is omitted it is inferred from the entry's keys: ``ref`` → :ref:`import <import-tendency>`, ``to`` → :ref:`linear <linear-tendency>`, ``time`` → :ref:`piecewise <piecewise-linear-tendency>`, ``value`` → :ref:`constant <constant-tendency>`; anything else defaults to ``linear`` (so a ``from``-only, ``rate``-only, or bare segment is still a linear ramp). Tendencies with no distinguishing key -- the :ref:`periodic shapes <periodic-tendencies>`, :ref:`smooth <smooth-tendency>`, and a value-less :ref:`constant <constant-tendency>` -- must name their ``type`` explicitly.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would make a lot more sense with a small example in my opinion.

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.

3 participants