1. Contest Update (12-Nov-2004)
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)
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
-
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
-
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)
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)
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)
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
