doug-moen
commented
8 years ago By "when the vector is saved", I assume you mean when the model is exported (as STL, AMF or whatever).
No, I don't think it is useful to discard part of the mantissa when exporting the model. Throwing away information like that can only make things worse, and can change a legal mesh into an illegal mesh with degenerate triangles or whatever. If a triangle contains 2 vertices whose coordinates differ only in the digits you are discarding, then discarding those digits will make the triangle degenerate.
Also, please note that this issue is not part of the OpenSCAD2 project. OpenSCAD2 is not a permanent fork of OpenSCAD, it's just a sandbox for experimenting with some ambitious syntax and language changes before they are integrated back into the main project. It would be better to discuss this on the OpenSCAD forum.
Doug-Moen has indicated he is familiar with set notation, so I will phrase this in set notation. But since I cannot be sure how far his understanding goes, I start one step back.
A set is a container for elements, a simple set may be: {1,2,3}. The curly braces indicate this is a set; inside it is a comma delimited list of its elements. The number of elements inside it can be counted; the element count is 3, a finite number. A more useful set is the set of natural numbers {1,2,3,...}. This set contains an infinite number of elements, nevertheless, its element count may be assigned a (transfinite) number, commonly denoted Aleph-nought. The set of all rational numbers (=fractions) {1, 1/2, 1/3, 2/3, ... , 2, ...} does contain the same number of elements Aleph-nought as does the set of natural numbers. The proofs I will skip here, as a pure text environment cannot handle it, and I don't want to bloat this up with graphics that most people don't care for anyway. The moment that irrational numbers (roots, sines, cosines, tangens, etc,) are added to above set, the element count increases to another transfinite number, commonly called C-nought. Further addition of imaginary numbers does not increase the element count any higher, the element count remains C-nought.
Counting the elements of a set has consequences for programming. As Kurt Gödel has shown,
So much for set theory background. The next step is to show that High School math is not applicable inside a computer environment. For this we need first to understand that numbers get rounded inside the computer, so that they fit to the finite length of the registers used. How they are fitted does not matter for the argument, when does the rounding take place? is what makes the difference. The associative law of High School math states (a+b)+c=a+(b+c). In the following examples the result is always rounded to the nearest integer. 1.4+2.2+3.05=7 Brackets denote interim results, thus (1.4+2.2)=4 and thus (1.4+2.2)+3.05=7 (2.2+3.05)=5 and thus 1.4+(2.2+3.05)=6 is proof that associativity does not hold on a computer. Switch above numbers around and you will see that the commutative law (a+b=b+a) does not hold either, as long as rounding comes into play.
Thus, Doug-Moen, you need to be careful about High School math when it is applied inside a computer. And you need to have rules to reliably convert from a set of transfinite size to the finite size set that a computer can handle.
But I want to give you not only a problem, but also a possible solution. This solution starts by agreeing that 1 unit in OpenSCAD represents 1mm in the real world. If that is accepted, then a lower limit has been accepted implicitly for the smallest meaningful resolution OpenSCAD can map to in the real world, in the form of the radius of a single atom. Take that to be 0.000 000 1mm, and you see shortly what I mean. At that resolution, a circle would look like 000000000 000111000 001000100 010000010 010000010 010000010 001000100 000111000 000000000 with the 0's denoting "not part of the circle" and the 1's "part of the circle", represented in a 9x9 matrix of dots, representing an area 0.000 000 9x0.000 000 9mm^2 in real space. Make the circle bigger for a larger real space area, and it will also become rounder.
Whatever floating point format, Double (64 bits) or Long (80 bits) you want to use, ensure that any vertex takes the form [x.x...x0000,y.y...y0000,z.z...z0000] where the x,y,z denote any meaningful digits of the vertex' position vector, and the 0000 denote digits that will be discarded when the vector is saved, digits that are there exclusively for covering up for rounding errors.
Do you think that could work?