So, first thing's first: the vectors that go from the grid points to the query point -- let's call them interior vectors.

These should *not* be normalized. Let's take, for example, the grid point at the bottom-left corner of our bounding box. The interior vector from that grid point to the query point has to be unique for that query point. Likewise, all points in this bounding box have to have unique interior vectors from that grid point. If you normalize the interior vectors, however, you lose the uniqueness: for example, if the bottom-left grid point is (0,0), then the query points (0.1,0.1), (0.25,0.25), (0.5,0.5), etc. will *all* generate the same, normalized vector. But if you leave those interior vectors un-normalized, they're all unique.

This does seem to lead to the behaviour you mentioned, of generating points purely in the [-0.5..0.5] range. I'm seeing it myself, and I can't track it down just yet -- evidently a factor of 2 missing somewhere in there. Anyway, the generated landscapes I'm seeing still look fine -- it's just a small scaling issue. The main point is to make sure the resulting noise "looks good" -- I may take off marks for arbitrary scaling factors, but if I do it will be minimal. Focus on the rest of the assignment first.

Now, pseudorandom gradient vectors. You need some source of randomness so that one particular "run" of the applet doesn't look like any previous one. You can do this by saving a static "global seed" which is initialized to a random number whenever the applet starts. Then, as you show, every time you calculate a single gradient vector (i.e., you have to do this four times at each octave) you have to re-seed the generator. But note that if you use the global seed as one of the seeding terms, all the gradient vectors for this particular run will look different from any other run (which is desired).

Unfortunately, there's no more "elegant" way to do this -- otherwise we'd have to compute and store gradient vectors for potentially every single grid point, which is of course infinite. As it stands, we just have to keep re-seeding and re-calculating the gradient vectors every time we use them. (Actually, I suppose you could keep a hash table mapping previously-seen grid points to gradient vectors, but this strikes me as overkill on what is fairly computationally trivial...and again you could potentially have to store an infinite amount of these.)

Finally, as for office hours: since it's the reading week, I hadn't planned on having the regularly-scheduled hours -- however, you can obviously always reach me by email. If there are more serious issues, I can schedule a meeting for later in the week.