This group is locked. No changes can be made to the group while it is locked.
Re: ALTO in ODL Planning
Y. Richard Yang
Shu, Thanks for the update! Please see below. On Tue, Apr 21, 2015 at 11:12 PM, 董舒 <dongs2011@...> wrote:
Great!
Thanks.
I will review tomorrow.
Let me understand. What is a goal of defining a default cost field? Or you are suggesting that there is a default cost field, say numerical, and then use augment to change (or add) it into another type, when it is, say, ordinal? My understanding is that augment can only add (https://tools.ietf.org/html/rfc6020#section-7.15). For efficient storage, in terms of Java classes, I feel that a possible definition of a cost-map is the following: Inner level is from string (dst pid name) to the type such as a float (numerical) or int (ordinal) or vector (path-vector): HashMap<String, Integer> or HashMap<String, Double> or HashMap<String, Vector>, .. Outer level is a hash map from string (src pidname) to the inner level hashmap, e.g., HashMap<String, HashMap<String, ValueType>> A very dumb inheritance based design is is: class CostMapBase { // base field (meta) } class CostMapInt extends CostMapBase { HashMap<String, Integer> costmap; } class CostMapDouble extends CostMapBase { HashMap<String, Double> costmap; } Or if one uses the containment design: class CostMap<ValueType> { // meta HashMap<String, HashMap<String, ValueType>> costmap; } I believe that the augment mapping is based on inheritance. Hence, to simulate the first design, the augment defines the whole hashmap of hashmap. Make sense? Richard
|
|