**Message-ID:** <Pine.NEB.4.63.0511071745470.12948@panix3.panix.com>

**From:** Alan Sondheim <sondheim@panix.com>

**To:** Cyb <cybermind@listserv.aol.com>,
"WRYTING-L : Writing and Theory across Disciplines" <WRYTING-L@LISTSERV.UTORONTO.CA>

**Subject:** out on a limb that truncates into nothing

**Date:** Mon, 7 Nov 2005 17:45:56 -0500 (EST)

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... _