1. Contest Update (12-Nov-2004)
- Posted by Derek Parnell <ddparnell at bigpond.com> Nov 12, 2004
- 517 views
I've corrected the bonus for speed. There are also a few new submissions. http://www.users.bigpond.com/ddparnell/contest1/rules.htm -- Derek Parnell Melbourne, Australia
2. Re: Contest Update (12-Nov-2004)
- Posted by Derek Parnell <ddparnell at bigpond.com> Nov 12, 2004
- 507 views
Derek Parnell wrote: > > I've corrected the bonus for speed. There are also a few new submissions. http://www.users.bigpond.com/ddparnell/contest1/rules.htm A last minute entry by Ricardo Forno has made me update it again. He is *so* close to getting top billing again. -- Derek Parnell Melbourne, Australia
3. Re: Contest Update (12-Nov-2004)
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Nov 12, 2004
- 463 views
- Last edited Nov 13, 2004
On Fri, 12 Nov 2004 01:56:09 -0800, Derek Parnell <guest at RapidEuphoria.com> wrote: >A last minute entry by Ricardo Forno has made me update it again. He is >*so* close to getting top billing again. OUCH! That's voodoo, he could have picked something other than 10.05. Ever get the feeling you're just being toyed with? Think I'll go and sulk now ;-(( Erm, anyway, I tried something different and got far worse than expected results. I narrowed it down to something like this: if atom(table[i][j]) then table[i][j]=chars[1..length] vs: if table[i][j]=0 then table[i][j]=1 I checked, under with profile, and both the above and all other statements in the program are executed exactly the same number of times. But one of the above takes 3.8 seconds, and one 6.8 seconds. Of course one of them creates a new sequence from a slice, whereas the other just assigns an integer. Of course, I thought the second one would be faster, but it ain't, by some margin. What's going on??? with profile_time suggests that the first version takes 0.3648 seconds (9.6% of 3.8) and the second 0.09656 seconds (1.42% of 6.8), about the ratio I might expect, and completely contradicting the overall runtimes for the two programs, since they only differ in those two lines. I've repeated this and got exactly the same results about two dozen times in a row. Anyone got any ideas? Pete
4. Re: Contest Update (12-Nov-2004)
- Posted by Derek Parnell <ddparnell at bigpond.com> Nov 12, 2004
- 458 views
- Last edited Nov 13, 2004
A question has been asked about the 'speed bonus' scoring. So let me clarify.... Only the fastest entry from each person can get a speed bonus. Thus for example, if you have two entries, and the second is slower than the first, it will not get a speed bonus. The first entry may get one (if its in the top 20 fastest-for-each-person) but even then it might not score as highly as the second entry due to other things. This would mean that your second entry appears on the leader board without a speed bonus, even though another person's entry on the leader board has a slower time and a bonus. To improve your position, you must improve both your speed and your correctness. So to summarize, the leader board shows your best scoring entry, not necessarily your fastest entry. -- Derek Parnell Melbourne, Australia
5. Re: Contest Update (12-Nov-2004)
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Nov 13, 2004
- 460 views
On Fri, 12 Nov 2004 21:39:22 +0000, Chris Bensler <bensler at nt.net> wrote: >The first bit of code checks the 'state' of the variable. It checks > an internal flag, not the value of the variable. Sorry, I think you *completely* misunderstood the question. (my fault, probably) The maths just on the "if" part is: first: 5.08% * 3.8 = 0.19304 seconds second: 1.08% * 6.8=0.07344 seconds. (at least that is what with profile_time repeatedly tells me) What that tells me (I need to test this I guess) is that "atom()" is in fact slower that "=0" (anyway). Nevertheless, if I "lost" on that test, I would accept it, but bear the above numbers in mind. > >The second bit of code checks the value of the variable and does a >comparison. > But both line 1 + line 2 together (as the only changes) account, at most, for 0.3648 seconds, and, in the case I think would be faster, but ain't, 0.09656 seconds. (again, that is what with profile_time repeatedly tells me) All other lines being equal, where has the extra *3* whole seconds of runtime (78%) come from? Would you be happy that changing one line from "atom()" to "=0" nearly doubles the runtime? If it did, would you like to know why? I do! I know you can't second-guess my code, I probably need to work on making a simpler case exhibit the same effect, which just may never have been noticed by anyone else, ever, before, but I kinda doubted, and hoped against that. Regards, Pete
6. Re: Contest Update (12-Nov-2004)
- Posted by Derek Parnell <ddparnell at bigpond.com> Nov 13, 2004
- 462 views
Pete Lomax wrote: > > On Fri, 12 Nov 2004 21:39:22 +0000, Chris Bensler <bensler at nt.net> > wrote: > > >The first bit of code checks the 'state' of the variable. It checks > > an internal flag, not the value of the variable. > Sorry, I think you *completely* misunderstood the question. > (my fault, probably) > The maths just on the "if" part is: > first: 5.08% * 3.8 = 0.19304 seconds > second: 1.08% * 6.8=0.07344 seconds. > > (at least that is what with profile_time repeatedly tells me) > > What that tells me (I need to test this I guess) is that "atom()" is > in fact slower that "=0" (anyway). > > Nevertheless, if I "lost" on that test, I would accept it, but bear > the above numbers in mind. > > > >The second bit of code checks the value of the variable and does a > >comparison. > > > But both line 1 + line 2 together (as the only changes) account, at > most, for 0.3648 seconds, and, in the case I think would be faster, > but ain't, 0.09656 seconds. > > (again, that is what with profile_time repeatedly tells me) > > All other lines being equal, where has the extra *3* whole seconds of > runtime (78%) come from? > > Would you be happy that changing one line from "atom()" to "=0" nearly > doubles the runtime? If it did, would you like to know why? I do! > > I know you can't second-guess my code, I probably need to work on > making a simpler case exhibit the same effect, which just may never > have been noticed by anyone else, ever, before, but I kinda doubted, > and hoped against that. Just did a bit of testing myself and it shows that the use of "if atom(table[i][j])" or "if table[i][j]=0" has no influence on the speed. By that I mean that ... if atom(table[i][j]) then end if and if table[i][j] = 0 then end if take the same time (near enough). The time is mostly taken up by ... table[i][j]=chars[1..len] as table[i][j]=1 has no real influence either. -- Derek Parnell Melbourne, Australia
7. Re: Contest Update (12-Nov-2004)
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Nov 13, 2004
- 478 views
On Fri, 12 Nov 2004 19:38:13 -0800, Derek Parnell <guest at RapidEuphoria.com> wrote: >Just did a bit of testing myself and it shows that the use of >"if atom(table[i][j])" or "if table[i][j]=0" has no influence on >the speed. <snip> Thanks Derek. My other post (Dramatic slowdown) clarifies the actual problem I stumbled into a bit better. Regards, Pete