Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p><strong>Think of how a monitor works:</strong> </p> <p>It is updated at 60&nbsp;Hz -- 60 times a second. Flicker flicker flicker 60 times, but your eyes are slow and can't <em>really</em> tell. The monitor shows whatever is in the output buffer; it just drags this data out every 1/60th of a second no matter what you do.</p> <p>Now why would you want your program to update the whole buffer 60 times a second if the image shouldn't change that often? What if you only change one pixel of the image, should you rewrite the entire buffer?</p> <hr> <p>This is an abstraction of the basic idea: you want to change the output buffer based on what information you want displayed on the screen. You want to save as much CPU time and buffer write time as possible, so you don't edit parts of the buffer that need not be changed for the next screen pull. </p> <p>The monitor is separate from your computer and logic (programs). It reads from the output buffer at whatever rate it updates the screen. We want our computer to stop synchronizing and redrawing unnecessarily. We can solve this by changing how we work with the buffer, which can be done in a variety of ways. His technique implements a FIFO queue that is on delay -- it holds what we just sent to the buffer. The delayed FIFO queue does not hold pixel data, it holds "shape primitives" (which might be pixels in your application, but it could also be lines, rectangles, easy-to-draw things because they are just shapes, no unnecessary data is allowed).</p> <p>So you want to draw/erase things from the screen? No problem. Based on the contents of the FIFO queue I know what the monitor looks like at the moment. I compare my desired output (to erase or draw new primitives) with the FIFO queue and only change values that need to be changed/updated. This is the step which gives it the name Differential Evaluation.</p> <p><strong>Two distinct ways</strong> in which I appreciate this:</p> <p><strong>The First:</strong> Mike Dunlavey uses a conditional-statement extension. The FIFO queue contains a lot of information (the "previous state" or the current stuff on monitor or time-based polling device). All you have to add to this is the state you want to appear on screen next.</p> <p>A conditional bit is added to every slot that can hold a primitive in the FIFO queue.</p> <pre><code>0 means erase 1 means draw </code></pre> <p>However, we have previous state:</p> <pre><code>Was 0, now 0: don't do anything; Was 0, now 1: add it to the buffer (draw it); Was 1, now 1: don't do anything; Was 1, now 0: erase it from the buffer (erase it from the screen); </code></pre> <p>This is elegant, because when you update something you really only need to know what primitives you want to draw to the screen -- this comparison will find out if it should erase a primitive or add/keep it to/in the buffer.</p> <p><strong>The Second:</strong> This is just one example, and I think that what Mike is really getting at is something that should be fundamental in design for all projects: Reduce the (computational) complexity of design by writing your most computationally intense operations as computerbrain-food or as close as you can get. Respect the natural timing of devices.</p> <p>A redraw method to draw the entire screen is incredibly costly, and there are other applications where this insight is incredibly valuable.</p> <p><em>We are never "moving" objects around the screen. "Moving" is a costly operation if we are going to mimic the physical action of "moving" when we design code for something like a computer monitor. Instead, objects basically just flicker on and off with the monitor. Every time an object moves, it's now a new set of primitives and the old set of primitives flickers off.</em></p> <p>Every time the monitor pulls from the buffer we have entries that look like</p> <pre><code>Draw bit primitive_description 0 Rect(0,0,5,5); 1 Circ(0,0,2); 1 Line(0,1,2,5); </code></pre> <p>Never does an object interact with the screen (or time-sensitive polling device). We can handle it more intelligently than an object will when it greedily asks to update the whole screen just to show a change specific to only itself.</p> <p>Say we have a list of all possible graphical primitives our program is capable of generating, and that we tie each primitive to a set of conditional statements </p> <pre><code>if (iWantGreenCircle &amp;&amp; iWantBigCircle &amp;&amp; iWantOutlineOnMyCircle) ... </code></pre> <p>Of course, this is an abstraction and, really, the set of conditionals that represents a particular primitive being on/off could be large (perhaps hundreds of flags that must all evaluate to true).</p> <p>If we run the program, we can draw to the screen at essentially the same rate at which we can evaluate all these conditionals. (Worst case: how long it takes to evaluate the largest set of conditional statements.)</p> <p>Now, for any state in the program, we can simply evaluate all the conditionals and output to the screen <em>lightning-quick!</em> (We know our shape primitives and their dependent if-statements.)</p> <p>This would be like buying a graphically-intense game. Only instead of installing it to your HDD and running it through your processor, you buy a brand-new board that holds the entirety of the game and takes as input: mouse, keyboard, and takes as output: monitor. Incredibly condensed conditional evaluation (as the most fundamental form of a conditional is logic gates on circuit boards). This would, naturally, be very responsive, but it offers almost no support in fixing bugs, as the whole board design changes when you make a tiny design change (because the "design" is so far-removed from the nature of the circuit board). At the expense of flexibility and clarity in how we represent data internally we have gained significant "responsiveness" because we are no longer doing "thinking" in the computer; it is all just <em>reflex</em> for the circuit board based on the inputs.</p> <p>The lesson, as I understand it, is to divide labor such that you give each part of the system (not necessarily just computer and monitor) something it can do well. The "computer thinking" can be done in terms of concepts like objects... The computer brain will gladly try and think this all through for you, but you can simplify the task a great deal if you are able to let the computer think in terms of data_update and conditional_evals. Our human abstractions of concepts into code are idealistic, and in the case of internal program draw methods a little overly idealistic. When all you want is a result (array of pixels with correct color values) and you have a machine that can <em>easily</em> spit out an array that big every 1/60th of a second, try and eliminate as much flowery thinking from the computer brain as possible so that you can focus on what you really want: to synchronize your graphical updates with your (fast) inputs and the natural behavior of the monitor.</p> <p><strong>How does this map to other applications?</strong> I'd like to hear of other examples, but I'm sure there are many. I think anything that provides a real-time "window" into the state of your information (variable state or something like a database... a monitor is just a window into your display buffer) can benefit from these insights.</p>
    singulars
    1. This table or related slice is empty.
    1. POHow does differential execution work?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USPeter Mortensen
    1. USsova
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. CO++ I appreciate your take on it. For me, initially it was an attempt to do program-described displays on slow devices (think 9600-baud remote text terminals), where it would basically do an automated *diff* & transmit minimal updates. Then I was pressed on why not just code this by brute force. The answer: because if the surface form of the code is as if it's a simple *paint*, it's shorter, nearly bug-less, therefore done in a fraction of the development time. (That's what I think of as the benefit of a DSL.)
      singulars
      1. PO
      1. USMike Dunlavey
    2. CO... The development effort that is freed up can then be re-invested in more sophisticated and dynamic displays, that users find responsive and pleasing. So you get more UI bang for the developer buck.
      singulars
      1. PO
      1. USMike Dunlavey
    3. CO... Example: this app from about 10 years ago: http://www.pharsight.com/products/prod_pts_using_dme.php
      singulars
      1. PO
      1. USMike Dunlavey
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload