out on a limb that truncates into nothing

[Alan Sondheim]

out on a limb that truncates into nothing


See below: commentary on digital collapse.

"Constructed Points and Dimensional Collapse

Geometries computed by spatial analysis methods may contain constructed
points which are not present in the input Geometries. These new points
arise from intersections between line segments in the edges of the input
Geometries. In the general case it is not possible to represent
constructed points exactly. This is due to the fact that the coordinates
of an intersection point may contain twice as many bits of precision as
the coordinates of the input line segments. In order to represent these
constructed points explicitly, JTS must truncate them to fit the Precision
Model.

Unfortunately, truncating coordinates moves them slightly. Line segments
which would not be coincident in the exact result may become coincident in
the truncated representation. For Line-Area combinations, this can lead to
dimensional collapses , which are situations where a computed element has
a lower dimension than it would in the exact result.

JTS handles dimensional collapses as gracefully as possible, by forming
the lower-dimension."

http://www.jump-project.org/project.php?PID=JTS&SID=OVER

"
00331 /*
00332  * Reduces the precision of a {@link Geometry}
00333  * according to the supplied {@link PrecisionModel}, without
00334  * attempting to preserve valid topology.
00335  * <p>
00336  * The topology of the resulting geometry may be invalid if
00337  * topological collapse occurs due to coordinates being shifted.
00338  * It is up to the client to check this and handle it if necessary.
00339  * Collapses may not matter for some uses.  An example
00340  * is simplifying the input to the buffer algorithm.
00341  * The buffer algorithm does not depend on the validity of the input
geometry.
00342  *
00343  */
00344 class SimpleGeometryPrecisionReducer {
00345 private:
00346         PrecisionModel *newPrecisionModel;
00347         bool removeCollapsed;
00348         //bool changePrecisionModel;
00349 public:
00350         SimpleGeometryPrecisionReducer(PrecisionModel *pm);
00358         void setRemoveCollapsedComponents(bool nRemoveCollapsed);
00359
00360         /*
00361         * Sets whether the {@link PrecisionModel} of the new reduced
Geometry
00362         * will be changed to be the {@link PrecisionModel} supplied
   to
00363         * specify the reduction.  The default is to not change the
   precision model
00364         *
00365         * @param changePrecisionModel if <code>true</code> the
   precision model of the created Geometry will be the
00366         * the precisionModel supplied in the constructor.
00367         */
00368         //void setChangePrecisionModel(bool nChangePrecisionModel);
00369
00370         PrecisionModel* getPrecisionModel();
00371
00372         bool getRemoveCollapsed();
00373         Geometry* reduce(const Geometry *geom);
00374 };
"

http://geos.refractions.net/ro/doxygen_docs/html/precision_8h-source.html

Dimensional collapse might be an example of the imprecision of phenomena
in relation to any given grid. Here one might have analog -> digital (i.e.
mapping) -> dimensional collapse.

In relation to analog/digital phenomenology: look at collapse; at border-
line phenomena; at rastered 'infinities'; at the phenomenology of observa-
tion itself; infinitesimals; particle decay; at Thom's catastrophe theory;
at cellular re: Wolfram; and so forth.

Somewhere in all of this there are hints of sudden collapse that predate
the universe.

Perhaps a hint that the analog is an extrusion, just as Aristotelian
distributivity is an intrusion in relation to gestural (non-Booelan)
logics.

Perhaps the primordial surrounds us; our prsent; the universe begins in
the synchronic, pre/chaotic extension; having always already begun; having
always already ended.

Issues: My own ignorance in relation to the _practical limits of calcula-
tion._ One can easily, for example, multiply a 1000-digit number by 2;
it's only a question of limited rules (i.e. 2 x 8 = 6 + carry). Machines
can handle 2 1000-digit numbers multiplied, etc. Pi can be calculated,
presumably indefinitely. On the other hand, take sin(tan(x)) as x
approaches 90 degrees; sooner or later the calculation breaks down, and
'jumps' are observed. Re: fractal programs - continuous enlargment stops
as a result of what? Calculation limits? Graphics/raster limits? Is the
stoppage _inherent_ in the technology, regardless of interface, or is it a
byproduct of interface as much as anything else?

My stupidity of course gets the better of this...


_