Monday, August 04, 2003

Fixing Medicine. So basically Steve is saying "Blame Government".  The current system keeps armies of people at work in doctor's offices whose only job is to chase down insurance companies for payment.  A similar army exists on the other side, working at the insurance companies.  Their raison-d'etre is to find some way, any way, to avoid paying doctors for as long as possible. The problem with the free market approach to medicine is that THERE'S NO STABILIZING MARKET FORCES AT WORK.  On one hand you're spouting that $12,000 is too much for a busted arm, and on the other hand you're saying that privatization is good!  The problem is that no-one in the system makes decisions based on prices.  No one except insurance companies, who are in an after the fact situation. Because medicine is a life or death matter, we should just face facts and recognize that our system as it stands simply does not work. I advocate the following (and I am completely, unassailably right).  First, end health insurance programs as we know them.  Gone.  Catastrophic insurance is then extended to all citizens, by the government.  Use accounting rules to fix the profit percentage for this, giving them a fair margin, and rewarding them for comparative fiscal efficiency.  Day to day visits are now the responsibility of individual citizens.  For low income earners, graduated assistance programs are available to help with wellness care. Vast amouts of cash are spent within the current system on extremely expensive drug therapies and machinery.  Those will become the domain of the private medicine system.  If, on a cost-benefit basis, a given therapy does not yield sufficient benefit (lives saved), those dollars can and will be redirected to where they'll do the most good.  Society can then argue about what percentage of GDP they'd like to spend on health care, and be reasonably assured that it is going to the right places. 3:05:20 PM    comment []

A Little on LOD. Responding to Ben Bederman: Thanks for the additional information on Piccolo's approach to LOD. Here are my thoughts. I think it's useful to make a separation between macro- and micro-LOD. I view micro-LOD as being at the primitive rendering level, and macro as the application level. You are absolutely correct in that every application needs and benefits from micro-level LOD, and that we have _some_ support in the Java2D platform to help us out here (ellipse line segment generation, for example). For any 2.5d UI, though, you pretty much need to know when you get "close" to a node, so you can create additional detail. Creating additional detail can mean populating the scene graph with additional nodes, or it can mean drawing an existing node differently. It can also mean both of those activities. You might also want have more than one gradiation, depending on how complex the node is. Most metrics for the "switch" between levels of detail will involve a pixel-based metric. That is, when a node becomes sufficiently discernible by the viewer, something happens. Working from zoom factors is an indirect way of accomplishing the same thing, and I think it clouds the waters. Ultimately we're dealing in pixels, pushed to the screen (well, if Piccolo were rendering to a vector-based display system that wouldn't be true, but we'll discount that uncommon case for now, unless anybody has an old asteroids machine around they've modified to run Java). So it makes sense to be able to declare a series of thresholds, measured in pixels. The zoom factor is essentially pixels per unit length, so it can perhaps be used the same way. I think if the goal of Piccolo is to make applications as simple as possible to write, then as a writer I want to be able to do something when my node grows to 10x10 visible pixels, then do something again when it grows to 100x100. This is a retreat from the notions of continuous level of detail that are largely prevalent in the 3D world. We do not need such sophistication; I am in complete agreement with you there. To create our simplified thresholding system, I would modify the event handling system to have an additional LODEvent, where that event contains the visibility, distance from the center point of the camera, current zoom factor of a node and the pixel size of that node. One or more pixel/zoom/distance thresholds could be registered with the camera, and/or for nodes. As the node is painted/zoom in upon, appropriate LODEvents are issued. This single mechanism could accomodate a pretty large number of cases. We don't attack the continuous LOD problem, but we do provide a simple mechanism (with a couple of modes) that can be used to achieve the very common cases. In addition, strategies for deferred loading and so forth could be added in the future. The Piccolo core can also be judicious in its issuance of LODEvents, in order to maintain frame rates. The real question, is the added complexity of a system like this worth it, in terms of the base library. I can't really answer that question. I can say that based on my observations, many (if not most) ZUI apps that deal with larger data sets will greatly benefit from not having to recreate such a framework. I am playing with a couple of different domains right now; the first is display of time-based information in a timeline form. The second is financial data set display. I anticipate needing LOD support for the first, but not necessarily for the second (although as the data sets climb in size, it might become necessary). It's entirely appropriate for the interested parties here to come up with this kind of functionality. If something sufficiently good is developed, I think we can make a case for it becoming part of the core. I say "core" because I think some of the events that we need to generate are best handled there, and might be difficult to add as extensions. 12:19:43 AM    comment []