Landon Curt Noll
0bc6c3e413
We quasi-canonicalized markdown links to FAQ entries. **IMPORTANT NOTE**: This is a useful step in completing issue #2417. This commit is consistent with the top level TODO comment requirements. Nevertheless, this changes made by this commit needs to be examined and in some cases improved. A link to an FAQ entry is of the form: ``` FAQ on "[the link text](....faq.html#string)" FAQ on "[the link text](....faq.html#string)" ``` The "FAQ" is at the start of the line, or in rare cases is preceded only by whitespace. The reference to the FAQ starts outside of the markdown link with the string **FAQ ON "**. After the markdown link is a **"** followed by either the end of line or a single punctuation character such as a period or comma. We reduced the size of "the link text" that refer to an FAQ to at most 3 words. In some cases the sentence and/or text surrounding the markdown link to a FAQ may need to be further adjusted to better accommodate this new style. **IMPORTANT NOTE**: References to a FAQ entry are on a separate line. p.s. When linking to the `faq.html` file itself, we use markdown of the form "`the [IOCCC FAQ](..../faq.html)`" and place the word "the" outside of the "IOCCC FAQ" link text. Given the above system (and because references to an FAQ entry is on a separate line), the following command shows links to FAQ entries, sorted by FAQ entry "link #name" so that one may evaluate the way a given FAQ entry is referenced: ```sh find * -name '*.md' -print0 | xargs0 grep -E '^[[:space:]]*FAQ on "' | sed -e 's/^\([^:]*\):\( *FAQ on "[^#]*\)#\([^)]*\)\()".*\)$/#\3\t\1\t\2#\3\4/' | sort ``` The above command shows the value of consistency when it comes to FAQ references. **NOTE**: There are a few differences on how a given FAQ is references. That is probably OK as there is NOT an "total mandate" that all references to a given FAQ must have the same "link text" for example. On the other hand if references to a given FAQ can be identical, that might be helpful. We are certain that in some contexts the "link text" might need to change. Should we decide to change the way FAQ are referenced, we will be able to modify identify and modify them with greater ease.' Examine the changes made by this commit and adjust and/or improve as needed. Performed `make www` to accomplish the above and to test under macOS.
To build:
make
To use:
You will need an SVG viewer or
a converter like ImageMagick's convert.
See
FAQ on "ImageMagick".
Look here to find some SVG Viewer Implementations.
./boutines < input > output.svg
Try:
./try.sh
If ruby is installed try.sh will generate an SVG file by:
ruby -e '20.times{puts "#{rand} #{rand}"}' | ./boutines > test.svg
It will also create an SVG file with the file input.txt.
The script will check if convert is available and if so it will try converting
the SVG file(s) to PNG file(s) which you should be able to view in most any
graphics viewer, editor or web browser.
If you have a program that opens
SVG files then you could open
the test.svg and result.svg files directly. An example program is
Inkscape. See the
list cited above for
others.
Judges' remarks:
Can you explain the author's remark "[generated files] are not as scalable as their name suggests"?
Author's remarks:
In memory of my father Pierre Boutines-Vignard.
Walk-through
My program works as follows:
Input
A list of 2D points in the unit square.
Output
A Voronoi diagram of the set as an SVG stream.
This will possibly save a compressed SVG file and may be useful:
./boutines | gzip > result.svg.gz
Input consists of a list of floating points values separated by whitespaces
(ranging preferably in [0,1]). Alternating a horizontal coordinate, a
whitespace then the other coordinate (pointing downwards in the resulting
graph) and a newline will just go fine:
0 0
0 1
1 0
1 1
.5 .5
Strictly speaking, you have to provide a set of points. If there are duplicates in the list, there is no guarantee on the one to be shown (in addition their labels will overlap) in the resulting colored Voronoi diagram.
Caution
This program might have been a lot shorter, but nearly impractical even for medium sized datasets. On the other hand it could have been a lot faster, but hard to qualify under the IOCCC size limit. So guess what I did? A compromise favoring innermost obfuscation, sacrificing sometimes speed and other tedious factors.
Therefore this entry is limited to
points and won't even be suitable for more than a few thousand; although generated files did pass the W3C SVG Validator, and are highly compressible, they are not as scalable as their name suggests... For serious applications about Voronoi diagrams, see Qhull, CGAL and the like but you may still encounter large output volumes (and have to handle some sort of clipping in order to represent properly infinite regions of the diagram in SVG.
Beware, compilation may report warnings about precision loss, linting may be a
disaster, but the code should remain portable, and the output accurate enough
for most devices (including many inkjet printers). If you ever miss precision
on a particular dataset or peripheral, you may want to dive in and let U be
the next power of __LINE__.
NOTE: bad inputs will be sanctioned by the production of the 42nd Mersenne prime (i.e. 2^25964951 -1); memory will be kept.
Why I think this code is Obfuscated ?
I'm quite divided on the subject because I wrote:
- Clear SVG keywords but complicated output statements.
- No nested loops but loads of function calls.
- Easy recursion but no clear data structure.
- Easy maths but no use of
math.h. - A single
if.
Be sure to check the antepenultimate line of code.
Missing Features
Color control
Cell colors are chosen randomly (with a questionable rejection scheme). It might have been useful to input them along with sites coordinates, turning the application into a puzzling graphics engine.
Site labelling
The points are implicitly numbered in the order they were entered (starting at one). This can be overridden however, via a simple XSL transformation.
Site radius
The site radius is hardcoded in the code, I still wonder why I did not design it as a function of the underlying cell's area (which can be averaged for free) or at least a command line parameter. Same with the char set, the viewport and potentially every SVG property.
See Also
Example Output
