|
|
|||||||
Rule Change: Due to some discussion during the tournament the second constraint has been changed. You no longer need to 'minimize' the gap. It is sufficient if the gap is less than 1 minute All documentation has been updated accordingly and the KIXGOLF_CD.ZIP package also reflects this rule change. My apologies. It's time for another round of KiXGolf! Todays course will delight all the avid music-listeners under the KiXGolfers as we create custom CDs with your favorite songs. I will also tell you how to turn KiXtart into a CD Burner!. Okay, the last sentence is wrong. However, I think you'll find a nice challenge ahead. Please download the complete KiXGolf "CD Sorter" package at http://people.bu.edu/jenmeyer/kixtart/kixgolf_cd.zip This package contains all the files required to run play KiXGolf, including the datasets and scoring engine. Please use the RESULTS.TXT file, that is generated after running the KiXGolf script to post your scores. This will guarantee that you post vaild scores and provide some helpful info to your competitors. I have one hint for you guys: Whoever has ever heard about the famous gambling state at the Mediterranean knows how to play the KiXGolf course. ============= The Challenge ============= You work for a large record company that markets a line of greatest hits compact discs --- "Super Funk of the 70s", "Partridge Family Unlimited", "3 Tenors in Antarctica, Again!". For each CD, you have a list of possible songs, their lengths, and the CD's maximum length. You would like each CD to be as close to full as possible, but you have a large catalog of songs to fill, in anticipation of an 80's revival. It's okay to leave a bit of empty space on each CD to get the job done quickly. You have decided to use KiXtart to determine the set of songs for each CD. Thanks to the folks at The Mathworks who created the original BINPACK challenge on which this KiXGolf challenge is based on. Download the complete KiXGolf "CD Sorter" package at http://people.bu.edu/jenmeyer/kixtart/kixgolf_cd.zip ============= Specification ============= You will be provided with a list, in comma-delimited string form, of song times, and the length of a CD. Not all the songs will fit on the CD. Your job is to return a single string of comma-delimited indices into that list of the songs you have chosen for this CD. The sum of the song times that you select should not be greater than the provided media length. You need not use all of the provided songs; there may be more songs than you have space for on a single CD. There were a lot of great disco songs, but you only want to produce a single disco CD. However, you can only use each song once per CD. In KiXtart syntax, the function header should look like this: code:More precisely, given a comma-delimited list of arbitrary indices, songList, find an array of indices, indexList, such thatfunction CD_Sorter(songList, mediaLength)
Example =======If songList = '10.2,30,14,20.8', with a target time of mediaLength = 45, then a good solution is to pick the elements 30 and 14, since 30 + 14 = 44, which is very close to 45. Therefore, indexList = '2,3', since songList(indexList) = '30,14' and sum(songList(indexList)) = 44, leaving a gap of 1 minute on the CD. Not bad, however, the constraints call for a gap of less than 1 minute. The optimal solution indexList = '1,3,4' leaves a gap of 0. Remember, that the songs are numbered starting at 1, there is no song 0! Song 1 has length 10.2, Song 2 has length 30, and so on. ======= Scoring ======= The optimim media lengths for all CDs have already been calculated. Your results will be compared to this optimized set of CDs to determine how good your algorithm is. You might also be able to develop an algorithm that features an even better optimization. ============= General rules =============
======== Deadline ========The game starts March 8, 2003 (3:00pm EST) and ends March 23, 2003 (3:00pm EST). ============ Test program ============ A test program is provided to help screen entries and to provide the Golf Score. Any program that passes the test program can be submitted. If you are surprised that your solution passed the test program, please submit it anyway! That will help me identify bugs in the test program. =================== Special Recognition =================== Special recognition for the person who first optimizes all CDs! ================================================================ 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: code:for a score of 45.for $b=0 to ubound($a) Another solution is: code:for a score of 53.DO 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 is syntactically correct with KiXtart. 4) The final solution MUST pass all test scripts that accompagny the KiXtart golf challenge. 5) The use of '$' as a variable is allowed. 6) In case of questions about a particular way to count the KiXtart Golf Challenge organizer has the last call. 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 following script can be used to count the KiXtart Golf score: http://www.kixtart.org/cgi-bin/ultimatebb.cgi?ubb=get_topic;f=2;t=003608 ================================================================ KiXtart GOLF - The Duration of the Competition ================================================================ 1) Private coding phase: From date/time of posting the tournament challenge to the following Sunday, 3pm EST (BBS+6 time) 2) Public coding phase: From Sunday, 3pm EST (BBS+6 time) to the following Sunday, 3pm EST (BBS+6 time) 3) Final results: Sunday, 3pm EST (BBS+6 time) Here's the KiXGolf code used to score the challange. however, you will need the complete package from http://people.bu.edu/jenmeyer/kixtart/kixgolf_cd.zip code:; KiXtart Golf [ 13. March 2003, 00:24: Message edited by: sealeopard ] |
||||||||
|
|
|||||||
Looks nice... One day too early??? {edit - ignore second line, was confused by title in Announcement: New KiXGolf on 3-9-03 } [ 08. March 2003, 22:31: Message edited by: MightyR1 ] |
||||||||
|
|
|||||||
Oops, that must have been a typo. I meant the Saturday. I usually start the tournaments on Saturdays. I'm going to correct this. [ 12. March 2003, 22:59: Message edited by: sealeopard ] |
||||||||
|
|
|||||||
Me Oops too... the post actually tells it's on saturday |
||||||||
|
|
|||||||
Corrected a bug in the script. Running just one randomly chosen CD would't have worked, this has bene corrected. ZIP package has been updated and can be downloaded at http://people.bu.edu/jenmeyer/kixtart/kixgolf_cd.zip |
||||||||
|
|
|||||||
Jens, How can I accomplish running just 1 CD?? code:If I try this, I get an error in line 75:; boolean to run the test just once for a randomly choosen CD code:ERROR : array reference out of bounds! |
||||||||
|
|
|||||||
Patrick: Sorry for that. Please see the correct lines 74-75 for the main loop below. I have also uploaded a corrected ZIP package under http://people.bu.edu/jenmeyer/kixtart/kixgolf_cd.zip code:$iCDNum=rnd($iNumCDs-1) |
||||||||
|
|
|||||||
Sorry Jens, still no go... if I make $iLoops=1 and $iRandomCD=1 I get this (do not count this as a score!!!): code:KiXtart |
||||||||
|
|
|||||||
That is actually the default result for the empty CD Sorter UDF as it returns an empty string. The reason why the checking algorithm says it processed 12 CDs even though you run only one CD though the sorter UDF is that all CDs are checked for valid lists of indices. If you wish, I can update the code that if you run only one CD through the CD sorter, that only that one CD is checked for validity. I have updated the code and all console output is now also included in the RESULTS.TXT file. You will see the results for each of the CDs separately in addition to the aggregate results. Do you already have an idea how to solve it? [ 10. March 2003, 00:25: Message edited by: sealeopard ] |
||||||||
|
|
|||||||
are all songtimes assumed to be given in floating point form or do we need to translate them? |
||||||||
|
|
|||||||
Will take a look at the new code. And Yes, got an idea... Want to check every possible solution (will take long time on CD12 I know). Not just a guess like your "hint" says... |
||||||||
|
|
|||||||
so, don't want to scan the entries... jens, do you have a list of songs times where multiple songs have exactly same time? |
||||||||
|
|
|||||||
jens did real killer for us. freaking it takes zillion minutes to execute... |
||||||||
|
|
|||||||
yeah, with only 9 songs, one list takes to scan without any calculations over an hour! I give up. |
||||||||
|
|
|||||||
Don't give up... Take a look at Jens' Hint. Jens may I say what gambling area you're referring too??? |
||||||||
|
|
|||||||
Re: Hint I'm referring to that gambling area that is also a popular spot for e.g. artists, royalties, non-tax-payers, and people we sometimes want to be. Re: Hint (again) Yes, potential solutions to the hint I provided can be posted, though this might lead to the resurfacing of unwanted memories of long time past when you were back in high-school or college As usual, I do not take any responsibility with the effects of participating in KiXGolf. Re: Songtimes All song times are floating point numbers with four digits of precision. However, you can use any numbering type internally as only the song numbers are required as output. For example, multiplying each song length by 10000 (and the media length of 45, too) will result in all integer numbers. However, whether that provides any advantage over using floats remains to be seen Might cut down on keystrokes, though, as you don't need to convert things to floats. |
||||||||
|
|
|||||||
Jooel: Can you elaborate on quote:What do you mean with scan? What is it scanning that takes an hour? |
||||||||
|
|
|||||||
jens, I wont tell anyway, even though my alghorithm is pretty slow I'm almost there... just some trouble with floating point units and to be able to post my results, I need to install some software on my firewall (the machine I write on now)... |
||||||||
|
|
|||||||
Joeel has brought to my attention a potential problem with the datasets. The datasets are comma-delimited floating point numbers of the songlengths. This means that e.g. 1.2345 (1 2345/1000 seconds) in the American English localization is 1,2345 in most European localizations. |
||||||||
|
|
|||||||
Not perfect... Optimization needed... code:Average CD Length = 37.35 |
||||||||
|
|
|||||||
you bastard! damn, I made myself a quicker engine and realized that it skipped a lot of stuff. jens, I think we could include the execution time in the engine to compare... |
||||||||
|
|
|||||||
Execution time varies based on hardware used and also the specific algorithm. There are three distinct algorithms that can be used to solve this particular problem. One can use each of the algorithms by itself or combine them to achieve greater accuracy. Anyway, I'll make a modification to the scoring screen to include both the start and stop time of the runs instead of just date/time. However, take those times with a grain of salt. I will post an updated package later today once I'm back home as I have all the material at home. Finally, though Patrick posted the first working version, the algorithm can still be improved. I'm waiting for the person to completely optimize all CDs [ 10. March 2003, 20:56: Message edited by: sealeopard ] |
||||||||
|
|
|||||||
Mine wasn't a real algorithm... Since much of improvement, I'm going for 'Perfect CD Sorter'... |
||||||||
|
|
|||||||
Patrick: A) Your routine worked! B) You beat Joeel! What else can you ask for? |
||||||||
|
|
|||||||
2b "perfect" |
||||||||
|
|
|||||||
me goes for routing soft so can really test (don't have the real package here...) |
||||||||
|
|
|||||||
damn, have to get this box masquarate... |
||||||||
|
|
|||||||
eh, uuh... can't realize what is wrong... it just says incorrect UDF... or something. how should the output be? |
||||||||
|
|
|||||||
k,sorry for my stupidity. forgot that jens does not like arrays... |
||||||||
|
|
|||||||
Did you download the ZIP Package? That one contains a ready-to-run script and UDF. The UDF output, as specified in the README, is a comma-delimited string of the song numbers, e.g. '1,2,3' if your are using songs 1, 2, and 3 of a particular CD. |
||||||||
|
|
|||||||
yeah... I'm just running the script. about 6mins and still counting... some output from the main script could be nice... |
||||||||
|
|
|||||||
ehe... 46mins of processor time... highest mem usage this far noticed 70M! good golf! |
||||||||
|
|
|||||||
Bummer, "FIX" is integer based... |
||||||||
|
|
|||||||
what fix? |
||||||||
|
|
|||||||
Fix( ) Action: Removes the fractional part of a number and returns the resulting integer value. Syntax: Fix (expression) Parameters: Expression Any valid numeric expression. Returns: Variant of subtype Integer. Remarks: If the number is negative, Fix( ) returns the first negative integer greater than or equal to the number. For example, Fix( ) converts -6.3 to -6. See Also: Abs( ), Int( ) Example: |
||||||||
|
|
|||||||
oh... damn, if I would have known that the run time of the script is this long, I would have done some improving of the code before executing it... already been running about 1,5hours... think I'll go to bed and post the result once it finishes... hopefully tomorrow. |
||||||||
|
|
|||||||
Going for "Perfect" really eats up my servers CPU First CD took about 10 mins with a total cd time of 44.9999 Talking about optimization... |
||||||||
|
|
|||||||
Is there any reason that the sort is called 100 times? Is it to deter brute force solutions? |
||||||||
|
|
|||||||
I think so... Bummer |
||||||||
|
|
|||||||
Yeah bummer indeed. I was expecting the script to have finished this morning based on the time it took to resolve CD 1, and was surprised that it wasn't. Then I spotted the 100 iterations. |
||||||||
|
|
|||||||
same here richard. well, I go out and will see if it's done by evening. if not, I'll come back tomorrow... |
||||||||
|
|
|||||||
ah btw. jens, as your script already opens the console on wkix32.exe without printing anything. damn, there should be something coming out saying how many times it has ran and how many times more to come. |
||||||||
|
|
|||||||
I got fed up with the blank screen so I stopped it and added some diagnostic messages to the main script. So far I've got this: code:It is now 11:42 local time, so CD#5 has taken 2 over 2 hours and hasn't finished wherase the rest of them took no more than a few minutes.Loop #1 @ 09:29:59 Hmmm. very odd. Best have another look at that code... |
||||||||
|
|
|||||||
well, there is some cd that is a lot longer than the others. jens, I got my loops to 5. |
||||||||
|
|
|||||||
woah! what is this: quote:what is the use in this and w00t! wicked. if ones script runs the whole week, he has no change to improve his code while it takes all reserves from the machine... re checked your code... it could indeed be less than 100 without harming anybody... |
||||||||
|
|
|||||||
Urk!? I think I've found part of the problem that CD#5 is taking so long. From a debug message: quote:Now, I've got a line which should exit the routine when the gap is less than 0.0001, but this very small value doesn't seem to trigger it. Hmmm. |
||||||||
|
|
|||||||
richard... lol. yeah, you can do it work faster, but isn't this golf? golf thus far has been about as little strokes as possible, not as quick as possible. jens, are the goals changed? I made the script run just once and my code had run about 2 hours when I left home. and I'm sure, I can't return results before the private coding phase is over. even though the code works, it's results can't be announced as it takes more than just one week to run the check script! |
||||||||
|
|
|||||||
The reason for the extra code to reduce the run time is that I have exactly the same problem you have. It will take too long to run at the moment. Once I am happy that the solutions are correct I can remove the time saving code to save bytes and get a better golf score, but until then I need to leave it in. |
||||||||
|
|
|||||||
I have posted an updated KiXGolf package at http://people.bu.edu/jenmeyer/kixtart/kixgolf_cd.zip The change is that it now saves the results for each CD to both the screen and the results file. An example results file is part of the package. I also added some calculations that will display the time the script needed to run. I willnot show the start date/time, the end date/time and the duration as part of the scoring part. The goal of the KiXGolf tournament has not changed. It is still about optimizing for least keystrokes. The only reason I put the 'loop 100 times' into the code is to deter the use of a brute-force approach. Though the 'brute-force approach' is defimitely a valid one, I don't see it as a challenge to just create a couple of FOR loops. be creative! I already gave one hint for a potentially powerful algorithm for this type of problem. If eerybody wished, I could spell out the method(s) that could be used. However, you would still have to code it. So far, I've already seen one solution posted which fulfills the requirements, namely it produced a list of song indices for each CD with each CD having a total length of <45 and it did finish in time. And Patrick did't even use the fastest computer for this I would also recommend to run your tests with just one loop and/or just one CD. [ 11. March 2003, 16:12: Message edited by: sealeopard ] |
||||||||
|
|
|||||||
Jens, Brute force will search for "Perfect"... Really nice to get the best score out of 1,267,650,600,228,229,401,496,703,205,376 possible solutions (CD12) I know which algorithm type your talking about, but can't determine the three methods of approach you mean. Others, Does anyone else have a clue what Jens is talking about??? |
||||||||
|
|
|||||||
jens, I did your recommendation but as you have so many songs, the calc takes still time. the increase in time is awesome as say 5 songs calc in 3-4 seconds. 6 songs takes already a approx minute. what comes to having a sorter with less than the media total. sure, I had such sorter and the code was sorter than current. also it's execution time was damn fast. but I think we have to disagree still with the goals. you accept code that does somewhat correct thing. I see patricks code as unacceptable as it does not calc the perfect values and as such is not acceptable. sure, I could do for each cd to include only 1 song and with your current ruling, that would also be acceptable some rules would be good. |
||||||||
|
|
|||||||
Agreed, Am going for perfect too. Will use one loop though... |
||||||||
|
|
|||||||
quote:Nope, haven't got a clue. Two nations separated by a common language |
||||||||
|
|
|||||||
There are three (as I know of) methods to solve this problem: 1) Brute-force 2) Limited search 3) Monte-Carlo Method or a combination of the above. Limited Search: A limited search would start with one song (e.g. the longest one), then choose a second one. If the second one fits, you choose a third one, and so on... Monte-Carlo Method: This method create random permutations of songlists. It then checks each songlist whether it is below the length limit and chooses the best fit. A combination would be to e.g. first do a Monte-Carlo, then search the leftover songs for a potential better fit of one of the already used songs. One thing that couldbe used is a sorted list of entries. [ 11. March 2003, 17:50: Message edited by: sealeopard ] |
||||||||
|
|
|||||||
dunno. my monte-carlo takes up hours for one cd and if I use limited it is fast but it indeed is not even close to perfect. for using combined... mm, it could be little faster but also a lot longer. |
||||||||
|
|
|||||||
Ahh. Thanks for that. I'm taking option one, but limiting it to one loop and a little recursion to make it all a little more aesthetically pleasing. 5 minutes for disks 1-8, but disk 9 is really pushing the envelope, it's taken 15 minutes to get the gap down to 0.000299999999987977. Maybe I should set a higher limit for the gap - it might catch all the "perfect" solutions. |
||||||||
|
|
|||||||
quote:formatnumber() keeps bombing out on me, so I just got rid of all occurences. Anyway, need to get all cd's optimized now. Then I'll worry about my golf score. |
||||||||
|
|
|||||||
Wow! Five optimized CDs, not bad. |
||||||||
|
|
|||||||
heh. added one small if statement and the execution time of all 100 loops was just one minute still, no optimized CDs. |
||||||||
|
|
|||||||
jens, I must admit that I got mad to you for thing not so big. as we know, the full-scan of possibilities takes zillion hours time (like my UDF) there can be some reliefe. either degrease the media time or song count or even loosen up the rules, like we have done now. what is the time on cd to be accepted? 50% gap? |
||||||||
|
|
|||||||
You got mad? Where? I didn't see anything Based on the task description, I would say that a lower gap takes precedence over a lower Golf score. Thus , a lower average gap win if the KiXGolf score is the same. However, then we would move away from the KiXGolf idea of "less keystrokes is better". Damn, I hate that I didn't seem to fully thought about this. |
||||||||
|
|
|||||||
Jens, This is the first chance I have had to read this. Are you demanding the optimal solution here or will any solution do? If the optimal solution is desired then it seems to me that recasting the problem as a linear programming problem might be the best approach in terms of computational time efficiency but in terms of key strokes the brute force method would be the best approach & possibly only solution. Your suggestion of using limited or monte-carlo searches suggests that non optimal solutions are permitted. Is this true? If so how are you balancing optimal against key stroke concerns? I am sorry for leaping in several days into the contest but I am trying to understand what is happening & I am a bit confused. [ 11. March 2003, 23:35: Message edited by: Jack Lothian ] |
||||||||
|
|
|||||||
Jack: I'm interested in the optimum CD fill with the least CD gap with the lowest KiXtart score. Granted, these conditions can be contradictory as you can lower your KiXGolf score by increasing the average gaps. This also means that two approaches could result in different CD fills and different KiXGolf scores. In this case, the approach with the lower gap (as measured/displayed by the average gap) would win. If two approaches result in the same average gap, then the lower KiXGolf score wins. This will actually only affect the outcome of the first part of the KiXGolf challenge. As the UDFs will be public for the second part you can still be able to further optimize somebody elses approach. This way, we are still true to the goal of the KiXGolf Tournament, namely keep the keystrokes as low as possible. BTW, the algorithm used to create the 'Gold Standard' for the optimized CDs is a combination of Monte-Carlo-Method and Limited Search. As far as I can tell this is actually the 'perfect' solution for the provided datasets. The only constraint that I tried to create was the prohibition of the brute-force approach as I don't see that approach as programmatically challenging. |
||||||||
|
|
|||||||
back at here... been doing some tests and still must wonder, why 100? it already tests all the CDs... why not 10 or 20? it takes a lot of time to run 100 times... or why not 1000? |
||||||||
|
|
|||||||
w00t! I ran your code jens it ran all the loops (100) and after that just crashed. no data written to file. why crashed, there is at the end a "get $sOutput" to catch the end window and it never gets there. it never shows me any errors nor there is any kix error. |
||||||||
|
|
|||||||
damn jens, aren't you american? wonder why no reply... does anyone have the older versions of kixgolf_cd test-suite? |
||||||||
|
|
|||||||
update. jens, I tested your code with 4.12, 4.20 and 4.21-rc1 and all of them quit "abnormally" in english, there is no screen output, kix does not error etc etc. so have you built in some sort of check if my syntax is better than yours, you skip it? |
||||||||
|
|
|||||||
more to it. if I add more songs (like add new dummy ",") at the end of list, your code will die with kixtart error array reference out of bounds. if I then remove one element from the outcoming list, your script executes. ofcourse then the cd's are not optimized. so, PLEASE, could you check your code. [edit] even more, updated your files again and even downloaded kix32.exe to test from console. full output is: quote:now, I keep on waiting until you fix it. until that my current by myself validated code is 245 strokes. [ 12. March 2003, 00:55: Message edited by: Lonkero ] |
||||||||
|
|
|||||||
I had the same problem. I think it quit on this line. code:It also quit on more lines farther down in the script if i commented that line out. Everytime line the script quit on was using the formatnumber() function. I just removed all references to formatnumber(). For example, I changed the above line to code:That seems to have fixed it for me. |
||||||||
|
|
|||||||
Okay, guys, I can reproduce the problem. I'll work on a fix. I haven't seen that before when I was using arbitry lists of indices to test the validation routine. |
||||||||
|
|
|||||||
I think I've found the problem. It look to me like a bug in the FORMATNUMBER function that only surface if you try to format the number to x decimal places and this resulting number would result in being effectively '0' See the code for an example code:I have already corrected the code and uploaded an updated KIXGOLF_CD.ZIP at http://people.bu.edu/jenmeyer/kixtart/kixgolf_cd.zip$a=0.1 The buggy FORMATNUMBER() function has been replaced by a homegrown NumberFormat() UDF which should also correctly set either a '.' or ',' decimal indicator based on the users locale settings. I will also post a report in the BETA forum as Ruud post about the already mentioned FORMATNUMBER() problem with '0' does not address this particular problem. |
||||||||
|
|
|||||||
now we are talking! jens, don't remember to add that even though it's buggy it does not produce any error, it just crashes kix. |
||||||||
|
|
|||||||
k, thanks jens... here is the results for the code I tried to approve yesterday: quote: |
||||||||
|
|
|||||||
jens, I still get array reference out of bounds. kixgolf_cd.kix line 115. last thing in console: quote:that error comes due my test code that has added "0" song. should it still crash? could the console say something? {edit} also, what is this: code:eh?CD #11 how much is 0%? should I read it that I should make my collection better than yours to be approved as optimized? [ 12. March 2003, 07:29: Message edited by: Lonkero ] |
||||||||
|
|
|||||||
Nuts. Ran to completion and then no output. Removed the formatnumber and restarted. May not going to get an opportunity to optimise at this rate |
||||||||
|
|
|||||||
richard, do you still run with brute force? I used that approach and it took t000 much time so made some cuts. now one cd takes about 3-5 seconds at most. |
||||||||
|
|
|||||||
Yep, still using brute force with some speed up techniques. If I pre-sort the arrays I can make massive improvements in speed, but with a huge overhead in code. If I convert to integer I can probably make similar improvements, again with code overhead. At the moment I just want it to run to completion so I can check that the algorithm is OK before optimising. Run times aren't too bad. Latest run (still active) is: code:CD#9 is the hardest so far at just over the hour.Loop #1 started @ 09:00:28 I think I may be having rounding problems with the floating point which are causing some comparison problems. For instance, one of my checks halts processing down a tree when the gap become negative (too many tracks). This is a problem when the values get buggered up internally, so instead of "1" you have "0.99999976234". Substract "1" from it and you will get a negative value which will cause the sequence to be deemed invalid. Maybe I will have to switch to integer sooner rather than later... |
||||||||
|
|
|||||||
Completed and the mainn script crashed. Will d/l the latest package and try again |
||||||||
|
|
|||||||
well, making them integer with say 3 decimal points should make it faster. but indeed it will also cause a lot of extra code. well, you boys can be developing now. my code is fully compressed now and it can't even be optimized any less without increasing of the code size dramatically. so, if someone goes under 240 strokes with good CD times, I give up. good luck to ya. |
||||||||
|
|
|||||||
well, as could not get my hands on the older versions can't say for sure but AFAIK the problem is the bug. get the newist version and if there is still problems, we might get to report new bug |
||||||||
|
|
|||||||
Well, a trial run (first 5 CDs) optimised all of them. Full run in progress now. |
||||||||
|
|
|||||||
At last! A full run. Optimised 11 CDs - the one that is not optimised can be optimised by a further "0%" apparently. How do I do that then? Here's the results. The golf score is not interesting as the UDF is still full of long variable names and debug code. quote:So, the question is what does the "0%" mean? Can this disk be optimised further or not? The optimal length is 44.58 and the created cd is 44.58 (CD#8) Looks to me like is should be 12 optimised CDs. [ 12. March 2003, 13:48: Message edited by: Richard H. ] |
||||||||
|
|
|||||||
same question I had... have to look up |
||||||||
|
|
|||||||
optimal results with cd8: Songs=3,20,2,11,7,6,19,10,1,5,8,13,14,9,17 would need to calc those values but I think it's all about floating point overflow. it can also be that jens is only calculating for say 0.001 and your code is 0.0000001 better or worse in time... |
||||||||
|
|
|||||||
now as I think of it. yeah. the screen only displays the seconds but he most likely has a $optimal>$UDFprovided switch which does calc with floats. |
||||||||
|
|
|||||||
CD#8 only takes 3 mins to calculate so I ran again. CD size generated is 44.5842, so my result is .0042 better than the optimal |
||||||||
|
|
|||||||
Lonk / Rich, You guys are running like crazy... I'm a bit stuck Will start thinking of new algorithm! |
||||||||
|
|
|||||||
richard, did you calc also what is the actual time for the optimal? it can be also something like 44.5847 |
||||||||
|
|
|||||||
Ok, I'm in a bit of a quandry now. I've got a solution that fully optimises all CDs. It takes about 1 hour 40 minutes on a machine that I use for work, so I'm not really interested in running it 100 times to generate exactly the same results. Just take the result and multiply by 100 for a worst case run time. Now, do I start cutting the code to get a lower byte count, or do I start adding code to get a faster executing script? Do I change the algorithm for one which produces a less accurate result with a smaller script or faster run time? |
||||||||
|
|
|||||||
quote:No, fair point. I'll do that now. |
||||||||
|
|
|||||||
This is England calling... The result in reverse order for CD#8 is... code:The lengths are printed twice - the second length is unformatted.CD #8 So they appear to be the same, although the script insists that it can be further optimised. |
||||||||
|
|
|||||||
so, it's bug in jens' code. what comes to the task and competition... I think we have no competition possible anymore or if we do, we need to do 3 different goals: -fastest -most accurate -smallest my current code combines these all but we can't compare our scripts in any way if there is no one clear goal. which we don't have now... I quess. or was it that to do a script that executes 100 loops before next sunday and does that in accepted way and is smallest. I have already created my current golf code. if we go for valid and small, this should be unbeatable: [edit, removed shitty stuff as proven my point] hehee! I'm good [ 12. March 2003, 18:20: Message edited by: Lonkero ] |
||||||||
|
|
|||||||
Joeel: Your code won't stand up to the competition as everybody else has better optimized code, which is part of the requirements. I've also got word back from Ruud, he confirmed that there's a bug in the FORMATNUMBER() function. He has already provided me with a private build that should eliminate the bug. However, I will have to test this first and report back to Ruud. With regards to the 'loop 100 times' issue: The 'run time' display will show whether your code can run within the allotted time, so I'm flexible on that one. I choose '100' as an relatively arbitrary number which would translate to about 2 hours per loop. Two hours seemed very reasonable to me. I will beef up the reporting part a little bit so that the processing time will also be reported on a per-CD basis. I'm also going to investigate the 'Can be optimized by 0.00%' issue. However, I believe it's just a display problem, as the length calculations are accurate to four digits but I'm only displaying two digits. I will modify the code accordingly. The determination whether there's room for improvement is water-tight, however, I will double-check this, too. [ 12. March 2003, 16:41: Message edited by: sealeopard ] |
||||||||
|
|
|||||||
eh? it does not stand? so new rule we got here... I see. the code has to be 100% optimized and shortest to be the winner. ok, re-doing my codes... |
||||||||
|
|
|||||||
It does not have to be 100% optimized, however the rules do state quote:Without this requirement I could just return one song per CD and achieve a low KiXGolf score. |
||||||||
|
|
|||||||
quote:Eh? How do you mean? If you look ate the result I posted above (CD#8) the optimal value and the value I calculated are the same to 4 decimal places, but I still get a "could be optimised further". This gives me a "room for improvement", as it is the only CD in the 12 which reports a problem. |
||||||||
|
|
|||||||
Richard: I'll look into this. |
||||||||
|
|
|||||||
Richard: I've rechecked your results and... You've created a perfect CD Sorter! The solution you've provided fully optimizes all CDs based on the 'Gold Standard' that was provided as a comparison. Interestingly, your song lists are not identical to the 'Gold Standard', especially if you look at the reuslts for CD 10. The 'Gold Standard' chooses to use only song 25. However, you managed to improve the reference solution on a total of 10 CDs! I have updated the output generator of the KIXGOLF_CD.KIX script. It will now give more detailed feedback about the number of optimized CDs, and whether you've beaten the gold Standard or completely filled the CD. It will also print the duration needed to compute each Cd optimization. |
||||||||
|
|
|||||||
jens, indeed... my last ironic example was doing a match against any non-zero value and returned that. anyway, I'm still not clear with the ruling. this far richard has the gold as what comes to filling the cd. on the other hand I have the shortest code which compromises the disc usage in benefit of better score. as I come to this, my shortest code gets to: code:Average CD Length = 44.59 |
||||||||
|
|
|||||||
However, Richard has a lower average gap, thus he minimized the gap better than you did. If your average gap would be as good as Richards, then the KiXGolf score would be the deciding factor. |
||||||||
|
|
|||||||
ok, now you have new rule once again. well, I just keep coding, maybe you can decide what really is golfed here before sunday. if you can, I thank you before hand. |
||||||||
|
|
|||||||
Jens, I am lost. Reading the thread a second time, I have no idea what is going on. If I read the objective of the competition correctly, then the final winner must create a program that generates a list that truly minimizes the possible 'dead time' on the CD. Any program that doesn’t generate this optimum result can not win no matter how few keystrokes that it may contain. Also, the solution must work in general, not just with your examples. The more I think about it in this light, the more convinced that I become that this is a classical linear programming (LP) problem & the objective of the contest is to program something like the Simplex algorithm using the least number of key strokes. Because the problem is very simple (i.e. all the unknown x values can only take on values of 0 or 1) suggests one might be able to develop a specialized LP algorithm that significantly reduces the complexity & the number of keystrokes. My instinct is that this problem is more a serious math challenge than a programming challenge. I don't believe that doing a large number of random pulls of samples from a play list can always guarantee an optimal solution. (Is this what you mean by Monte-Carlo Jens?) By varying the seeds for the random pulls & increasing the number of pulls, you could get all the correct specific solutions given by your “gold method” but I don’t see how this would work in general. Of course, all LP methods could be construed as constrained random walks that eventually converge to an optimal solution. Thus in a generic sense these methods might be referred to as Monte-Carlo solution methods. (Or is this what you mean by Monte-Carlo Jens?) Also, any pulled sample based upon size ranking within the list can't guarantee an optimal solution. In fact starting with the longest songs would tend to generate semi-optimal solutions that minimized the number of songs on a CD. But again, your description of a Limited Search could be construed as a simplified explanation of an LP algorithm. Another point is that an LP formulism implies that multiple optimal solutions are possible because the solution matrix is underspecified. Thus one could get 2 or more optimal solutions with the same gap but different selections lists. On the other hand, if you get 2 “optimal” solutions with different gaps then this implies that your algorithm is not correct. If Richard is using the brute force method than his solution is equivalent to an LP solution & it is indeed a perfect solution. Another thought is maybe this “Gold standard” that you refer to uses the combined limited & Monte-Carlo approach with a different objective in mind. Maybe minimizing "dead time" on a CD is a secondary objective. If you wanted to generate a set of CD that had a balanced mix but didn't leave too much dead time, then a random pull followed by a ranking followed by a straight count off method might work very well. PS: Got to go for lunch now but I will look in after. [ 12. March 2003, 19:04: Message edited by: Jack Lothian ] |
||||||||
|
|
|||||||
Jack: This 'Gold Standard' was calculated using a Monte-Carlo-Method followed by a Limited Search. However, as Richard already proved, there might be better solutions that actually fill the CD completely. OTOH, there might not be a combination of songs for a given CD that actually fill the complete CD without gap. Thus, the rules specify that the gap has to be minimized without exceeding the media length. I think that those two statements in the rules are pretty clear. It does not matter what the actual song indices are. As some of the song lists contain songs with the same length, one algorithm might choose song 17, whereas the other algorithm chooses song 18, if both songs have the same length. This is not a deciding factor. Now, if you would like to go the LP way, yes, that is entirely possible. I think that both the MC and LS methods, however, might speed up the execution time compared to LP as you are seeding potential solutions. There are definitely different ways to solve the problem. The solution should work in general, though the provided CD sets are a good cross-section. Also, there cannot be two 'optimal' solutions with different gaps, as in that case one solution did not minimize the gap. Thus, you end up with just one 'optimal' solution. |
||||||||
|
|
|||||||
so once again, is the ruling now that the winner is the code with the optimal average length and if there is multiple of those, the one with best golf score? as for now, the testcode says I have valid code and it's score is lowest, so I post that too: quote: |
||||||||
|
|
|||||||
Jooel: Richards results: quote:I think he's slightly better. |
||||||||
|
|
|||||||
The point I was making was I think that only the LP & brute force methods generate optimal results consistently. Maybe the MC & LS methods might be faster or maybe even take less key strokes but that is irrelevant if they don't generate optimal results all the time. If I am reading the thread correctly, Richard has shown that the brute force method generates at least one solution more "optimal" than the Gold Standard. If this is so,it is proof that this strategey doesn't consistently generate optimal results. Also, what exactly do you mean by Monte-Carlo? Is this just a simple random selection process or is it something more complicated? PS: I not sure that I understand your reference to seeding in LP solution. If you wanted to minimize key strokes, I suggest you could seed the first iteration with x(1)=x(2)=..=X(n)=0 but if your playlist were always small you could seed it with the first m elements whose sum fits below the threshold. This would converge very fast in the examples given. Maybe with less than 10 iterations in the cases shown. [ 12. March 2003, 20:41: Message edited by: Jack Lothian ] |
||||||||
|
|
|||||||
yeah, in the means of gap. do you see my question in previous post? or should I take this as you compare the results and then decide which is better? |
||||||||
|
|
|||||||
As far as I understand it the Monte Carlo method creates a random subset of all potential outcomes based on specific constraints. In our case, you have for example 3 songs. Thus, you have the following potential outcomes code:The Monte-Carlo Method would create a subset of e.g. three potential outcomes that it generates randomly, e.g.1 code:or1 code:Then, only this subset is tested whether it fulfills the constraint of sum of all song lenghs smaller than media length and gap is minimized.12 However, this apporach inplies that you might miss the 'perfect solution'. Thus,a limited search is appended, which checks if you can either add songs or substitute songs in order to minimize the gap further. Nevertheless, even this approach might miss the 'perfect' solution. So, if you want the perfect solution all the time, either BF or LP will always give it to you. However, you might not finish running the script within the allotted time. |
||||||||
|
|
|||||||
In the examples given, I believe that any LP algorithm would be very fast but the number of keystrokes used would be very high. Because the constraint matrix is really 2 joined identity matices, I suspect that somewhere in the literature a specialized solution has been developed for this problem that significantly reduces the complexity of the problem. Find this & you may have a winner. |
||||||||
|
|
|||||||
jens, the problem your task has is that you don't say what is approved as optimal. you just say better. this leaves all the judging not to rules but to you per code. if we go for optimal, we should do a script that does full scan for all possibilities and see the perfect results and then say those are the optimal scores. now, there is nothing to hang on. just like jack pointed in side note, this looks like not golf but mathematical course. |
||||||||
|
|
|||||||
Here's my last run. Some of the code chooses randomly, so don't know when or if I can repeat this. quote: |
||||||||
|
|
|||||||
First of all, I'd like to apologize for the confusion creted by the ambiguous rules. If everybody agrees that this would be a fair change, then I would like to change the two rules/constraints for the CD Sorter algorithm as follows:
[ 12. March 2003, 23:39: Message edited by: sealeopard ] |
||||||||
|
|
|||||||
oh, that is better. but, I thought the media was minutes so, sure I have pieces in this light to improve. |
||||||||
|
|
|||||||
I'll be around for another 20 minutes. If nobody objects I will update the scripts accordingly and restate the tasks, rules, and constraints. [ 13. March 2003, 00:21: Message edited by: sealeopard ] |
||||||||
|
|
|||||||
Update: Rule Change: Due to some discussion during the tournament the second constraint has been changed. You no longer need to 'minimize' the gap. It is sufficient if the gap is less than 1 minute. All documentation has been updated accordingly and the KIXGOLF_CD.ZIP package at http://people.bu.edu/jenmeyer/kixtart/kixgolf_cd.zip also reflects this rule change. My apologies. Constraints:
[ 13. March 2003, 00:29: Message edited by: sealeopard ] |
||||||||
|
|
|||||||
sorry to ask once more I understand by your stating that "all are qualified this far" that you are not talking about individual cd-gaps but the average? |
||||||||
|
|
|||||||
Jooel: The gap of each CD has to be less than one minute. Richard submitted a valid run at http://www.kixtart.org/board/ultimatebb.php?ubb=get_topic;f=14;t=000491;p=4#000082 Maciep submitted a valid run at http://www.kixtart.org/board/ultimatebb.php?ubb=get_topic;f=14;t=000491;p=5#000111 Jooel, your submission at http://www.kixtart.org/board/ultimatebb.php?ubb=get_topic;f=14;t=000491;p=3#000073 seems to have a problem with CD8 as the gap is larger than one minute. |
||||||||
|
|
|||||||
Two results. Result 1 is "best fit". Result 2 is "less than one minute gap". Result 2 is 5 bytes shorter ("1" instead of "0.0001" ) and is much, much quicker. As before, this is a linear approach so the results will be identical each time - there is no gain in running the process 100 times. I made a speed-up change to the best fit which has brought the run time down from 1:40:00 to 1:10:00, but I may have lost some accuracy, so will try with the speed-up backed out. RESULT 1 : BEST FIT code:RESULT 2 : GAP SMALLER THAN 1 MINUTECD #1 code:CD #1 |
||||||||
|
|
|||||||
damn! that's nice. even though it's not the fastest avail but it's faster than fast as you think of the accuracy it has. |
||||||||
|
|
|||||||
quote: |
||||||||
|
|
|||||||
quote: |
||||||||
|
|
|||||||
Stole another byte. 287 Best fit score (accuracy) 282 Under 1 minute gap score (speed/size) It's now completely unreadable, which I guess means I probably can't make it any smaller |
||||||||
|
|
|||||||
quote: |
||||||||
|
|
|||||||
Nice results, everybody! |
||||||||
|
|
|||||||
doh, I could not get with my syntax from current av.gap of 0.91 under 0.89 and that is not enough. and I'm even running out of time. |
||||||||
|
|
|||||||
k, hence the new ruling, was able to make it fit with some additional strokes... exactly 40 more. and the time, from previous 9secs per total loop, this lasts now 38mins! anyway: code:CD #1 |
||||||||
|
|
|||||||
quote: |
||||||||
|
|
|||||||
this is not fair! you have so fast code and all! |
||||||||
|
|
|||||||
Average CD Length = 44.83 Average Gap = 0.17 Average Gap [%] = 0.39 KiXtart KiXtart Version = 4.21 Release Candidate 1 KiXGolf Script = kixgolf_cd.kix Computer OS = Windows 2000 Professional CPU = Intel Pentium III Speed = 797 MHz Memory = 375 MB KiXGolf Scoring Engine Scoring Engine = 3.0.3 KiXtart Golf Score Tournament = KiXtart Golf: CD Sorter Processing Start = 2003/03/13 23:42:46.052 Processing End = 2003/03/14 00:22:28.758 Duration = 0000/00/01 -1 # Loops = 1 # Processed CDs = 12 # Valid CDs = 12 # Full CDs = 2 KiXGolf Result = Valid CD Filling KiXGolf Score = 256 Thank you for participating in KiXtart Golf! |
||||||||
|
|
|||||||
still, nice to see how my changes do affect to the speed. even though small difference in resulting gap, the time increases dramatically. but only in some special songlist types. |
||||||||
|
|
|||||||
Average CD Length = 44.83 Average Gap = 0.17 Average Gap [%] = 0.39 KiXtart KiXtart Version = 4.21 Release Candidate 1 KiXGolf Script = kixgolf_cd.kix Computer OS = Windows 2000 Professional CPU = Intel Pentium III Speed = 797 MHz Memory = 375 MB KiXGolf Scoring Engine Scoring Engine = 3.0.3 KiXtart Golf Score Tournament = KiXtart Golf: CD Sorter Processing Start = 2003/03/14 00:48:32.627 Processing End = 2003/03/14 01:27:49.666 Duration = 0000/00/00 00:39:17.039 # Loops = 1 # Processed CDs = 12 # Valid CDs = 12 # Full CDs = 2 KiXGolf Result = Valid CD Filling KiXGolf Score = 248 Thank you for participating in KiXtart Golf! |
||||||||
|
|
|||||||
Whoa! Way to go Jooel! Removed some speed-up code, which in a general solution would be relevant, but doesn't appear to have much effect on this particular data set, so the best fit code is now: code:There is another bit of speed related code that I can chop to save about 15 characters, but the run times may get huge.Average CD Length = 44.84 Will start it now and see what happens... |
||||||||
|
|
|||||||
I was first thinking that I and maciep had same codes as the stroke count is so similar but as I see his gaps and full cd amount, I see also that our codes must be a lot different. maciep, btw... what is your gap on cd 8? I had to make my code sooo slow to keep that cd above 44mins... |
||||||||
|
|
|||||||
Jooel, It's different everytime. But it's always more than 44 minutes and I didn't have to do anything special for that CD or any others . But, in general, my gaps are pretty high compared to yours. |
||||||||
|
|
|||||||
oh, you have randomizer! nice. and it's even quick. good, I want to see that even though it might not be winner. awesome... but I hope you don't give up now. just try to find those 2 strokes to make you #1 my code has been so compressed for long time now, that if I remove 1 stroke, I have to add 20-30 first to make it work again and start removing again. and that is challenge I like! |
||||||||
|
|
|||||||
richard, you are so close now that I must ask you too not to give up... maciep, btw... I think that after sunday the code I will try to compress is yours. so, please post it right away once round 2 start, so I can get to tweaking of it |
||||||||
|
|
|||||||
I stopped running in phase 1, can't get it to work Going on holliday next week... But me too will print and tweak after public phase will be started... |
||||||||
|
|
|||||||
It's taken 3 hours for disk #5 and still not finished, so I don't think that's going to work I'm not going to be able to squeeze any more out because of the underlying design (you'll see what I mean), so I've posted my last version off to Jens for posting as I'm not about this weekend. |
||||||||
|
|
|||||||
Jooel, I have 7 more strokes that I can definitely take off right now. But it slows it down to about a minute. So, I'm going to try to find all of the other little cuts before I do that. So basically right now my score is 242. |
||||||||
|
|
|||||||
now, that is not fair |
||||||||
|
|
|||||||
quote: |
||||||||
|
|
|||||||
maciep, I want to know... how generic is your code? like, if the songlist has only 2 five-minute songs, does it work? or is it specific for this task? just want to know |
||||||||
|
|
|||||||
Jooel, It is specific for this task in that if the given gap of one minute is not attainable, the function would fail. So, if there were only two five-minute songs in a list, then the function would not work. But if there were only two 27-minute songs in a list, it would work. |
||||||||
|
|
|||||||
yeah, just like I quessed. no wonder I have hard time competing well, I try to keep up but I have great suspicion will I get any strokes of this without loosing the generic nature. well, will try to improve the crypting. |
||||||||
|
|
|||||||
So, If I would test it with gap=2, your function would fail? What happens if I change the media length? Hmm, the whole gap-business could have lead to the introduction of a third calling parameter CD_Sorter(SongList, MediaLength, Gap) but that's too late now. |
||||||||
|
|
|||||||
jens, the gap thingie could have been with percent ruling. but what comes to medialength, wonder why you wanted to use the same. could have collected the info together from multiple loops with multiple media-lengths... well, think that it's too late for this also. |
||||||||
|
|
|||||||
Yes, I know, two loops, one for media lengths between e.g. 0 and max(sum(Songlist)), the other one for a gap of 0.05%-20% of media length. But, as you said, this is too late now. Unless we modify the goal of the second (public) coding round. I'm not going to make any changes to the current setup. |
||||||||
|
|
|||||||
Guys, Media length is not a factor in my function. If it's changed, the function will still work. Personally, I agree that CDSorter() should have a third parameter for the gap. Right now, I have it hardcoded as 1 minute. Anyway, quote: [ 14. March 2003, 16:30: Message edited by: maciep ] |
||||||||
|
|
|||||||
not saying that medialength is a factor but it would bring up real-world usage example. that is the reason the parameter was added in first place. |
||||||||
|
|
|||||||
btw, jens... think that we could make a cycle counter for next golf tournament. purely kix-solution and not perfect I have in mind but anyway. |
||||||||
|
|
|||||||
Average CD Length = 44.83 Average Gap = 0.17 Average Gap [%] = 0.39 KiXtart KiXtart Version = 4.21 Release Candidate 1 KiXGolf Script = kixgolf_cd.kix Computer OS = Windows 2000 Professional CPU = Intel Pentium III Speed = 797 MHz Memory = 375 MB KiXGolf Scoring Engine Scoring Engine = 3.0.3 KiXtart Golf Score Tournament = KiXtart Golf: CD Sorter Processing Start = 2003/03/14 19:58:48.046 Processing End = 2003/03/14 20:38:02.722 Duration = 0000/00/00 00:39:14.675 # Loops = 1 # Processed CDs = 12 # Valid CDs = 12 # Full CDs = 2 KiXGolf Result = Valid CD Filling KiXGolf Score = 245 Thank you for participating in KiXtart Golf! |
||||||||
|
|
|||||||
I don't actually like the Idea of gap as arg. it's then no more real-life situation. who knows before hand the best solution without testing? and who needs to know anything anymore when he knows the ideal? that is stupid in that way. but the gap could have been percent of the media length IF POSSIBLE or little lower etc. this way the task would have double harder too. |
||||||||
|
|
|||||||
I understand what you're saying, but I still like the gap. It gives us a set of rules. I mean after all, this is a golf tournament. So with no rules, whose the winner? Would it be lowest score, smallest gap or fastest function? Gap % would work too, but it would just add strokes to my score, it wouldn't change my algorithm at all. And as far as real world goes, I don't think a function that takes 40 minutes to fill 12 CD's with songs would be very acceptable. |
||||||||
|
|
|||||||
I am not sure about the gap being the key variable. Rounding is raising its ugly head in all my tests. Several of Jens' examples can give multiple answers that differ in the 3rd or 4th decimal. For example, I have derived 2 very different answers for CD1 that give lengths of 44.9998 & 44.9999 for an improvement of 0.0001 in the gap. Small changes in logic can drastically change the derived results. Rounding & data conversion in kixtart can be bizarre & unpredictable. |
||||||||
|
|
|||||||
Theoretically, you wouldn't have any rounding issues as all datasets have foru decimal places and simple add/subtract operations won't change the number of significant decimal places. However, since the numbers are displayed in binary fashion, you incur +/- EPS in precision for each number. EPS is the smallest number that can be expressed in the number format used. EPS for integers is e.g. 1. So, even add/subtract introduce very small round-off errors whcih should be in the order of maybe 1E-16. I would not expect to see round-off errors in the fourth digit. |
||||||||
|
|
|||||||
Average CD Length = 44.83 Average Gap = 0.17 Average Gap [%] = 0.39 KiXtart KiXtart Version = 4.21 Release Candidate 1 KiXGolf Script = kixgolf_cd.kix Computer OS = Windows 2000 Professional CPU = Intel Pentium III Speed = 797 MHz Memory = 375 MB KiXGolf Scoring Engine Scoring Engine = 3.0.3 KiXtart Golf Score Tournament = KiXtart Golf: CD Sorter Processing Start = 2003/03/14 20:46:06.287 Processing End = 2003/03/14 21:25:02.276 Duration = 0000/00/00 00:38:55.989 # Loops = 1 # Processed CDs = 12 # Valid CDs = 12 # Full CDs = 2 KiXGolf Result = Valid CD Filling KiXGolf Score = 244 Thank you for participating in KiXtart Golf! |
||||||||
|
|
|||||||
Trying to track this down: On the 12th CD: quote:Not sure what's up. |
||||||||
|
|
|||||||
My first good code. Why are you guys NOT looping 100x? code:Average CD Length = 44.39 [ 15. March 2003, 11:09: Message edited by: Howard Bullock ] |
||||||||
|
|
|||||||
Yahoo! Was 244 the best so far? code:Average CD Length = 44.38 |
||||||||
|
|
|||||||
code:Average CD Length = 44.39 [ 15. March 2003, 11:48: Message edited by: Howard Bullock ] |
||||||||
|
|
|||||||
no, it wasn't, but that doesn't matter anymore... quess I need to make myself totally new code... |
||||||||
|
|
|||||||
I believe data conversion is my main problem. I just can't seem to find a way to force Kixtart to treat the gap variable as a double precision number throughout my routine. It seems that during function calls, kixtart does its own internal data format conversions & this conversion is not fixed but rather based upon the actual values in the arrays. |
||||||||
|
|
|||||||
It's getting harder to reduce the size. Still looking though code:Average CD Length = 44.58 |
||||||||
|
|
|||||||
Is anybody using plain old integers? Just remove the dots in the numbers and you don't have to worry about conversions code:As you only need to return the index numbers it's not really important whether you wourk with doubels or integers.$a='1.234' [ 15. March 2003, 20:18: Message edited by: sealeopard ] |
||||||||
|
|
|||||||
Jens, should we post the result file of 100 loops with the code for Phase #2? |
||||||||
|
|
|||||||
Howard, it's not really necessary as the processing times will indicate how long a 100-loop run would take. |
||||||||
|
|
|||||||
Results of the first round of KiXGolf - CD Sorter: Best published score: 207 by Howard Bullock Scoring Timeline (top line is most recent post): 207 = Howard 214 = Howard 360 = Howard 244 = Lonkero 245 = Lonkero 230 = Maciep 239 = Maciep 279 = Richard 248 = Lonkero 256 = Lonkero 249 = Maciep 278 = Lonkero 278 = Maciep 297 = Maciep 367 = Maciep 283 = Richard 737 = Maciep |