Closed matyesz closed 5 years ago
Currently, we have shortcuts to create some commonly used curves in v2.5's Curve.java.
and in Curve_PwAffine's interface, we have:
I am open to extend this to a larger reasonable set. But issue #7 should be kept in mind. The is{TokenBucket,RateLatency} can probably be moved to the Curve Interface.
For the get{...} methods, we need to take a good look in comparison to Num. As mentioned, they are supposed to return special constants, for example a number created with the Num class. But in contrast to the numbers, most curves need to be instantiated with parameters (e.g., the token buckets and rate latencies above). I.e., they are not entirely constant. That leaves getZero{Arrivals,DelayedInfiniteBurst,DelayedInfiniteBurstMSC} and getInfiniteArrivals. Immutable constants of those can indeed help reduce the overhead of computations the same way the Num constants do.
As for all constants in Java we could create an enum where constanst can have parameters and comparison is easier. We could also use them in switch-cases and not depending on the parameter we could make decisions.
Sounds good, in particular considering my failed attempt in pull request #49 (curves depend on the num backend that might change during runtime). Thinking about issue #7, I wonder how deep the comparison inspects the curve in contrast to the equals method. That is required in case the special curve was created using the non-standard way. E.g., you can create an infinite service by first creating a zero-rate service curve and later adding a second segment with infinite burst, starting at x=0 (excluded). We'd only recognize it as a zero delay, infinite burst when using the equals method.
For illustration, the NumBackend is a good example. There, we provide Num create{Zero,PositiveInfinity,NegativeInfinity} as well as Num get{Zero,PositiveInfinity,NegativeInfinity}. Moreover, there we have the boolean is{Zero,PositiveInfinity,NegativeInfinity}.