I walked into neurobio, spent 15 minutes guessing on the exam, and went to turn it in. My professor said, "Easy, huh?" with a knowing smile, and I responded, "Haha, not really," in the smallest voice ever.
I left and immediately dropped the course. I feel like shit.
EDIT: Actually, I shouldn't feel like shit, because although this was momentarily humiliating, my GPA is intact and I'm just not as good at neurobio as I thought I'd be. So I guess it's alright.
I restarted Heart Gold because Pokemon. Dumped 6 hours into it in one go because Pokemon. Forgot that you have to delete your old save before you start a new game in order to save. Looks like my DS is going to be on for the next couple of weeks.
Spent way too long figuring out how someone else's code works only to realize that something was not set when it should have been. THIS IS WHY WE COMMENT CODE!!!
I had my meeting today about my annual merit increase. The increase that it was represented to us as a group to expect was not the increase I got. It was substantially less. I am not pleased today.
And because on paper I'm a low level corporate IT grunt, there's very little I can do about it from a job hunting perspective.
I took my SATs on a Saturday at 8. I was up all night prior with food poisoning and forgot my calculator for the portion where they were allowed. Not my best day.
I remember my first SAT, it was also on a Saturday at 8. My brother was watching someone else's kid the night before so I got no sleep. When I woke up I ate a cake for breakfast and washed it down with a couple sodas. I had a pretty shitty score.
Took a skills test for a company I'm trying to get a summer internship with. Screwed way up on the programming portion by being unable to remember important bits of the Java and C standard libraries.
Well, the non-programming bits I did absolutely fine on. I was allowed to use "reasonable" pseudo-code, but I wasn't sure what to consider reasonable and stuck with trying to do Java and C. But fuck trying to program without an API reference.
Ugh, if anyone ever requires you to do a skills test/interview question that requires you to have memorized a standard library, that's no good. The most interesting technical interview question I have been asked was this one:
A helicopter drops two trains, each on a parachute, onto a straight infinite railway line. There is an undefined distance between the two trains. Each faces the same direction, and upon landing, the parachute attached to each train falls to the ground next to the train and detaches. Each train has a microchip that controls its motion. The chips are identical. There is no way for the trains to know where they are. You need to write the code in the chip to make the trains bump into each other. Each line of code takes a single clock cycle to execute.
You can use the following methods (and only these);
MF(x) - moves the train forward
MB(x) - moves the train backward
isParachute() - returns true if and only if there is a parachute immediately next to the train
You may use any programming language of your choice.
Way cooler than "How many golf balls can fit inside a regular sized school bus?"
True, MB(x) is a red herring. In fact, if you try to use both, there's a good chance your program will fail for some placements of the trains. Your solution needs to work for every situation. There aren't really that many ways to do it inefficiently. The best answer is this one (confirmed by my interviewer):
//inch forward until you find the parachute do while { MF(1); }(isParachute())
//go forward as fast as possible until you crash while(true) { MF(9999999); //really just whatever the max speed of the train is }
Oh, MF(x) moves forward x units in 1 unit of time. You weren't at all clear on that; otherwise I would've come up with something more like what you mentioned.
In that case, yes, the best answer is pretty much what you put forth, as long as you put the biggest number you can in for x. This is faster, though:
//inch forward until you find the parachute do { MF(1); } while (!isParachute())
//go forward as fast as possible until you crash while(true) { MF(9999999); MF(9999999); //really just the max speed of the train is }
I reckon it's a better problem if you take the x out and only allow moving one unit, since that way you actually have to think about clock cycles and not just put in a big number.
It's also trickier to optimize with MF(1) only - you actually have to do some math.
No, I noticed that it was one unit of time per line of code (though that's still dodgy if you put multiple statements on the same line). The issue is that you didn't have any mention of what the "x" was about.
EDIT: Oh, and there was a mistake in your answer; you should've had !isParachute() as the condition.
Hard mode: They may or may not be facing in the same direction.
Takes forever, but you either move progressively one space farther in either direction until you find the other parachute, or random amounts. Random amounts are faster assuming a reasonable limit on the separation distance.
It's only roughly twice as slow as just moving one space at a time forwards was for the previous case, so not really much of a difference on the whole.
However, you need infinite memory in order to do this; I think there may not be a solution that doesn't require either infinite memory or a source of true randomness.
I think the problem statement implies you don't have access to a source of randomness, or there would generally be much better solutions. There's also a caveat - if they have access to true RNG, then there's a question of whether they would spit out identical numbers, or different ones.
A related problem: the track is circular instead of infinite; their initial positions are guaranteed not to be directly opposite one another.
Comments
I left and immediately dropped the course. I feel like shit.
EDIT: Actually, I shouldn't feel like shit, because although this was momentarily humiliating, my GPA is intact and I'm just not as good at neurobio as I thought I'd be. So I guess it's alright.
I even quoted them with CBO guidelines and they still refused.
And because on paper I'm a low level corporate IT grunt, there's very little I can do about it from a job hunting perspective.
But fuck trying to program without an API reference.
Also, when in doubt, make up functions that do what you want them to do.
slow = True
while True:
MF(x)
if isParachute():
slow = False
if slow:
pass
//inch forward until you find the parachute
do while {
MF(1);
}(isParachute())
//go forward as fast as possible until you crash
while(true) {
MF(9999999); //really just whatever the max speed of the train is
}
In that case, yes, the best answer is pretty much what you put forth, as long as you put the biggest number you can in for x. This is faster, though:
//inch forward until you find the parachute
do {
MF(1);
} while (!isParachute())
//go forward as fast as possible until you crash
while(true) {
MF(9999999);
MF(9999999); //really just the max speed of the train is
}
I reckon it's a better problem if you take the x out and only allow moving one unit, since that way you actually have to think about clock cycles and not just put in a big number.
It's also trickier to optimize with MF(1) only - you actually have to do some math.
EDIT: Oh, and there was a mistake in your answer; you should've had
!isParachute()as the condition.However, you need infinite memory in order to do this; I think there may not be a solution that doesn't require either infinite memory or a source of true randomness.
I think the problem statement implies you don't have access to a source of randomness, or there would generally be much better solutions. There's also a caveat - if they have access to true RNG, then there's a question of whether they would spit out identical numbers, or different ones.
A related problem: the track is circular instead of infinite; their initial positions are guaranteed not to be directly opposite one another.
I think the problem becomes impossible to solve (for a guaranteed crash) if they may or may not be facing in the same direction.