You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The proposed approach would work at least the way I see it. What are your thoughts @trulsf ? I do not see any issue with incorporating these, except for cases in which the profiles have different lengths.
In this case, we would need to have also @assert to check that the profiles have the same length. The error message for different length is:
prof_1 =OperationalProfile([1, 2, 3])
prof_2 =OperationalProfile([1, 2, 3, 6])
prof_1 + prof_2
ERROR: DimensionMismatch: arrays could not be broadcast to a common size: a has axes Base.OneTo(3) and b has axes Base.OneTo(4)
Do we consider the error message to be sufficiently descriptive?
I have also felt had the need for this quite recently, so maybe there is a need to add it.
For me the logical behavior is to ensure that
(prof1 + prof2)[t] == prof1[t] + prof2[t]
With the current practice of handling too short operational profiles by repeating the last entry, we need to consider this also when adding, e.g. we should have
We should also think through whether we should support combinations of profiles like OperationalProfile + FixedProfile.
There may also be some challenges if presented with more complex profiles on a strategic, scenario or representative level, e.g.
op =OperationalProfile([1, 2, 3])
rp =RepresentativeProfile([op, op])
sp1 =StrategicProfile([rp, op])
sp2 =StrategicProfile([op, op])
sp1 + sp2
The suggested implementation would generate a MethodError, but it is possible to imagine ways to define this by adding the OperationalProfile to each of the profiles of the RepresentativeProfile
With the current practice of handling too short operational profiles by repeating the last entry, we need to consider this also when adding, e.g. we should have
I am more inclined to remove this and instead provide an error if the profile is too short for the time structure. The current approach can, especially in the case of OperationalProfile, lead to potential problems if people are not aware of this behavior.
Activity
JulStraus commentedon Mar 23, 2026
The proposed approach would work at least the way I see it. What are your thoughts @trulsf ? I do not see any issue with incorporating these, except for cases in which the profiles have different lengths.
In this case, we would need to have also
@assertto check that the profiles have the same length. The error message for different length is:Do we consider the error message to be sufficiently descriptive?
trulsf commentedon Mar 24, 2026
I have also felt had the need for this quite recently, so maybe there is a need to add it.
For me the logical behavior is to ensure that
With the current practice of handling too short operational profiles by repeating the last entry, we need to consider this also when adding, e.g. we should have
We should also think through whether we should support combinations of profiles like
OperationalProfile + FixedProfile.There may also be some challenges if presented with more complex profiles on a strategic, scenario or representative level, e.g.
The suggested implementation would generate a MethodError, but it is possible to imagine ways to define this by adding the
OperationalProfileto each of the profiles of theRepresentativeProfileJulStraus commentedon Mar 24, 2026
I am more inclined to remove this and instead provide an error if the profile is too short for the time structure. The current approach can, especially in the case of
OperationalProfile, lead to potential problems if people are not aware of this behavior.trulsf commentedon Mar 26, 2026
I have opened a PR with changes in line with the one proposed here. @Zetison Please join the discussion there if you have suggestions for improvement.
trulsf commentedon Apr 13, 2026
PR is now merged (#92 ).