The Challenge: Printer Queue

The only printer in the computer science students' union is experiencing an extremely heavy workload. Sometimes there are a hundred jobs in the printer queue and you may have to wait for hours to get a single page of output.

Because some jobs are more important than others, the Hacker General has invented and implemented a simple priority system for the print job queue. Now, each job is assigned a priority between 1 and 9 (with 9 being the highest priority, and 1 being the lowest), and the printer operates as follows.
  • The first job J in queue is taken from the queue.
  • If there is some job in the queue with a higher priority than job J, then move J to the end of the queue without printing it.
  • Otherwise, print job J (and do not put it back in the queue).

In this way, all those important muffin recipes that the Hacker General is printing get printed very quickly. Of course, those annoying term papers that others are printing may have to wait for quite some time to get printed, but that's life.

Your problem with the new policy is that it has become quite tricky to determine when your print job will actually be completed. You decide to write a program to figure this out. The program will be given the current queue (as a list of priorities) as well as the position of your job in the queue, and must then calculate how long it will take until your job is printed, assuming that no additional jobs will be added to the queue. To simplify matters, we assume that printing a job always takes exactly one minute, and that adding and removing jobs from the queue is instantaneous.

This, if the queue look like "1 2 3 4" and your job is in postion 2, then it'll take 2 minutes until your job is printed.

In case of the queue being "1 1 9 1 1 1" and your job in position 0 (the first slot), it'll then take 5 minutes as your job and the job after you move all the way back in the queue in order to make room for the higher-priority job in slot 2.

A download is available at http://s91376351.onlinehome.us/kixtart/kixgolf_pq.zip

Inputs & Outputs

Input: One string with n space-separated integers (1<= n <= 100) in the range 1 to 9, giving the priorities of the jobs in the queue. The first integer gives the priority of the first job, the second integer the priority of the second job, and so on. One integer (0<= m <= n-1) denoting the position of your job in the queue.

Output: A single integer; the number of minutes until your job is completely printed, assuming that no additional print jobs will arrive.


The solution must pass all tests in order for it's KiXgolf Score to be considered.

When posting KiXtart Golf Scores, please include the KIXGOLF_*.TXT file that is created in the script directory. It contains some basic information about the computer that the script is run on and the resulting scores.

Test program

Test cases are provided to help screen entries and to provide the Golf Score.
Any script that passes the test cases can be submitted. If you are surprised that your solution passed the test cases, please submit it anyway! That will help me identify bugs in the test program.

KiXtart GOLF - How To Play

Most importantly, anybody can play, no age restrictions, no penalties, no handicap!

The object in "real" golf is to hit the ball in the hole in the fewest strokes. The object in KiXtart Golf is to get from input (tee) to target (hole) in the fewest keystrokes.

Example: How many positive elements are in array $a?

Array $a could be of structure $a=[1, 2 ,-3, 4, -5, -7, 8, 9]

One approach:
for $b=0 to ubound($a)
  if $a[$b]>0

for a score of 45.

Another solution is:
  if $a[$b]>0
UNTIL $b>(UBOUND($a)+1)

for a score of 53.

Better approach: Code sample 1

KiXtart GOLF - The Rules

1) The goal of KiXtart Golf is to score the lowest strokes.
2) Strokes are all characters in a piece of code except whitespace characters, unless the whitespace character is necessary for the line of code to work. Therefore, carriage returns and line feeds do not count or spaces in between the '=' sign when assigning variables, e.g. '$a = $b' scores 5.
3) Code can be constructed any way you like, as long as it does not generate syntax or other errors when running the script in KiXtart.
4) The final solution MUST pass all test scripts that are part of the KiXtart golf challenge.
7) During the private coding phase, no code is allowed to be posted. Violations result in disqualification of said player.
8) During the public coding phase, code should be posted, reused, and borrowed from other players.
9) The test script contains the official KiXgolf scoring engine
10) Only the person posting a particular score will be recognized for the score, unless the KiXtart Golf Challenge organizer or another delegate posts code on behalf of a player
11) KiXtart Golf (a.k.a KiXgolf) codes must be written inside the KiXgolf UDF collection tags, ';!' and ';!;!' and must be eclosed by the FUNCTION commands
12) Parameter names of the UDF's can be changed and additional optional parameters can be added.
13) Additional helper UDFs can be written as long as they reside inside the ';!' and ';!;!' tags.
14) The use of '$' as a variable is allowed.
15) The UDF layout is up to coder.
16) The UDF is expected to finish in a reasonable time, that is, on modern computers inside 1 hour timeframe.
17) You can submit scores as often as you want.
18) If you reach leading score, you are obligated to post your score immediately so others can try to compete with you.
19) The UDF may only use the KiXtart/KiXforms commands/functions/macros, no other code fragments are allowed.
20) Calls to COM components that are part of a standard default Windows installation are allowed.
21) The use of the KiXforms DLL is also permitted as the KiXforms DLL can now be considered an integral part of KiXtart scripting.
22) Calls to other executables, as long as they are part of a standard default Windows installation are allowed.
23) The UDF should be self-contained (except for any I/O mentioned in the challenge). In particular, you may not do things like fetching extra data from a remote site or file.
24) You may assume ASCII as character set.
25) You may use block comments as the KiXgolf Scoring Engine now supports block comments.
26) You are allowed to only use publicly available versions of KiXtart and KiXforms, private builds or alpha builds are NOT allowed.
27) Your submitted score must include the result print of the KiXgolf test-engine.
28) The SETOPTION() parameters in the KiXgolf script may not be modified and will govern the script behavior. SETOPTION() parameters may change depending on the particular needs of the KiXgolf challenge.
29) Tokenizing the UDF, script, or portions thereof is not allowed.
30) If something is not explicitly denied by the rules, it's allowed.
31) If Confusion arises, arranger of the KiXgolf round has the final say.
32) Additional test cases can be added during the private round by submitting a proposal for a new test case to the BBS. The proposed test case becomes official once it has been added to the existing test cases and the KiXgolf package has been reposted for download. If new test cases are added within 12 hours of private round end the private round will extend by an additional 24 hours. The public round will then start one day later and also end one day later. Not additional test cases will be added during the public round.

KiXtart GOLF - The Duration of the Competition

1) Private coding phase: From date/time of posting the tournament challenge to November 14, 6pm EST (BBS+6 time)

2) Public coding phase: From November 14, 6pm EST (BBS+6 time) to November 18, 6pm EST (BBS+6 time)

3) Final results: November 19, 11pm EST (BBS+6 time)

You will need the complete package from http://s91376351.onlinehome.us/kixtart/kixgolf_pq.zip.
There are two types of vessels, submarines and targets.