Raul,
On Fri, Nov 18, 2011 at 03:53:07PM -0500, Raul Miller wrote:
> Ok.. I hope we have not ruined anything here (to prevent people from
> googling this and studying up ahead of time, it would be best if the
> terminology were somewhat obfuscated). But, anyways...
I don't think it will be a problem, and it's too late anyway. :)
> There are a few fussy details here. Anyways, I do not know if this is the
> best way to organize the data, but it's an approach:
>
> input=: |: ".;._2 ('520' (a.i.'VTC')} a.) {~ a.i. 0 :0
> V 124.7 39.9 5
> C 125.9 40.8 3.5
> T 127.1 41.6 1.3
> C 128.4 42.4 3.5
> )
>
> scanindex=: #\
> scantype=: 0&{
> scantime=: 0&{ ([ + (0 = [) * ]) 20.5 - 2 * 3&{
> seektime=: (40 %~ 1&{) >. 20 %~ 2&{
> total=: seektime + scantime
>
> Thus:
> (scanindex,.scantype,.total,.seektime,.scantime) input
> 1 5 8.1175 3.1175 5
> 2 0 13.545 0.045 13.5
> 3 2 2.04 0.04 2
> 4 0 13.54 0.04 13.5
>
> This would need some additional formatting though, so:
>
> ('#',. ":@,.@scanindex,.':',.' ',.('C T V' {~scantype),.' ',.
> '8.3,8.3,8.3' 8!:2 total,.seektime,.scantime) input
> #1: V 8.118 3.118 5.000
> #2: C 13.545 0.045 13.500
> #3: T 2.040 0.040 2.000
> #4: C 13.540 0.040 13.500
>
> The parenthesized part probably deserves a name.
>
> The final line of the file would be:
>
> ([: +/ total,.seektime,.scantime) input
> 37.2425 3.2425 34
Thanks! I will study your implementation tonight.
> And, yes, I am computing some of the same values twice. (In general, I
> think it's a bad idea to prioritize efficiency over simplicity, but I make
> exceptions when efficiency becomes a problem.)
>
> That said:
>
> I have assumed that antenna starting position was 0 0. This might not be a
> valid assumption.
I thought I mentioned that, but I guess I did not. Yes, the starting
position is 0 0.
> some of these names seem long, the code might be easier to scan if relevant
> shorter names were available.
>
> I did not name the column extractors. In a larger problem, I probably
> would have (and I would try to make them visually distinct from other
> verbs.)
>
> I used a stunt to translate the non-numeric values into numbers (and
> another one to convert back). In general, homogeneous data is easier to
> work with than heterogeneous, especially if the homogeneous form has
> mnemonic value (which, luckily, was the case here). In the general case...
> I usually try to avoid solving the general case -- specific cases are much
> more tractable.
This is good advice and new to me.
> I do not know if the report should be formatted differently. Reports often
> involve finicky issues.
It's not that important.
> And, finally, my results look different from yours. So I do not know if I
> made a mistake.
The sample stuff I included in the email was cribbed from the middle
of the sample input and sample output I attached, so if that's all you
tested with, that is probably why. If you used the stuff I attached, I
would expect it to be because of not accounting for using the shorter
of clockwise or counterclockwise rotation, but I don't have the time
at the moment to figure out if you accounted for that or not.
Thanks so much for taking a crack at this! I'll be going over your
solution in detail!
--
Daniel Lyons
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
