--- trunk/TODO 2011/05/10 13:32:53 1167
+++ trunk/TODO 2011/05/24 18:47:46 1257
@@ -5,6 +5,8 @@
SHORT TERM ============= (*needed* for streamlines & tractography)
========================
+Remove CL from compiler
+
[GLK:3] Add sequence types (needed for evals & evecs)
syntax
types: ty '{' INT '}'
@@ -23,12 +25,13 @@
SHORT-ISH TERM ========= (to make using Diderot less annoying to
======================== program in, and slow to execute)
-value-numbering optimization [DONE, but needs more testing]
+value-numbering optimization [DONE]
Allow ".ddro" file extensions in addition to ".diderot"
-Be able to output values of type tensor[2,2] and tensor[3,3]
-(currently only scalars & vectors)
+Be able to output values of type tensor[2,2] and tensor[3,3];
+(currently only scalars & vectors). Want to add some regression tests
+based on this and currently can't
[GLK:1] Add a clamp function, which takes three arguments; either
three scalars:
@@ -59,7 +62,7 @@
to index into complete list
[GLK:6] Use of Teem's "hest" command-line parser for getting
-any input variables that are not defined in the source file
+any "input" variables that are not defined in the source file.
[GLK:7] ability to declare a field so that probe positions are
*always* "inside"; with various ways of mapping the known image values
@@ -92,8 +95,10 @@
"initially" supports lists
-"initially" supports lists of positions output from
-different initalization Diderot program
+"initially" supports lists of positions output from different
+initalization Diderot program (or output from the same program;
+e.g. using output of iso2d.diderot for one isovalue to seed the input
+to another invocation of the same program)
Communication between strands: they have to be able to learn each
other's state (at the previous iteration). Early version of this can
@@ -180,6 +185,15 @@
There is value in having these, even if the differentiation of them is
not supported (hence the indication of "field#0" for these above)
+Introduce region types (syntax region(d), where d is the dimension of the
+region. One useful operator would be
+ dom : field#k(d)[s] -> region(d)
+Then the inside test could be written as
+ pos ∈ dom(F)
+We could further extend this approach to allow geometric definitions of
+regions. It might also be useful to do inside tests in world space,
+instead of image space.
+
co- vs contra- index distinction
Permit field composition:
@@ -195,15 +209,19 @@
field#2(3)[] F = bspln3 ⊛ img;
or, as a tensor product of kernels, one for each axis, e.g.
field#0(3)[] F = (bspln3 ⊗ bspln3 ⊗ tent) ⊛ img;
-This is especially important for things like time-varying data, or
-other multi-dimensional fields where one axis of the domain is very
-different from the rest, and hence must be treated separately when
-it comes to convolution. What is very unclear is how, in such cases,
-we should notate the gradient, when we only want to differentiate with
-respect to some subset of the axes. One ambitious idea would be:
+This is especially important for things like time-varying fields
+and the use of scale-space in field visualization: one axis of the
+must be convolved with a different kernel during probing.
+What is very unclear is how, in such cases, we should notate the
+gradient, when we only want to differentiate with respect to some
+subset of the axes. One ambitious idea would be:
field#0(3)[] Ft = (bspln3 ⊗ bspln3 ⊗ tent) ⊛ img; // 2D time-varying field
- field#0(2)[] F = lambda([x,y], Ft([x,y,42.0])) // restriction to time=42.0
- vec2 grad = ∇F([x,y]); // 2D gradient
+ field#0(2)[] F = lambda([x,y], Ft([x,y,42.0])) // restriction to time=42.0
+ vec2 grad = ∇F([x,y]); // 2D gradient
+
+Tensors of order 3 (e.g. gradients of diffusion tensor fields, or
+hessians of vector fields) and order 4 (e.g. Hessians of diffusion
+tensor fields).
representation of tensor symmetry
(have to identify the group of index permutations that are symmetries)
@@ -212,10 +230,35 @@
outer works on all tensors
+Help for debugging Diderot programs: need to be able to uniquely
+identify strands, and for particular strands that are known to behave
+badly, do something like printf or other logging of their computations
+and updates.
+
+Permit writing dimensionally general code: Have some statement of the
+dimension of the world "W" (or have it be learned from one particular
+field of interest), and then able to write "vec" instead of
+"vec2/vec3", and perhaps "tensor[W,W]" instead of
+"tensor[2,2]/tensor[3,3]"
+
+Traits: all things things that have boilerplate code (especially
+volume rendering) should be expressed in terms of the unique
+computational core. Different kinds of streamline/tractography
+computation will be another example, as well as particle systems.
+
Einstein summation notation
"tensor comprehension" (like list comprehension)
+Fields coming from different sources of data:
+* triangular or tetrahedral meshes over 2D or 3D domains (of the
+ source produced by finite-element codes; these will come with their
+ own specialized kinds of reconstruction kernels, called "basis
+ functions" in this context)
+* Large point clouds, with some radial basis function around each point,
+ which will be tuned by parameters of the point (at least one parameter
+ giving some notion of radius)
+
======================
BUGS =================
======================