Transformation: Compute looks like any other module when you place it into your network. Yet, one of the DX developers once told me that he estimates that the program code for Compute comprises on the order of 60% of the entire source code of Data Explorer! (I haven't counted program lines in the source code to prove this.)
Earlier, (at the end of the previous module), I assigned you the task of reading the Help on Compute. You may want to review it again.
Compute is a marvelous module because it permits the DX program to modify Object Component values on the fly. Without Compute, you would need to return to the program code that generated your data and output new data files, or in the case of experimental data, you would have to create preprocessing programs and run them on your data before you imported it into DX.
Here's a simple example: let's say the "temperature" data in your Field is in Fahrenheit degrees but you want to convert all values to metric. Without Compute, you would have to preprocess your data using the old Fahrenheit to Celsius conversion you learned in grade school:
C = (5/9) * (F - 32)
In DX, you can simply insert a Compute module into your network and perform this operation right in the program itself using virtually the exact expression above.
Here's the BIG RULE OF COMPUTE!
Compute always and only operates on the "data" Component.
|
|
As a teaser, there is a way to make any Component the "data" Component". Think about that for a moment. We'll return to this feature later when we discuss Mark and Unmark. |
In a plain old Field, with "positions", "connections", and "data", inserting a Compute into the data-flow program will permit you to do computations on the values in the "data" Component.
Let's build a test net to try this out. We'll use a data file from $DXROOT/dxsamples-x.x/data called "temperature.dx". This data file contains a 25x8x14 3D grid of scalar data. This data is from the thundercloud: there are several related but separate data files for this sample object, rainwater.dx, cloudwater.dx, and temperature.dx.
Import "temperature.dx"
MapToPlane
Compute
AutoColor
Image
Run the data-flow through the left-hand input on Compute. When you have the net all hooked up and the data filename typed into Import, Execute and see what happens.
What happens is you get an Error from Compute. Drat!
Just wanted to show you this because inevitably it will happen again. It's very easy to fix. Double-click on the Compute module to open its CDB. You see that Compute's CDB is rather different than other modules. There are two named inputs "a" and "b" and a space for an Expression. If you wired the modules as I suggested, you should see that only the "a" input is connected. It is not an error to leave the "b" input unconnected. The error is that we didn't enter any Expression for Compute to compute.
There are a number of possibilities at this point. The simplest Compute expression would be "a" (don't type the quotes in the Expression). Enter this, Execute again, and you should see a nice familiar image. Or not: Whoops, you forgot to hit Enter, didn't you? OK, again, whenever you make entries in dialog boxes, you should as a general rule hit Enter after your typing to force the dialog box to "see" the new text entry. Alternatively, in this case, you could have pressed OK (which closes the CDB and accepts the new entry), or Apply (which accepts the entry but leaves the box open for further editing).
Now, you have an image, colored by AutoColor, of the temperature data on the surface determined by the current location of the MapToPlane.
Open the Compute dialog again if you closed it, and change the Input Name "a" to "F". Ignore the "b" name for now.
You have just renamed an input. Execute the net. You'll get another error. Read the Error in the Message Window.
|
|
What would you do to fix the error?
Answer |
|
 |
Optional: View this Technical Aside if you want more detail on this subject; the information is not required to understand the upcoming material. |
This feature of providing your own names for the objects coming in via the input tabs of Compute is very handy. It permits you to create more readable expressions by using your own variable names in your expressions. If a variable is defined but not used in an expression (like "b"), it's no problem. But if you use an undefined variable as "a" was, after we removed its name definition, that is an error. So there are two solutions: replace the Input name "F" with "a" again (i.e., wimp out), or more usefully, change the Expression to read "F" (By using meaningful names, you're on the road to self-documenting Compute statements!). Remember, no quotes are typed in the Expression text area.
|
|
Optional: View this Technical Aside if you want more detail on this subject; the information is not required to understand the upcoming material. |
This has no effect on the net! It's just to get you used to being able to give good names to Compute inputs. If you made both edits to read "F" (input and expression), the "data" component values pass through Compute unchanged. The picture should look the same as when the name and expression read "a".
But now we're ready to convert to Celsius. Change the expression to: (5.0 / 9.0) * (F - 32) (The multiply symbol is the asterisk. It is not optional.)
Don't forget to hit Enter (key), OK, or Apply. Execute and you should see. . .(drum roll). . .the same image. Harrumph!
|
|
Why didn't the image change?
Answer |
Well, that seems like a big waste of time, right? But let me tell you a nifty secret: that little old expression you typed in just automatically changed 200 temperature values (25x8 since the default MapToPlane aligns in X-Y through the 3D volume). If you have ever used a "traditional" programming language, you note the complete lack of any iteration expressions. You did not need to write:
for i = 0 to 24
for j = 0 to 7
C = (5.0 / 9.0) * (F - 32)
end
end
or something similar. The nested iteration was done automatically for you by DX. Every grid point was visited and the same expression was done using that grid point's data value. The new result (in C degrees) was placed at that grid point's data value. That is, the old F degrees values are no longer in the "data" component when Compute is finished; they are overwritten by the result of the expression. As always, the old F data values are still in DX's memory: they are easily accessible from the output of Import or from MapToPlane. But the "data" in the Field that comes out of Compute is now in "C degrees". It is therefore a different, new Field than the one that went into Compute.
|
|
Optional: View this Technical Aside if you want more detail on this subject; the information is not required to understand the upcoming material. |
|
|
Optional: View this Technical Aside if you want more detail on this subject; the information is not required to understand the upcoming material. |
|
|
Optional: View this Technical Aside if you want more detail on this subject; the information is not required to understand the upcoming material. |
|
|
Note that I used decimal numbers for 5.0 and 9.0 in the Compute Expression. Why? To investigate this yourself, connect a Compute (all by itself, no inputs) to a Debugging: Echo. Enter the expression: (5/9) and Execute. The answer appears in the Message Window. Now change the expression to (5.0/9.0) and Execute and observe the answer.
Answer |
Try this: unhook Compute from AutoColor and Image, and move the Compute before MapToPlane. The new net is Import…quot;Compute…quot;MapToPlane…quot;AutoColor…quot;Image and the Compute expression is still the F to C conversion. Execute again and observe the Image.
|
|
Think about the data-flow operations. The Imported temperature data set is a 3D grid of values, 25x8x14. What does Compute do this time? What does MapToPlane do? What does AutoColor see as the data range at its input?
Answer |
So far, Compute seems like a big washout. All this Computing and the image looks the same! OK, let's do something a bit more interesting. Compute mutters: I'll be back.
