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
There are different representations (that is, set of linear segments) for specific curve shapes, in particular the ones we offer convenient create* methods for -- see details and example below.
The create* methods create the according function in one specific way of representing it. Exactly this way is required to trigger the shortcuts in the code, e.g., to identify the "zero delay, infinite burst" curve as the neutral element of convolution. Calling the beautify() method does not map alternative representations to the one chosen for the create* methods (needs further investigation, but I am fairly certain). Unfortunately, neither these shortcuts nor using the generic code path for special curves is covered by our tests. Thus, I am not certain if this issue is a bug report or a feature request ... (there had been a related bug, reported by GSI, and fixed in v2.2.8).
Details and example: Take the implementation of "delayed infinite burst" curve with delay d in Curve_DNC.java. The is makeDelayedInfiniteBurst method creates these two segments:
(x1,y1)=(0,0), rate=0 leftofen=false
(x2,y2)=(d,+infty), rate=0, leftofen=true
Checking for this shape invokes Curve_DNC's equals method that iterates over these segments, calls LinearSegment's equals that, in turn, only checks if the above values match one by one as it does not know the context of belonging to a "delayed infinite burst" curve. However, in this context some values do not matter: the rate (>=0) of the second segment is irrelevant as its y-coordinate is already +infty (ok, this actually holds independent of the context).
Also, in other context, there are other irrelevant values. Take the "zero delay, infinite burst" curve where the rate of the first segment does not matter as it is actually only the point in the origin.
The same overall situation might apply to zero{Arrivals,Service} and potentially others.
The text was updated successfully, but these errors were encountered:
There are different representations (that is, set of linear segments) for specific curve shapes, in particular the ones we offer convenient create* methods for -- see details and example below.
The create* methods create the according function in one specific way of representing it. Exactly this way is required to trigger the shortcuts in the code, e.g., to identify the "zero delay, infinite burst" curve as the neutral element of convolution. Calling the beautify() method does not map alternative representations to the one chosen for the create* methods (needs further investigation, but I am fairly certain). Unfortunately, neither these shortcuts nor using the generic code path for special curves is covered by our tests. Thus, I am not certain if this issue is a bug report or a feature request ... (there had been a related bug, reported by GSI, and fixed in v2.2.8).
Details and example: Take the implementation of "delayed infinite burst" curve with delay d in Curve_DNC.java. The is makeDelayedInfiniteBurst method creates these two segments:
Checking for this shape invokes Curve_DNC's equals method that iterates over these segments, calls LinearSegment's equals that, in turn, only checks if the above values match one by one as it does not know the context of belonging to a "delayed infinite burst" curve. However, in this context some values do not matter: the rate (>=0) of the second segment is irrelevant as its y-coordinate is already +infty (ok, this actually holds independent of the context).
Also, in other context, there are other irrelevant values. Take the "zero delay, infinite burst" curve where the rate of the first segment does not matter as it is actually only the point in the origin.
The same overall situation might apply to zero{Arrivals,Service} and potentially others.
The text was updated successfully, but these errors were encountered: