I did not see anything attached, but forgot about that before I was ready
to reply.

And here's an overview of how I treated angle differences:

   degdif/~ 0 90 180 270 360
   0  _90 _180   90    0
  90    0  _90 _180   90
_180   90    0  _90 _180
 _90 _180   90    0  _90
   0  _90 _180   90    0

But, reading back, I never updated the definitions from my initial draft
(which just aimed at getting the right arguments in roughly the right
arrangement).  So here's the definitions which would actually generate the
results I posted:

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
)

degdif=: 360&|&.(+&180)@-
scanindex=: #\
scantype=: 0&{
scantime=: 0&{ ([ + (0 = [) * ]) 20.5 - 2 * 3&{
seektime=: (40 %~ 2 |@degdif/\ 0,1&{) >.  20 %~ 2 |@-/\ 0, 2&{
total=: seektime + scantime

FYI,

-- 
Raul

On Fri, Nov 18, 2011 at 4:17 PM, Daniel Lyons <[email protected]>wrote:

> 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
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to