Closed kenkoooo closed 4 years ago
For Cap
and Cost
-- in theory we can use a different type for Cap
, Cost
and Result
type where Result : From<Cap> + From<Cost>
.... which can be useful for problems like this, though probably overkill for almost all other problems.
Another use case would be non-integral cost problems. Since having non-integral capacity is problematic for this algorithm, it would make sense to separate these two type params, and use
Actually floating point types in Rust doesn't implement Cost
type for product of them.Ord
, so..... nevermind.
For
Cap
andCost
-- in theory we can use a different type forCap
,Cost
andResult
type whereResult : From<Cap> + From<Cost>
.... which can be useful for problems like this, though probably overkill for almost all other problems.~Another use case would be non-integral cost problems. Since having non-integral capacity is problematic for this algorithm, it would make sense to separate these two type params, and use
Cost
type for product of them.~ Actually floating point types in Rust doesn't implementOrd
, so..... nevermind.
Thanks! Let's keep using a single type parameter for now.
Port
mincostflow
from the AtCoder's library, resolved #21.Questions
Cap
andCost
as the same type. Is it better to separate types?Integer
trait. Does it make sense?