The Graph Theory in C# (Part 2)
In my quest to create my own graph theory library in C#, I started out to be conventional to being radical. I searched the Internet how programmers were doing it and got overwhelmed by the varied approaches. So I started reading about graph theory and got just as drowned with TMI (too much information). Finally, I realized that my problem would be easier to solve if I just focused on the first page of my research: the definition of the graph.
It is when you find out more about graphs and how they are used and how they are visualized when you get lost in what a graph really is. That was the problem I had in my research. Just like how other programmers were suggesting, it seemed like I could never have a graph without the algorithms and visualizations that should go with it. However, materials about graph theory seem to suggest that the graph is just the data. Should I trust how programmers see the world? Or should I trust the graph theorists who wrote the books?
A retrospective was in order. What was I doing right? What was I doing wrong? What was I missing? What was my goal? Did I want a black ball? Or did I want a black ball that could do everything a black ball should do? Did I have enough time to reverse-engineer what others had spent a lifetime for? Did I really want to re-invent the wheel?
So I looked at what I had and what are already out there. I had the data I needed. I had no time. There were many tools available to process and visualize a graph -- all too many for the same thing that I wondered what was common? There had to be something already, right? Well, my research led me back and forth to the Boost Graph Library (I was jealous), which eventually led me to DOT, a graph description language. Eureka! That was the common denominator. There was actually an existing "language" that graph tools were sharing.
I realized that I didn't need a black ball that can do everything, like what programmers were suggesting. I just needed a black ball. All I really needed to do was a proper way to represent my data as a graph!
So I went back to page 1 (well, page 2 because I started with the programmers). I had a plan, but I wanted to make sure that my work would be nowhere less than what a graph should be. My graph library must agree with the accepted definition of the graph. There were many textual definitions available, but I wanted something that looked like it used the language of science: Mathematics. True enough, my page 1 (err... page 2), had it all along! The expression that saved the day was not as cryptic as it may seem: G = (V, E) -- a graph G is a collection of vertices V and edges E (read more here). That's all I needed!
My quest was almost complete. I just needed to start writing the code. Time was running out...
It is when you find out more about graphs and how they are used and how they are visualized when you get lost in what a graph really is. That was the problem I had in my research. Just like how other programmers were suggesting, it seemed like I could never have a graph without the algorithms and visualizations that should go with it. However, materials about graph theory seem to suggest that the graph is just the data. Should I trust how programmers see the world? Or should I trust the graph theorists who wrote the books?
A retrospective was in order. What was I doing right? What was I doing wrong? What was I missing? What was my goal? Did I want a black ball? Or did I want a black ball that could do everything a black ball should do? Did I have enough time to reverse-engineer what others had spent a lifetime for? Did I really want to re-invent the wheel?
So I looked at what I had and what are already out there. I had the data I needed. I had no time. There were many tools available to process and visualize a graph -- all too many for the same thing that I wondered what was common? There had to be something already, right? Well, my research led me back and forth to the Boost Graph Library (I was jealous), which eventually led me to DOT, a graph description language. Eureka! That was the common denominator. There was actually an existing "language" that graph tools were sharing.
I realized that I didn't need a black ball that can do everything, like what programmers were suggesting. I just needed a black ball. All I really needed to do was a proper way to represent my data as a graph!
So I went back to page 1 (well, page 2 because I started with the programmers). I had a plan, but I wanted to make sure that my work would be nowhere less than what a graph should be. My graph library must agree with the accepted definition of the graph. There were many textual definitions available, but I wanted something that looked like it used the language of science: Mathematics. True enough, my page 1 (err... page 2), had it all along! The expression that saved the day was not as cryptic as it may seem: G = (V, E) -- a graph G is a collection of vertices V and edges E (read more here). That's all I needed!
My quest was almost complete. I just needed to start writing the code. Time was running out...
Comments
Post a Comment