This procedure looks good to me. The server may assign the same (need client tie breaker) or different (server tie breaker) ordinal values. Works for me!
Richard On Saturday, June 6, 2015, Wendy Roome <[email protected]> wrote: > I naively assumed that it was easy to define & detect order conservation. > Ha! > > So how about this procedure: > > First, for all (src,dst) pairs, ord(src,dst) exists iff num(src,dst) > exists. > > Next consider the array of triples <num(src,dst), src, dst> for all > defined numerical costs. Sort this array by cost. > > Then do the same for the array of triples <ord(src,dst), src, dst>. > > Finally compare the two arrays. The src,dst entries must be in the same > order, except for sequences where the numerical cost is the same, in which > case they can be in any order within that sequence. > > BTW, that allows a server to assign unique ordinal values to break ties in > numerical values. > > - Wendy Roome > > From: "Y. Richard Yang" <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> > Date: Fri, June 5, 2015 at 12:36 > To: Wendy Roome <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> > Cc: "[email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');>" < > [email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');>> > Subject: Re: [alto] ALTO Interop test in July > > I see that there are duplicate values in Figure 2 (e.g., 75.0). A > question is to define the meaning of "preserve", as RFC7285 does not define > it, I believe. Here is an attempt in defining it precisely. First, for > non-equal case, we should have num[x] > num[y] => ord[x] < ord[y]. An issue > is if we define the case for num equal, e.g., num[x] == num[y] => ord[x] == > ord[y]. I assume that we have it? > -- Richard
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
