This week will start off my first major holiday of the year, so I'm in a rather happy mood. Unfortunately, this starts Wednesday and leaves only today and tomorrow (Mon and Tues) for work. I have therefore decided to spend these two days "profiling", organising and protecting my existing code. Refinement of the approximations may be continued but as this is a long process, I feel there is not enough time to warrant starting what I will only pick up again after a weeks break.
I'm also hoping the clearer and more organised code will help in understanding the behaviour of some of the algorithms; such as why, when taking into account all parts of the grid containing vertices, the vertices stick to the outside of their parent section (as shown in my previous post).
This is most likely to be my last post until I return next Tuesday, unless I discover anything interesting hidden in my work, so for now, have a fun week working and lets all prayer the weather clears up, and don't let the thought of me relaxing in the middle of a field, with the sun shining down on me, drinking an ice cold beer, put you off your work.
<EDIT>
Having monitored the output from a single randomly chosen vertex (I chose vertices[0] heh, totally random), and printed the coordinates and grid reference in order to watch its path. The test runs 50 iterations per coarse level.
During the beginning of each level, there is a quick movement due to the change in the environment (two vertices being placed in the same place as one for example). This "cools" off due to the cooling scheme as the level progresses. These changes become less powerful as levels pass.
In the last 2 levels, the vertex skips between two grid squares, suggesting the forces push it out of one, then the forces from the new square push it back. Peculiar behaviour. I will need to check with the forces between vertex and grid to see what's causing this but it seems likely the forces do not match up (they're "unfair").
</EDIT>
No comments:
Post a Comment