1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
|
TO DO and Changes to make to CirclePack:
-- Want way to find out what vertex is currently centered at origin.
-- shading_err.cmd shows annoying problem with shading of discs on
the sphere
-- When trying to specify a redchain with "fix -f <f..>", there is a
problem with blue faces -- they can get left out. This results from
my approach: I use the putative red chain to identify "poison"
verts. Then the blue faces can get passed by as the new red chain
is generated.
-- "print" causes segmentation. The "post_fp" file pointer is not
being opened.
-- Need "edge picking" capability (at least for euclidean). Put
screen in correct mode, then pick edges with the mouse.
-- Need to check out the "mend" routines.
-- Need way to keep centers unchanged but apply mobius maps for
desired screen display -- probably not something for CirclePack,
but rather for standalone routines. However, might store the
current Mobius in file and, when it's there on read, apply it
before displaying.
-- Check that display option flags are updated to repeat last display
-- Can we get Vlist call, if empty, to default to none rather than all
circles?
-- Way to plot in order, but only display the circles around a designated vert
as it's layed out.
-- Need routine to pin down where layout errors are started.
-- Should be able to cut out, repack, and blend back in a section of
a packing to fix locallized flaws. Need functionality for following
curves overlaying a circle packing.
-- Need to build chains of circles/faces lying along a curve because:
* want to draw them, make list
* want to cut out, repack, blend back in partions of a packing
surrounded by a curve
* want to build piecewise linear map between circle packings
so need efficient way to find faces line passes through.
-- Might arrange in layout order to bypass 4 degree (and 5 degree?) vertices
and put them im later. Might also (after talking with Chuck) go back
after star of vert is completed and jiggle it to distribute any
plotting errors.
-- Triangle color doesn't get written. eg. with -M
-- may need to "molify" triangles to smooth placement.
-- add "color" to info reported on faces/circles
-- erroneous "blend usage" message with ?vert call.
-- calling ?vert with index exceeding nodecount defaults to
some vert number. Why?
- internally might use fread/fwrite calls to store stuff
in binary form -- eg. with temporary p_light data.
- Reorganize color routines: make _call routine which is easier to
maintain, default to circles without -f flag, color by angle sum
over/under, copy color should use vertex_map if available.
Other coding: compare p1 p2, but put colors, eg, in p0. Color
files reflecting "activity" in packing computation, eg, number
of increases, decreases.
- build a Java interface to run Repack in various ways. Use it
as a training device to develop automated methods for a
program executive to parcel out the repacking tasks in a
parallel implementation.
- Consider using "flood" technology for getting red chain for
other tasks. E.g. in original processing of data, to help handle
"walls", disconnected pieces, non local-planarity, etc.
- maybe hyp circle labels should be at eucl center?
- develop formula for hyp center of triangle, put labels there.
- put colors and labels in post_any_face, check draw_any_face, etc.
- incorporate some high-precision routines using pari libraries,
called when you want extra precision. E.g., perhaps Mobius
transforms should always be computed this way. Should have
repack routine, slow but accurate.
- with flags, might get rid of redundant routines, e.g., drawing
circle/face numbers.
- put multiply-connected demo in demo.cmd chain.
- do you save any cycles in C by using, eg, 'redlist' for 'p->redlist'??
I think not, but might save by only sending to subroutine those
parts of p needed.
- what does fix -l do in non-simply connected case?
- Should redfaces be discarded for simply connected complexes
(unless, eg., there is a drawlist)?
- check "slit" and allow it to cut from bdry to bdry
- need combinatorial routines for:
short path from v to w
n-generation subcomplex from v (with holes filled in)
(May be able to do this by setting red chain
type growth and, to catch holes, observing
when it first touches itself.
- Dual graph construction?
- parens programmed in edge_list_parse. (e.g. along a bdry or
red chain segment, along shortest path between, etc. )
- check what happens to new redfaces info under hex_refine?
- methods to improve quality of red chain: e.g., eliminate
edge-paired blue faces? When red chain first hits self,
try to balance added faces on the opposite sides? Go back
in and move the red chain? E.g., make adjustments in
fundamental domain -- perhaps clicking and moving individual
faces?
- "protected vertex" list to facedraworder as alternative to
"drawlist". (Will take some more thought and planning.)
- no longer need to prune faces without interior ngbh's, e.g.
in cookie.
- circles on sphere are "backward" compared to flat map -- math is
correct, but not consistent with normal thinking. Maybe put option
in .packrc
- should have button to bring up canvas "deiconify" it if it's an icon.
- fix reading command in DesPack; maybe use "select" process
- Translation stuff:
- read in, set flag
- else, reset table on read.
- table will be corrupted on some comb changes. Flush?
- write out in M write mode
- "pair_picking" routine can be problem if vertices for string
of edges are not in correct order.
- where do colors of horocycles come from?
- what's diff between -e and -e a?
- Hook in *.html scripts
=============================
- if inv_distances always fall in certain patterns, might be able
to improve recompute time by specialized routines, e.g. models
like Chuck's "uniform" neighbor.
- might try lookup tables for speeding some computations
- In live action settings, might be able to give preliminary results as
computations are proceeding: e.g., repack large but local nbhd and
display while real computations continue in background. Similarly for
refinements -- could go ahead and compute local bit while rest is
being packed.
- 'get_data -v' should transfer vertex_map.
- should all vertex_map stuff be in map?
- need Vertex_map utility string.
- need to madify translation procedures to allow more general
vertex_maps. Complication: to check index size, need to pass
nodecount or something.
- write utility "cmd_line_parse" which takes a datastr and picks
off the "-" indicated flags and the remaining free-form string and
puts them in locations for use by the calling routine. (Are "-p1"
and "-q0" examples of the only commands with more than one character
after the '-'?)
- need more checks to stop arithmetic errors when computing centers
with poor radii
- fix up the bdry_comp pointers so we can allocate space only as needed.
- make 'molify_cent' as the standard way to lay out a packing; however,
have to adjust the method in multiply-connected cases for verts on
outside of red chain. Probably need to keep plot info in red chain
data structure so when plotting a given vert we know which neighbors
have been plotted in spots we should use.
- put flag with geom_to_h which does a straight transition of (legal)
radii and centers, without globally checking for largest, etc. to
maintain a packing.
- figure out way to organize data so one can swap out flowers; that
is, if you want to work with some subcomplex, instead of creating a
new packing, you just temporarily redefine the flowers (and .num)
data so the repacking routine just computes the data you want.
- Might consider building in a "vertex order" for layout rather
than a face order (at least in simply connected cases). With locations
being molified anyway, it's not so important which face is being
drawn; the next circle uses all possible pairs of neighbors.
- Might consider repacking computation in order of circle layout
instead of simple numerical order. Than way might get the ones
that are most crucial to layout done first.
For example: for hyp packing, might add ideal vert, puncture at
alpha, make new ideal vert V the temporary alpha, do the packing around
this new alpha, then do "cir_invert -u V" to put the original packing
(less the punctured vert) into the disc. Using drawing order for repack
makes sense because you might work only on the verts in the early
generations, get them to lay out before moving on to those deeper
in the final packing.
|