Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!europa.asd.contel.com!gatech!udel!haven.umd.edu!socrates.umd.edu!socrates!rockwell From: rockwell@socrates.umd.edu (Raul Rockwell) Newsgroups: comp.lang.apl Subject: Re: Grade Down Columns of An Array Message-ID: Date: 22 Jun 91 17:46:41 GMT References: <33789@usc.edu> Sender: rockwell@socrates.umd.edu (Raul Rockwell) Organization: Traveller Lines: 43 In-Reply-To: rockwell@socrates.umd.edu's message of Fri, 21 Jun 1991 13: 05:48 GM Just a couple second thoughts on the sorting method I mentioned in my last post. First, one does not need to to transpose the array before ravelling it. Since the sort will totally reorder the array, and since the key I provided results in a transposed array after sorting, the initial transpose is redundant. (Though it is probably useful conceptually). Second, the normalization technique I used wouldn't work if you wanted to maintain the relative positions of "identical" elements. I think this might be significant with floating point values, because of the effects of comparison tolerance. Also, I mistyped at least one bug into the code. So, ammended code (same puns as before): vec <- , array vec =. , array normalized <- \|/ \|/ vec normalized =. \: \: vec colHorder <- - (R vec) x (R array)R i (R array)[1] col_order =. - (# vec) * ($ array)$ i. 1{$ array grade <- \|/ colHorder + normalized grade =. \: col_order + normalized sorted <- vec [ (\) ( (|) R array ) R grade ] sorted =. vec {~ |: ( |. $ array ) $ grade (the typo in my prior post, by the way, was where I used 'array' rather than 'vec' to compute 'normalized') Finally note that my use of intermediate variables is purely stylistic -- all of these values could be computed on the fly (though there may be a significant cost associated with computing 'vec' on the fly in some dialects of APL). -- Raul