Disallow duplicate regulators

Vectornaut commented

2025-02-27 19:26:15 +00:00

Member

As of pull request #46, it's possible to add two regulators of the same kind with the same subjects. For the kinds of regulators we're currently envisioning, duplication isn't useful, and it can lead to surprising or annoying behavior when duplicate regulators have conflicting set points. We should prevent duplicate regulators from being created.

If we become confident that we'll never want duplicate regulators of any kind, we might consider storing regulators in a hash map, using each regulator's kind and subjects as its key. The prohibition of duplicate regulators would then be built into the data structure. Whether this is a good idea might depend on how we address issue #55.

As of pull request #46, it's possible to add two regulators of the same kind with the same subjects. For the kinds of regulators we're currently envisioning, duplication isn't useful, and it can lead to surprising or annoying behavior when duplicate regulators have conflicting set points. We should prevent duplicate regulators from being created. If we become confident that we'll never want duplicate regulators of any kind, we might consider storing regulators in a hash map, using each regulator's kind and subjects as its key. The prohibition of duplicate regulators would then be built into the data structure. Whether this is a good idea might depend on how we address issue #55.

Vectornaut referenced this issue

2025-02-27 19:31:34 +00:00

Generalize constraints to observables #48

glen commented

2025-02-28 23:59:07 +00:00

Owner

@Vectornaut wrote in glen/dyna3#60 (comment):

If we become confident that we'll never want duplicate regulators of any kind, we might consider storing regulators in a hash map, using each regulator's kind and subjects as its key. The prohibition of duplicate regulators would then be built into the data structure. Whether this is a good idea might depend on how we address issue #55.

It's my expectation that we won't ever want duplicates. But if you want to wait to address this issue until after we resolve #55, go ahead and set the dependencies however represents that. Not 100% sure if you make this dependent on #55 or vice versa, but I think the former.

@Vectornaut wrote in https://code.studioinfinity.org/glen/dyna3/issues/60#issue-463: > If we become confident that we'll never want duplicate regulators of any kind, we might consider storing regulators in a hash map, using each regulator's kind and subjects as its key. The prohibition of duplicate regulators would then be built into the data structure. Whether this is a good idea might depend on how we address issue #55. It's my expectation that we won't ever want duplicates. But if you want to wait to address this issue until after we resolve #55, go ahead and set the dependencies however represents that. Not 100% sure if you make this dependent on #55 or vice versa, but I think the former.

Vectornaut added a new dependency 2025-03-01 00:37:20 +00:00

glen/pocomath#55 - With return types, specifications of implementations are too complicated

Vectornaut removed a dependency 2025-03-01 00:37:35 +00:00

glen/pocomath#55 - With return types, specifications of implementations are too complicated

Vectornaut added a new dependency 2025-03-01 00:38:06 +00:00

#55 Introduce curvature regulators

Rows
Columns

Disallow duplicate regulators #60