Feature/451 ssp linear transformations

[markaren]

Closes #451

Should add test, but want to hear feedback first.

[kyllingstad]

I like it!

I'd prefer we avoid protected member variables, though, so my recommendation would be to implement linear_transformation_connection::set_source_value() in terms of scalar_connection::set_source_value() instead of accessing scalar_connection::value_ directly.

[eidekrist]

Nice!

[markaren]

I take it that the positive feedback means we agree on this approach?

Add test, and then we have an approval?

[kyllingstad]

Should we require that all features that we implement for SSP must also be implemented for OspSystemStructure? Since we have defined the latter as our primary format, it would perhaps seem strange if the SSP support wasn't a subset of that.

[markaren]

Should we require that all features that we implement for SSP must also be implemented for OspSystemStructure

I think this is to strict. What if OspSystemStructure strays way off compared to SSP, then it may be very difficult to support potential useful fetatures/changes defined in e.g. SSP 2.0.

However, this particular feature should definitively be supported in both. But not necessarily in the same PR.

If it was up to me though, OspSystemStructure would be a superset of SSP. Like YAML to JSON.

[markaren]

If it was up to me though, OspSystemStructure would be a superset of SSP. Like YAML to JSON.

Chew on that a little bit. That would in practice mean that we could use the same parser for both formats.

[eidekrist]

I'm happy with approving this once a test is in place. This feature should definitely be available for OspSystemStructure as well, so I have created #465.

On the topic of OspSystemStructure as a superset of SSP, that's a clear no from me for the time being. Might be worth revisiting after the project is concluded.

[eidekrist]

@kyllingstad: Should we require that all features that we implement for SSP must also be implemented for OspSystemStructure? Since we have defined the latter as our primary format, it would perhaps seem strange if the SSP support wasn't a subset of that.

Agreed. We don't have that much time left in this project, and I would even say that OspSystemStructure should always come first, and SSP at best second.

[markaren]

Unless SSP is abandoned, I reckon it will continue to be favored from mine and NTNUs side.

[eidekrist]

Looks OK!

[eidekrist]

Next time please wait for approval before merging.

[markaren]

I took your last comment as an approval. Sorry about that.

[eidekrist]

Might be interesting for future usage/debugging: The tolerance parameter (1e-9 here) represents a percentage value.

[markaren]

Auch. Well, we'll fix that. What would a decent value here be?

[markaren]

Might be interesting for future usage/debugging

Nice thing about Boost.test vs the others tests is that the what and where is shown, so it would not have been difficult to see what happened.
Anyway fixed in: #472