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...
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
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.
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.
I do not know if the report should be formatted differently. Reports often
involve finicky issues.
And, finally, my results look different from yours. So I do not know if I
made a mistake.
--
Raul
On Fri, Nov 18, 2011 at 2:30 PM, Daniel Lyons <[email protected]>wrote:
> On Fri, Nov 18, 2011 at 12:49:55PM -0500, Raul Miller wrote:
> > I think that representative data, along with a description of the result
> > and purpose of the code would work. (Or, if not, that should be enough
> for
> > us to ask intelligent questions.)
>
> I've been disinclined to share the problem because it is intended to
> be used to help our organization make hiring decisions, as a kind of
> one-up FizzBuzz. It's inspired by this Mars Rover problem:
>
> http://thefundoowriter.wordpress.com/2009/10/01/the-mars-rover-problem/
>
> Anyway, I'm going to break the code of silence because I figure
> solutions in J are unlikely to be helpful to applicants where I work,
> since they have to code in Java anyway.
>
> The task is to simulate antenna motion for scans here at the VLA. We
> choose a very simplistic and unrealistic simulation. I have an input
> file that looks like this:
>
> 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
>
> This is a list of scans. The leading character is one of three values,
> C, T, and V representing Calibration, Target and Variable-length
> scans. The second and third values are the azimuth and elevation of
> the source to be scanned. (We ignore sidereal motion for the sake of
> this test, so they can be treated as absolute locations). The fourth
> value is the flux density, a radio astronomical unit of measure for
> brightness of a source.
>
> You're given the following facts:
>
> - an antenna can rotate at 40 degrees per minute
> - an antenna can ascend or descend at 20 degrees per minute
> - target scans take 5 minutes, calibration scans take 2 minutes
> - variable-length scans take -2 * (flux density) + 20.5 minutes
>
> The final output is to be a report. There is to be one line for each
> scan, something like this:
>
> #19: V 10.540 0.040 10.500
> #20: C 2.045 0.045 2.000
> #21: T 5.040 0.040 5.000
> #22: C 2.040 0.040 2.000
>
> So you have just the scan index, the total time of this scan, the "slew
> time" (time it took the antenna to move into position) and the
> on-source time. The last line of the report is aggregate information:
>
> 164.128 4.428 159.700
>
> This is the total time, total slew time and total on-source time for
> the whole file.
>
> I've attached a sample input and output for this problem if you'd like
> to take a crack at it. I had come up with the following parts, which
> probably are too bulky for seasoned J users, but here they are:
>
> NB. Geometry
> diff =: -`(-~) @. <
> minRotationDistance =: - <. &: (360&|) -~
>
> NB. Antenna simulation
> timeToRotate =: (%&40) @: minRotationDistance
> timeToAscend =: (%&20) @: diff
>
> Thanks for your patience! I appreciate all the help,
>
> --
> 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
