A simple pyramid
This one ended up being an attempt only. I couldn't complete it.
For time:
1-2-2 : 10-20-20 : 1-2-2
pullup-pushup-situp pyramid
SS: 1-2-2 : 10-20-20 : 7-14-14, 31 minutes
I went to check out the space over at crossfit Hoboken, and ended up attempting a pretty nasty pyramid in the process. It was open gym (and a rest day), so I didn't interact with many people but the space certainly had all the essential elements of a crossfit gym. I think I might come here on the weekends when I don't feel like trucking it all the way to the city just to go to Cole's.
18 comments:
Don't think I understand the rep scheme, but given the time, it looks like a lot of pushups!
The pull-ups go up 1 rep every round and the push-ups and sit-ups increase by two reps.
Grand total completed: 89 pull-ups, 178 push-ups, 178 sit-ups
So I guess I am the first one. On our way back from TRC I noted that Scott's notation was not proper syntax, and thus a challenge was born, who can write the fastest (in computer time) matlab code (Matlab 5.3 I think was the vote) to generate a matrix with the number of each exercise. Here is my entry:
foo=[1:1:20 19:-1:1]';
bar=2*foo;
baz=[foo,bar,bar]
For the record, my original idea was:
foo=[1:1:20 19:-1:1]';
bar=[foo,2*foo,2*foo]
And the ugliest version of this code I could come up with is:
foo=[1:1:20 19:-1:1]';
bar=[foo,kron(foo,[2 2])]
g, your pyramid would kill anyone but you--I think it tops out at 10-20-20. You only need one line:
[1:10 9:-1:1]'*[1 2 2]
Sorry , I mistakenly made mine go to 20 instead of 10. It should be
foo=[1:1:10 9:-1:1]';
bar=2*foo;
baz=[foo,bar,bar]
Sure yours has 1 line, but it has 3 operations. I think, although I don't know, that calling something stored is faster than doing the operation, even if that operation is easy.
[1:10 9:-1:1]'*[1 2 2]
I swear I didn't read Eric's, but you're going to have to take my word on it...
I think you're right, for raw speed the memory copy saving you the two O(n) multiply operations could be faster. However, I think that the assignments actually cost you (you have to allocate memory for three variables meaning that you allocate 5n doubles which I think takes a bit more time. (Apparently in both octave and recent matlab versions...)
octave:9> nIter = 1000; minT = Inf; maxT = -Inf; tot = 0;
octave:10> for n=1:nIter
> clear foo bar baz
> tic; baz=[1:10 9:-1:1]'*[1 2 2]; t = toc;
> minT = min(minT, t);
> maxT = max(maxT, t);
> tot = tot + t;
> end
octave:11> avgT = tot/nIter;
octave:12> fprintf('ED times: min, %0.6g; max, %0.6g; avg, %0.6g.\n', minT, maxT, avgT);
ED times: min, 0.000172; max, 0.00348; avg, 0.000178737.
octave:13>
octave:13> nIter = 1000; minT = Inf; maxT = -Inf; tot = 0;
octave:14> for n=1:nIter
> clear foo bar baz
> tic; foo=[1:1:10 9:-1:1]'; bar=2*foo; baz=[foo,bar,bar]; t = toc;
> minT = min(minT, t);
> maxT = max(maxT, t);
> tot = tot + t;
> end
octave:15> avgT = tot/nIter;
octave:16> fprintf('GF times: min, %0.6g; max, %0.6g; avg, %0.6g.\n', minT, maxT, avgT);
GF times: min, 0.000186; max, 0.000299; avg, 0.000188693.
octave:17>
>> nIter = 1000; minT = Inf; maxT = -Inf; tot = 0;
>> for n=1:nIter
clear foo bar baz
st=tic; baz=[1:10 9:-1:1]'*[1 2 2]; t = toc(st);
minT = min(minT, t);
maxT = max(maxT, t);
tot = tot + t;
end
>> avgT = tot/nIter;
>> fprintf('ED times: min, %0.6g; max, %0.6g; avg, %0.6g.\n', minT, maxT, avgT);
ED times: min, 1.9489e-05; max, 0.000509209; avg, 2.09156e-05.
>>
>> nIter = 1000; minT = Inf; maxT = -Inf; tot = 0;
>> for n=1:nIter
clear foo bar baz
st=tic; foo=[1:1:10 9:-1:1]'; bar=2*foo; baz=[foo,bar,bar]; t = toc(st);
minT = min(minT, t);
maxT = max(maxT, t);
tot = tot + t;
end
>> avgT = tot/nIter;
>> fprintf('GF times: min, %0.6g; max, %0.6g; avg, %0.6g.\n', minT, maxT, avgT);
GF times: min, 2.1499e-05; max, 0.000966005; avg, 2.39771e-05.
>>
While we are waiting for Brian's solution, let me say that I did tests on Matlab 7.3 this morning and my solution is slightly faster.
On my machine yours takes about 0.000064 seconds and mine 0.000057 seconds.
Hmmm, my guess is that it will be very version dependent, but we did decide that 5.3 was the testbed.
I actually considered both versions, but leaned towards the final one because of exactly what Eric said: allocation time for assignments.
Unfortunately, I no longer have 5.3 on my laptop. Brian?
I fully expect Brian to beat us all.. I'm betting on:
baz = [
1 2 2
2 4 4
3 6 6
4 8 8
5 10 10
6 12 12
7 14 14
8 16 16
9 18 18
10 20 20
9 18 18
8 16 16
7 14 14
6 12 12
5 10 10
4 8 8
3 6 6
2 4 4
1 2 2
]
which I didn't propose because it didn't seem quite in the spirit--but I'm sure is fastest (not including input time). Was code compactness a criterion or not?
Oh, and the versions for the above tests were:
octave 2.1.73 [Linux/Opteron]
matlab 7.7.0.471 (R2008b) [MacOS/Intel]
I don't have anything older than that lying around.
Ok, that might follow the letter of the law but definitely not the spirit. Good preempt, though, for any potential coding snarkiness on Brian's part...
I think code compactness to some degree was part of the idea. Who would have written that out for a blog post?
Yes, I thought about that too and I agree it is not in the spirit of the challenge.
Ok, just to be clear, proper pyramid syntax is not proper MATLAB syntax. 1:10:1 is a normal pyramid to 10. That notwithstanding, your comments are pretty awesome. I have MATLAB 5.3, so I can test them all if you'd like.
Outer product (same as E & K). I tried very hard to minimize the multiplies, but nothing was faster than the outer product (except the table solution). I think it will slow significantly with Matlab 5.3 since Lapack was not yet introduced (I think it was in 6).
I will look for an old version of Matlab.
I think I'm running 5.3 on my setup machine (as is Scott), when my morning behavioral session is done I'll do the comparison.
BTW if we had agreed on the matrix being the other around, my method would have been even faster (I would save the transpose).
BTW, do you realize how pathetic this makes us? :-)
Post a Comment