I was playing around with old/example24.
With n=6 I get a crash with  Exception Code: c00000fd, usually stack
overflow.
That is a contrived problem.
However with let() & a bunch of other new developments there are more people
doing list processing & recursion. So this may be more of a problem in the
future.

Double it?

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/Should-we-increase-the-stack-size-tp21147.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

To quote Wikipedia (https://en.wikipedia.org/wiki/Menger_sponge):
"The Menger sponge is a closed set; since it is also bounded, the
Heine–Borel theorem implies that it is compact. It has Lebesgue measure 0.
It is an uncountable set." And because the set is uncountable, there will
always be a level that blows the stack. (Uncountable means that there are
more elements in the set than there are integers. Thus, with a finite memory
size available trying to represent the set accurately is folly - remember my
comments on "Lattice Structure".
Besides, my experience has always been that the upper practical limit for
OpenSCAD lies around 100 000 items to be unioned, attempting to do one
million is where the folly starts. Why? Thermal expansion values range
around 1e-5, and unless you control temperature uniformity inside your
printer to be within 1 degree Celsius, thermal expansion issues alone will
make that kind of accuracy impossible - let alone backlash in your
mechanical system. A Menger Sponge of level 4 has 160 000 individual cubes
that need to be unioned, level 6 involves 20^6=64million cubes - way too
much.
My suggestion is to close both issue 451 and issue 1446, the reason being
that they set targets for software that are unrealizable in hardware,
because the software demands more storage place and computing time than is
available in the universe we live in. But if MichaelAtOz is supplying me
with a return ticket to the alternative universe he suggested in "Lattice
Structure", I can go there and return with an OpenSCAD that has no bugs,
does all work in zero memory and zero time. . .
Speaking of time: issue 451 and issue 1446, when run with level 4, produce
the same geometry:
http://forum.openscad.org/file/n21184/Issue1446.jpg
but require substantially different time:
Issue451-4
// Fractal depth (number of iterations)
n=4;
Compiling design (CSG Tree generation)...
ECHO: version = [0, 0, 0]
Rendering Polygon Mesh using CGAL...
Geometries in cache: 1811
Geometry cache size in bytes: 1316952
CGAL Polyhedrons in cache: 48
CGAL cache size in bytes: 103213696
Total rendering time: 0 hours, 34 minutes, 39 seconds
Top level object is a 3D object:
Simple:        yes
Vertices:  109484
Halfedges:  330006
Edges:      165003
Halffacets:  77358
Facets:      38679
Volumes:        2
Rendering finished.

Issue 1446:
level 4
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL...
Geometries in cache: 1770
Geometry cache size in bytes: 1287104
CGAL Polyhedrons in cache: 2
CGAL cache size in bytes: 96977888
Total rendering time: 3 hours, 21 minutes, 5 seconds
Top level object is a 3D object:
Simple:        yes
Vertices:  144104
Halfedges:  634416
Edges:      317208
Halffacets: 278844
Facets:    139422
Volumes:        2
Rendering finished.

The - for me - most interesting part is that the Menger Sponge provides me
with a test bed for testing the capabilities of a boolean operations library

• what is the speed increase relative to the above observations?
  MichaelAtOz has suggested that the parallel processing approach currently
  readied for implementation roughly halves rendering time. Above examples
  suggest that with different programming a sixfold increase in speed is
  possible, and my own experiments in that direction indicate that 1000-10000
  times faster rendering is possible even without parallel processing - but
  also that it would require rather radical changes to OpenSCAD.
  Thank you for that test bed.

wolf

--
View this message in context: http://forum.openscad.org/Should-we-increase-the-stack-size-tp21147p21184.html
Sent from the OpenSCAD mailing list archive at Nabble.com.