Thursday, November 26, 2009
Monday, November 16, 2009
Dynamic call graph treemaps
I'm trying to come up with new visualization techniques for analyzing code. The static structure diagrams / UML diagrams are all well and fine, but I kind of want something that shows the relationship among objects resulting from the actual code execution.
So I'm looking at whether you can create a tree map, where the tree reflects the call hierarchy of the code with each method as a node, but then the size of each node in the tree map is proportional to the amount of time spent executing that method. And maybe a very Tufte-esque graph inside each node could reflect consumption of resources (like memory) that were allocated / released during the execution.
So I'm looking at whether you can create a tree map, where the tree reflects the call hierarchy of the code with each method as a node, but then the size of each node in the tree map is proportional to the amount of time spent executing that method. And maybe a very Tufte-esque graph inside each node could reflect consumption of resources (like memory) that were allocated / released during the execution.
Quitwiki
What if there was a wiki, a kind of DIY site that specifically concentrated on quitting services, products, etc. while preserving the value obtained from those services, products, etc. I guess the basic idea is to pool collective knowledge to lower switching costs for products and services.
For instance, if I want to stop using Quicken to manage my money (maybe to switch to Mint.com, or to just use spreadsheets), then I could go to this "Quitwiki" to find out about how to ensure the highest level of data portability, potential compatibility issues, etc. I think one of the main things it would need to provide is tools for conversion and access to file formats, APIs, and other tools like that.
For instance, if I want to stop using Quicken to manage my money (maybe to switch to Mint.com, or to just use spreadsheets), then I could go to this "Quitwiki" to find out about how to ensure the highest level of data portability, potential compatibility issues, etc. I think one of the main things it would need to provide is tools for conversion and access to file formats, APIs, and other tools like that.
Saturday, November 14, 2009
LINQ to Fields
I've been looking in to the lambda expression capability in LINQ / C# 3.0, and it occurred to me that it provides the perfect mechanism for implementing a field abstraction that I have been thinking about for a while. The idea is that an image / volume / region / transform is represented at its most basic level as a lambda which takes a vector is input and produces a scalar, vector, or bool as its output.
The most interesting part is the use of the Expression<> to create expressions trees. This allows lambdas to be combined in to algebraic expressions to form new lambdas, but the result is an expression tree that can be examined via reflection. So, one could assemble the lambda that represents some image processing operation, and then an inference could be made to construct a pipeline (for instance, with ITK) that implements the expression.
Then LINQ could be used to construct these expressions, given a set of data objects and possible transformations that could be applied. Each field entity would have the necessary attributes to describe how it could be combined with other entities, and then the LINQ query would do the combining.
The most interesting part is the use of the Expression<> to create expressions trees. This allows lambdas to be combined in to algebraic expressions to form new lambdas, but the result is an expression tree that can be examined via reflection. So, one could assemble the lambda that represents some image processing operation, and then an inference could be made to construct a pipeline (for instance, with ITK) that implements the expression.
Then LINQ could be used to construct these expressions, given a set of data objects and possible transformations that could be applied. Each field entity would have the necessary attributes to describe how it could be combined with other entities, and then the LINQ query would do the combining.
Friday, October 30, 2009
Visit to St. Charles
Having been working on a project that involves the team in St. Louis, I have been lucky enough to travel there several times over the past couple of months. Lucky, because some of my family is still in St. Louis so I get to visit them.
For this trip, we went out to eat at a quirky restaurant in old St. Charles called Vivian's Vineyard. Here are some pictures from the restaurant (with my nieces, sister, and mother featured prominently).
For this trip, we went out to eat at a quirky restaurant in old St. Charles called Vivian's Vineyard. Here are some pictures from the restaurant (with my nieces, sister, and mother featured prominently).
Friday, June 12, 2009
Trip to Gulf Shores, AL
Visited Fort Morgan / Gulf Shores with the relatives. Very relaxing out on the end of the peninsula. Didn't see any sharks, but occasionally dolphins could be seen swimming in schools off the shore.
The photo album is clearly very weak -- I'm not sure why I didn't take more pictures. We did lots of stuff, like visiting Dauphin Island, the USS Alabama, driving to Orange Beach, and of course hanging out on the beach. These photos are from the historic Fort Morgan, which was a civil war fort at the very end of the peninsula.
The photo album is clearly very weak -- I'm not sure why I didn't take more pictures. We did lots of stuff, like visiting Dauphin Island, the USS Alabama, driving to Orange Beach, and of course hanging out on the beach. These photos are from the historic Fort Morgan, which was a civil war fort at the very end of the peninsula.
Tuesday, December 18, 2007
Writer's strike solution
The networks need to create a new Reality TV show with a group of unemployed writers living together in a house in the Hollywood Hills. Each episode involves them getting in to a zany situation, and then they have to write themselves out of it...
Wednesday, May 16, 2007
Innovation and Risk
Having recently completed the first phase of a new inverse planning algorithm for radiation treatment planning, I have been thinking a lot about the relationship between innovation and risk. Of course, everyone knows that innovation is intrinsically risky, but the question is: what are all of the components of this risk, and can all be mitigated as efficiently as possible?
The commitment of time and resources to the initial development of a new idea is one of the first sources of risk in innovation. This risk can best be managed by following a path that develops the innovation to a suitable state for evaluation, while expending a minimal amount of resources.
But once this point has been reached, there is still further risk that persists, due to the need to couple further development to pragmatic concerns of how the innovation is to be used (productization). While this will consume even more resources, it seems that the current market(s) for innovation could benefit from significant improvements in efficiency of how this risk is mitigated.
For any new innovation, there will always be some early adopters who would be willing to expend some of their own resources toward the productization of a promising new technology. The problem is that this early adopter's risk is not efficiently mitigated, because the adopters themselves seem to only get intangible benefits from this risk. For instance, a high-profile clinic with many researchers will undertake new technologies because it allows their researchers to maintain their status as cutting-edge innovators. This means that, when deciding which innovations to adopt, they will mostly evaluate the likely "halo effect" of being associated with a ground-breaking new technology, which is an intangible benefit that eludes quantitative evaluation. Thus they will tend to be looking for "blockbuster" technology, much like Hollywood makes money mostly on a few blockbuster movies. Smaller independent films need financiers who are more willing to undertake smaller risks for smaller possible benefits, in return for equity interest.
But why can't early adopters in technology also partake in "equity interest" of some sort for their risk? This might encourage more commitment of resources during the productization phase of innovation, which would then make the initial development phase correspondingly less risky as well.
The commitment of time and resources to the initial development of a new idea is one of the first sources of risk in innovation. This risk can best be managed by following a path that develops the innovation to a suitable state for evaluation, while expending a minimal amount of resources.
But once this point has been reached, there is still further risk that persists, due to the need to couple further development to pragmatic concerns of how the innovation is to be used (productization). While this will consume even more resources, it seems that the current market(s) for innovation could benefit from significant improvements in efficiency of how this risk is mitigated.
For any new innovation, there will always be some early adopters who would be willing to expend some of their own resources toward the productization of a promising new technology. The problem is that this early adopter's risk is not efficiently mitigated, because the adopters themselves seem to only get intangible benefits from this risk. For instance, a high-profile clinic with many researchers will undertake new technologies because it allows their researchers to maintain their status as cutting-edge innovators. This means that, when deciding which innovations to adopt, they will mostly evaluate the likely "halo effect" of being associated with a ground-breaking new technology, which is an intangible benefit that eludes quantitative evaluation. Thus they will tend to be looking for "blockbuster" technology, much like Hollywood makes money mostly on a few blockbuster movies. Smaller independent films need financiers who are more willing to undertake smaller risks for smaller possible benefits, in return for equity interest.
But why can't early adopters in technology also partake in "equity interest" of some sort for their risk? This might encourage more commitment of resources during the productization phase of innovation, which would then make the initial development phase correspondingly less risky as well.
Wednesday, March 21, 2007
Knowledge Visualization
A number of techniques and applications exist to automatically visualize graphs or concept maps. I'm particularly interested in techniques that involve interactive, animated visualization techniques. I have developed a novel knowledge visualization environment called theWheel that provides a compelling animated depiction knowledge represented using a graph-based formalism [such as data encoded using the Semantic Web's Resource Description Framework (RDF)].
But I would like to explore some more sophisticated techniques utilizing the Kohonen map...
But I would like to explore some more sophisticated techniques utilizing the Kohonen map...
Wednesday, February 14, 2007
Rubberneck TV
I sat in a traffic jam on I-280 this morning that stretched for ~5 miles, apparently caused by a motorcycle accident. I realized that there is a very cool and useful feature that should be available for current model cars, what with their LCD panels and communication systems built in to the navigation dashboard: RubberneckTV!
The basic idea is that when a traffic backup occurs due to a crash, there could be a single reporter with a camera (or maybe even a passing motorist vlogger) that is on the scene right away. They would have access to a special mobile transmitter, able to transmit footage and a live report to the cars waiting in traffic due to the crash.
So people could tune in, find out about the crash, find out if anyone was hurt, etc. They could get their entire fix of the most immediately relevent news item in their life at the moment. After 30 minutes of waiting in traffic, when they finally reach the crash scene, there will be no slowing down to take a look, because it will already be stale news...
The basic idea is that when a traffic backup occurs due to a crash, there could be a single reporter with a camera (or maybe even a passing motorist vlogger) that is on the scene right away. They would have access to a special mobile transmitter, able to transmit footage and a live report to the cars waiting in traffic due to the crash.
So people could tune in, find out about the crash, find out if anyone was hurt, etc. They could get their entire fix of the most immediately relevent news item in their life at the moment. After 30 minutes of waiting in traffic, when they finally reach the crash scene, there will be no slowing down to take a look, because it will already be stale news...
Subscribe to:
Posts (Atom)
-
Looking at the CQRS architectural pattern, there are interactions that maybe I didn’t fully understand. Like if the target of queries/comma...
-
Dicom syntax can be encoded in a songle kaitai yaml
-
One of the problems to be addressed for adaptive treatment paradigms is the need to visualize and interact with deformable vector fields (...