![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
stoutfellowAll last week I was struggling to construct algorithms. I'm given a body of data - call it A. The data in A is combinatorial in nature; it represents travel on the surface of a polyhedron by giving the sequence of edges the path crosses. (The path eventually closes up on itself, forming, so to speak, a loop.) What I want to do is to answer one question: does the path cross itself?
The plan of attack worked like this: I wanted to extract more combinatorial information - call it B - which should answer the question. This information had to do with how many times, and in what way, the loop crosses other paths, which run between the vertices of the polyhedron. Repeated efforts, however, failed to get all of B. I finally, reluctantly, decided that I needed to construct some numerical, not merely combinatorial, data - not just that the loop crosses this edge, but where it crosses. I didn't want to do this; it seemed... inelegant.
I spent the weekend trying to work out how to construct and use the numerical data.
Sunday evening and this morning, I worked myself around to the conclusion that, even reinforced with the numerical data, the information in B wouldn't be enough to answer the question. I had to come up with a different line of attack altogether.
Around noon, I decided how to go at it; forget elegance, let's just crank numbers.
The problem seemed straightforward, but there were some structural incongruencies between the combinatorial and the numerical data, and I wound up with a rather ugly kludge fitting them together.
Around 3:30, I got it all patched together. I have no doubts about the procedure; if I'm concerned about anything, it's whether I've actually implemented the procedure in the algorithm. But I'm pretty confident. It's already cleared several hurdles that the previous work stumbled at.
I'm going to have to take another look at the code, and make sure that it actually does what I designed it to do. I'm fairly optimistic, though.
(I know, I'm probably giving too much detail for those who aren't mathematically inclined, and not enough for those who are, but it's been a long day and I'm tired.)
The plan of attack worked like this: I wanted to extract more combinatorial information - call it B - which should answer the question. This information had to do with how many times, and in what way, the loop crosses other paths, which run between the vertices of the polyhedron. Repeated efforts, however, failed to get all of B. I finally, reluctantly, decided that I needed to construct some numerical, not merely combinatorial, data - not just that the loop crosses this edge, but where it crosses. I didn't want to do this; it seemed... inelegant.
I spent the weekend trying to work out how to construct and use the numerical data.
Sunday evening and this morning, I worked myself around to the conclusion that, even reinforced with the numerical data, the information in B wouldn't be enough to answer the question. I had to come up with a different line of attack altogether.
Around noon, I decided how to go at it; forget elegance, let's just crank numbers.
The problem seemed straightforward, but there were some structural incongruencies between the combinatorial and the numerical data, and I wound up with a rather ugly kludge fitting them together.
Around 3:30, I got it all patched together. I have no doubts about the procedure; if I'm concerned about anything, it's whether I've actually implemented the procedure in the algorithm. But I'm pretty confident. It's already cleared several hurdles that the previous work stumbled at.
I'm going to have to take another look at the code, and make sure that it actually does what I designed it to do. I'm fairly optimistic, though.
(I know, I'm probably giving too much detail for those who aren't mathematically inclined, and not enough for those who are, but it's been a long day and I'm tired.)
