12 recent entries Archive:
Subtopics:
Comments disabled |
Wed, 17 Jan 2007
Linogram development: 20070117 Update
require "polygon"; polygon t1(N=3), t2(N=3); constraints { t1.v[0] = (0, 0); t1.v[1] = (1, 1); t1.v[2] = (2, 3); t2.v[i] = t1.v[i-1]; }This defines two polygons, t_{1} and t_{2}, each with three sides. The three vertices of t_{1} are specified explicitly. Triangle t_{2} is the same, but with the vertices numbered differently: t_{2}.v_{0} = t_{1}.v_{2}, t_{2}.v_{1} = t_{1}.v_{0}, and t_{2}.v_{2} = t_{1}.v_{1}. Each of the triangles also has three edges, defined implicitly by the definition in polygon.lino:
require "point"; require "line"; define polygon { param index N; point v[N]; line e[N]; constraints { e[i].start = v[i]; e[i].end = v[i+1]; } }All together, there are 38 values here: 2 coordinates for each of three vertices of each of the two triangles makes 12; 2 coordinates for each of two endpoints of each of three edges of each of the two triangles is another 24, and the two N values themselves makes a total of 12 + 24 + 2 = 38. All of the equations are rather trivial. All the difficulty is in generating the equations in the first place. The program must recognize that the variable i in the polygon definition is a dummy iterator variable, and that it is associatated with the parameter N in the polygon definition. It must propagate the specification of N to the right place, and then iterate the equations appropriately, producing something like:
e_{0}.end = v_{0+1}Then it must fold the constants in the subscripts and apply the appropriate overflow semantics—in this case, 2+1=0. Open figures still don't work properly. I don't think this will take too long to fix. The code is very messy. For example, all the Type classes are in a file whose name is not Type.pm but Chunk.pm. I plan to have a round of cleanup and consolidation after the 2.0 release, which I hope will be soon.
[Other articles in category /linogram] permanent link |