Non-deterministic STLs
When you have a large fully parametric design and you change something it
isn't always obvious what the knock on effects will be. But you need to
know exactly which STL files have changed so you can re-slice and reprint
them. Also when you make a change to accommodate a new variant you might
want to verify that it doesn't affect other variants.
In both of the above use cases you need to be able to compare the STL files
and know if they have changed. As discussed before OpenScad uses machine
addresses to order the vertices, so the order changes when you change
unrelated code. I got around this by writing a Python script to order the
vertices numerically. That works most of the time but I still get the odd
file changing unexpectedly.
I changed a module today that generates rounded cylinders. The change
shouldn't have actually affected anything at all because mathematically it
was the same shape. However it did make small changes to STL files that
used it. Fair enough, probably due to the numerical conversion issues
discussed yesterday. However, it also changed an STL file that does not use
it. It includes the module but does not invoke it.
The change is numerically insignificant but it makes very difficult and
time consuming to work out what has really changed. Only two vertices
changed out of a file nearly 1MB long.
[image: Inline images 1]
Is it possible that having the vertices ordered by address (which can
change from machine to machine and when anything is added to or removed
from the source code) can lead to different numerical results due them
being processed in a different order somewhere?
Oddly although GitHub's STL difference views shows the correct number of
lines changed, it highlights a lot more triangles, so I think it has non
deterministic issues as well.
nophead wrote
However, it also changed an STL file that does not use
it. It includes the module but does not invoke it.
The change is numerically insignificant but it makes very difficult and
time consuming to work out what has really changed. Only two vertices
changed out of a file nearly 1MB long.
Is it possible that having the vertices ordered by address (which can
change from machine to machine and when anything is added to or removed
from the source code) can lead to different numerical results due them
being processed in a different order somewhere?
Was the old STL done with the same OpenSCAD version?
Doesn't sound good for geometry to change where a changed module is not
invoked.
I still have a feeling there is a ghost in the machine since 2015.03...
Newly minted Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
View this message in context: http://forum.openscad.org/Non-deterministic-STLs-tp15513p15694.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
"NaN.000000000000013" http://xkcd.com/1537/ ;)
Newly minted Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
View this message in context: http://forum.openscad.org/Non-deterministic-STLs-tp15513p15695.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Was the old STL done with the same OpenSCAD version?
Yes the same 32 bit binary but running on 32 bit XP on a core due as
opposed to 64 bit Win7 on a core I5.
Doesn't sound good for geometry to change where a changed module is not
invoked.
I am not sure that is the case, I may have been mistaken or it is a very
rare occurrence.
On 15 January 2016 at 04:46, MichaelAtOz oz.at.michael@gmail.com wrote:
"NaN.000000000000013" http://xkcd.com/1537/ ;)
Newly minted Admin - PM me if you need anything, or if I've done something
stupid...
Unless specifically shown otherwise above, my contribution is in the
Public Domain; to the extent possible under law, I have waived all
copyright and related or neighbouring rights to this work. Obviously
inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it!
http://www.ourfairdeal.org/ time is running out!
View this message in context:
http://forum.openscad.org/Non-deterministic-STLs-tp15513p15695.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On Jan 15, 2016, at 03:55 AM, nop head nop.head@gmail.com wrote:
Was the old STL done with the same OpenSCAD version?
Yes the same 32 bit binary but running on 32 bit XP on a core due as opposed to 64 bit Win7 on a core I5.
That would be on a different CPU, different OS and different C library implementation, all of which can influence floating point arithmetics as well as rounding.
If you really want 100% parity across CPUs, OSes and C libraries, I would start by investigating two things:
- Rounding, see e.g. http://martinwguy.co.uk/crunch/test/tybor/tbin2dec.c
- Floating point format used (e.g. 80 bit float extensions which has been discussed earlier)
Note that this will probably extend to the external libraries we use as well (CGAL, Eigen, libtess2, Clipper).
-Marius
tbin2dec.c prints the same on both computers when compiled for 32 bits with
GCC 4.9.2. It also prints the same when compiled for 64 bits on the 64 bit
OS.
Rounding is add 0.5 and truncate.
MIN_WIDTH=509.
Test ( Pass ) {}
On 15 January 2016 at 14:30, Marius Kintel marius@kintel.net wrote:
On Jan 15, 2016, at 03:55 AM, nop head nop.head@gmail.com wrote:
Was the old STL done with the same OpenSCAD version?
Yes the same 32 bit binary but running on 32 bit XP on a core due as
opposed to 64 bit Win7 on a core I5.
That would be on a different CPU, different OS and different C library
implementation, all of which can influence floating point arithmetics as
well as rounding.
If you really want 100% parity across CPUs, OSes and C libraries, I would
start by investigating two things:
- Rounding, see e.g. http://martinwguy.co.uk/crunch/test/tybor/tbin2dec.c
- Floating point format used (e.g. 80 bit float extensions which has been
discussed earlier)
Note that this will probably extend to the external libraries we use as
well (CGAL, Eigen, libtess2, Clipper).
-Marius
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org