Live data from Hacker News

Bifurcate the Problem Space

potetm.com

11–20 of 37 posts

Re: Bifurcate the Problem Space

#11

I consider myself a "good" debugger, and I don't really know why. Reading this makes me think that I probably have several strategies, including this one, that I subconsciously use without having a label for them.

I really like this book (and have recommended it before on hn) http://debuggingrules.com/?page_id=31 - it helps to have a shared team vocab for some of the concepts.

There's a summary set of slides here that gives a great overview: https://courses.cs.washington.edu/courses/cse474/18wi/pdfs/l...

Re: Bifurcate the Problem Space

#12
post #8
post #7

Earlier quoted context omitted.

Bisection means dividing a curve into two equal parts. Bifurcation means divide, split, or fork something into two.

But of course bisection doesn't just apply to curves, and bifurcation only refers to certain kinds of division. You wouldn't bifurcate a cake or a number, for example. I feel like it refers to a continuous process of splitting e.g. in time like a species that evolves into two species or in space like a road that forks into two roads.

I think the key difference is that bisect refers to slicing something into equally sized parts. This is sometimes the case (see eg. git bisect) but bifurcating the problem space would be the more general term.

Re: Bifurcate the Problem Space

#13

I was fortunate enough to learn this strategy outside of a software context first. In grad school I was responsible for maintaining our GC-MS and LC-MS machines (Gas/Liquid Chromatograph / Mass Spectrometer) in addition to using them for my own experiments on a regular basis. They were complex pieces of equipment that had a ton of fiddly components. The best way to troubleshoot these machines was to split the problem…

I've always used "divide and conquer" which is a cliche for a reason. Bifurcate is commonly used by Indian colleagues, and perhaps programmers are familiar with the term, but it's not something used by US business people in my experience.

Also, binary search

Re: Bifurcate the Problem Space

#14

Earlier quoted context omitted.

I've always used "divide and conquer" which is a cliche for a reason. Bifurcate is commonly used by Indian colleagues, and perhaps programmers are familiar with the term, but it's not something used by US business people in my experience.

Also, binary search

I more often heard and used "bisect". Is that subtly different or subtly the same?

Re: Bifurcate the Problem Space

#15
The principle reminds me of a “bifurcation algorithm” I found to bifurcate and explore parameter space in a sort of novel way. It has its drawbacks! But it was fun to tinker with, too.

Effectively, we define some function to map N -> B, where N is the natural integers and B is in [0, 1]. (We can then apply some arbitrary function on B for our actual parameter value). We find the initial values as 0, 1, 0.5, 0.25, 0.75; that is: the extrema, all halves (1), all missed quarters (2), missed eighths (4), missed sixteenths (8), and so on. I used some binary representation of N to get B; there are probably other ways to do it.

I found this pretty useful at bifurcating a highly dimensional parameter space – it meant that made sure at all times I could get a decently equal view of all points (with bias towards B=0) in expanding detail. It also meant I didn’t have to think about allocation time, which was useful on a somewhat packed (but use-as-needed) compute cluster.

Re: Bifurcate the Problem Space

#16
The fact that the author is "commenting things out" makes me think that they don't have access to a debugger on their environment. When I find myself on that particular situation, I tend to:

* Add lots of logs (e.g. "entered function X with parameters a, b, c", "exited function X, return value W"). * "Make things explode in a useful way". This is, cause an error on purpose, which halts the program. This is useful for debugging server-like environments where many different things might happen at the same time, so the logs become insufficient. It is way slower than having a debugger doing step-by-step scrutiny, but it can be done.

Re: Bifurcate the Problem Space

#17
I do this, because I like dumb solutions. This, along with challenging assumptions, is basically how I debug. I love git bisect, a lot of people don't even know it's there.

I'll note that, when pair programming, the people who sit and reason about the code often outperform me, so the way I look at it I'm trading time against complexity.

Re: Bifurcate the Problem Space

#18
post #15

The principle reminds me of a “bifurcation algorithm” I found to bifurcate and explore parameter space in a sort of novel way. It has its drawbacks! But it was fun to tinker with, too. Effectively, we define some function to map N -> B, where N is the natural integers and B is in [0, 1]. (We can then apply some arbitrary function on B for our actual parameter value). We find the initial values as 0, 1, 0.5, 0.25, 0.7…

Sounds a lot like quasi-random low-discrepancy sequences like Sobol or Halton. Very effective tool to accelerate Monte Carlo integrations, which boils down to the effectiveness of exploring the phase space (but you have to make sure that sequences in different dimensions are independent!).

Re: Bifurcate the Problem Space

#19
post #8

Earlier quoted context omitted.

But of course bisection doesn't just apply to curves, and bifurcation only refers to certain kinds of division. You wouldn't bifurcate a cake or a number, for example. I feel like it refers to a continuous process of splitting e.g. in time like a species that evolves into two species or in space like a road that forks into two roads.

I think the key difference is that bisect refers to slicing something into equally sized parts. This is sometimes the case (see eg. git bisect) but bifurcating the problem space would be the more general term.

While bisect is indeed slicing into two (mostly) equal parts, bifurcation is creating two branches, and in my mind, with the intent of following up on both (at least initially). So what's done here is bifurcation with pruning, and I think bisect would be a more appropriate term -- certainly the attempt should be made to divide the problem space into equal parts.

Re: Bifurcate the Problem Space

#20
This is Troubleshooting 101; "Divide and Conquer."

My original training was as an electronic technician; specifically, an RF tech.

We would debug through a signal path.

The very first thing they taught us to do, was stick a probe in the halfway point, and see if the signal was what it was supposed to be.

Post reply on HN