The variable does not retain the changed value.
How to assign a value to a variable?
dprovv1 = 0.0;
dprovv2 = 0.0;
for (i = [0 : 1 : 10]) {
if (dprovv2 == 0) {
echo (dprovv1);
dprovv1 = (dprovv1 + 1);
}
}
The dprovv1 variable seems not to keep the changed value.
Thank you.
I do not speak English. I apologize for my english.
--
View this message in context: http://forum.openscad.org/The-variable-does-not-retain-the-changed-value-tp18219.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
There are no variables in OpenScad, only named constants that have only one
value for the whole of their scope.
In your example you would need to do something like dprovv3 = dprovv1 + i;
In general something that changes during a loop will need to be a function
of the loop variable.
On 27 August 2016 at 10:45, bvox123 bvox@domusvox.net wrote:
How to assign a value to a variable?
dprovv1 = 0.0;
dprovv2 = 0.0;
for (i = [0 : 1 : 10]) {
if (dprovv2 == 0) {
echo (dprovv1);
dprovv1 = (dprovv1 + 1);
}
}
The dprovv1 variable seems not to keep the changed value.
Thank you.
I do not speak English. I apologize for my english.
--
View this message in context: http://forum.openscad.org/The-
variable-does-not-retain-the-changed-value-tp18219.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
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/General#Variables
I think we should ditch the term 'variable'...
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/The-variable-does-not-retain-the-changed-value-tp18219p18220.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
I totally agree. This question comes up far too often
On 8/27/2016 7:36 AM, MichaelAtOz wrote:
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/General#Variables
I think we should ditch the term 'variable'...
This is a long overdue decision.
But - Who is willing and capable to do so? I remember doug.moen doing this
kind of thing to the manual, and he made a big mess of it until he finally
learned how things fit together . . .
OpenSCAD sticks out of the CAD programs that I have tried because it is so
easy to learn - until you get creative. Then rendering gets slow - very
slow, indeed, and rendering times go up to become hours, not fractions of a
second. I have learned by now how to speed up rendering about 50 000 times,
i.e. to cut down 2 hour rendering to about 0.1 seconds.
But to do that, you need to take into account hardware limitations, and not
hide behind some lofty software design theory.
In practical terms, I can speed up rendering about 100 times by moving from
OpenSCAD to Free Pascal, by ditching any attempts at functional programming.
If you want that kind of speed improvement for OpenSCAD, I am willing to
show you how, and why ditching functional programming is a key to
substantial speed improvements.
Another key to speeding up OpenSCAD is reducing the amount of data that is
cached - caching large amounts of data slows down program execution, unlike
caching small amounts, which speed up execution.
wolf
--
View this message in context: http://forum.openscad.org/The-variable-does-not-retain-the-changed-value-tp18219p18256.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On 08/30/2016 01:14 AM, wolf wrote:
This is a long overdue decision.
But - Who is willing and capable to do so? I remember doug.moen doing this
kind of thing to the manual, and he made a big mess of it until he finally
learned how things fit together . . .
Talk is cheap, and in this case also feels like it's intended to be
insulting. Why do you think that's needed?
Doug may have made a mistake, we all do from time to time when we
are actually changing things. The only interesting part is to also
care enough to fix it. Only changes will bring things forward.
He helped OpenSCAD a lot in various places, so to counter the mood
of the quoted part, I just want to say thanks Doug.
But to do that, you need to take into account hardware limitations, and not
hide behind some lofty software design theory.
Nothing surprising here. That's also true for $10000 commercial
software that can do lots of stuff better but still has to align
with real life and constraints of the existing hardware.
Another key to speeding up OpenSCAD is reducing the amount of data that is
cached - caching large amounts of data slows down program execution, unlike
caching small amounts, which speed up execution.
If you have some numbers and specific suggestions for improvements,
please share. I guess everybody will welcome any speed-up in
render performance.
ciao,
Torsten.
I'm curious about this:
"In practical terms, I can speed up rendering about 100 times by moving from
OpenSCAD to Free Pascal, by ditching any attempts at functional programming."
Can you show me an example of how to do this? What libraries would be used?
Etc?
Jon
On 8/29/2016 7:14 PM, wolf wrote:
This is a long overdue decision.
But - Who is willing and capable to do so? I remember doug.moen doing this
kind of thing to the manual, and he made a big mess of it until he finally
learned how things fit together . . .
OpenSCAD sticks out of the CAD programs that I have tried because it is so
easy to learn - until you get creative. Then rendering gets slow - very
slow, indeed, and rendering times go up to become hours, not fractions of a
second. I have learned by now how to speed up rendering about 50 000 times,
i.e. to cut down 2 hour rendering to about 0.1 seconds.
But to do that, you need to take into account hardware limitations, and not
hide behind some lofty software design theory.
In practical terms, I can speed up rendering about 100 times by moving from
OpenSCAD to Free Pascal, by ditching any attempts at functional programming.
If you want that kind of speed improvement for OpenSCAD, I am willing to
show you how, and why ditching functional programming is a key to
substantial speed improvements.
Another key to speeding up OpenSCAD is reducing the amount of data that is
cached - caching large amounts of data slows down program execution, unlike
caching small amounts, which speed up execution.
wolf
In practical terms, I can speed up rendering about 100 times by moving from
OpenSCAD to Free Pascal, by ditching any attempts at functional programming.
That I doubt for the same precision. If you profile OpenScad the
functional language parsing part of it is lost in the noise. It's all the
computation done on the geometries that are the problem.
If you want that kind of speed improvement for OpenSCAD, I am willing to
show you how, and why ditching functional programming is a key to
substantial speed improvements.
No. Read the profile data for the execution.
Another key to speeding up OpenSCAD is reducing the amount of data that is
cached - caching large amounts of data slows down program execution, unlike
caching small amounts, which speed up execution.
Also wrong. The performance of a cache is a function of the available
space, the cost of data regeneration and search. In the OpenSCAD case
the only number that is even relevant is the cost of regenerating the
data because it dominates the rest.
We know how to speed up OpenSCAD. It's just hard work.
- Move away from CGAL or write CGAL classes for stable fixed point 64bit
maths - Add parallelism where it's currently heavily single threaded
- Switch to a different set of algorithms with different scaling
properties
All of those are very involved. For complex designs you may want to look
at ImplicitCAD (https://github.com/colah/ImplicitCAD). It's a relative
language wise of OpenSCAD but uses Haskell as a programming language and
has parallelism and uses an algorithmic approach which for complex
objects tends to scale better. It's underlying models can also do things
that OpenSCAD struggles with such as nice bevels and fillets.
ImplicitCAD however is also rather lacking in the nice UI features that
OpenSCAD has so if you want to knock together an object, spin it around
in the UI and work on it the experience simply doesn't compare.
Alan
You asked for it, here it is.
The attached file HelixSource.tar.gz contains the source code to create a
helix composed of 200000 vertices and dump it on your hard disk as a 112 MiB
.stl file. To compile it, Lazarus 1.6 is required. According to the Lazarus
website, "write it once, compile anywhere" i.e. no special requirements
regarding your operating system. Whether that is true I have not tested.
Execution time on my system ( Intel Core i5-3470@3.4GHz, 4 CPU cores without
hyperthreading, Level 1 cache size :4 x 32 kB, Level 2 cache: 4x256kB, Level
3 cache:6 MB shared cache, Physical memory: 32 GB, Operating system: 64 bit
Kubuntu) is about 0.2 seconds, of which about half is used to render the
200000 vertices into 32 bit .stl format. Each vertex is calculated using 80
bit floating point numbers, with a 64 bit mantissa. I have tried to use
64bit fixed precision format until I realized that rounding errors cannot be
avoided this way, since part of the work is calculating the length (norm) of
vectors, which would require 128 bits if the result were not to be rounded.
The .stl data are 32 bit floats, in line with the .stl spec.
Execution times are quite variable, in line with what to expect if caching
is the main contributor determining execution speed.
Compare the 0.1 second true rendering time under Free Pascal / Lazarus with
the 11 seconds rendering consumed when following the same programming
strategy in OpenSCAD (shared in re: improve rendering speed, 9 June 2016,
this forum, or the nearly 2 hours OpenSCAD requires for rendering if the
helix is constructed from spheres, or the one hour if constructed, following
parkinbot, from thin slices joined by hull(), or the 20 minutes it takes to
render parkinbot's helix implementing a suggestion by Ronaldo how to produce
slices of zero thickness.
Compare these speed increases also with Alan Cox' claim that parallel
execution does lead to major speed increases. My system has just 4 cores,
and if each core is fully utilized, I may expect a speed increase of
somewhere between 2 and 3 times, not more. SSE instructions, allowing 128bit
data, are useful for vectorizing 32 or 64 bit floats, with another 4 resp. 2
times speed increase. I use 80 bits, and cannot use them at all.
I presume I have demonstrated that I know what I am talking about?
By the way, if you decide to go to the trouble and compile my program, load
the resultant .stl file into both OpenSCAD and MeshLab and try to rotate it.
Which program is still usable with files of this size?
This concludes part one of what I have to say, about speed increases that
can be expected if functional programming is officially ditched. Part 2 will
show that functional programming has, in version 2015.03-1, already been
ditched - inofficially. It is just that the key people have not realized it.
wolf
--
View this message in context: http://forum.openscad.org/The-variable-does-not-retain-the-changed-value-tp18219p18276.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
wolf wrote
I presume I have demonstrated that I know what I am talking about?
I'd rather doubt that. You have written and tweaked a single benign thing
and use it to shoot against a paradigm blindly. Show us, how you e.g.
intersect two or more of your helixes and allow for any boolean operation in
just 0.1s. Or show us, how you implement something like this:
http://forum.openscad.org/file/n18277/helix.png
--
View this message in context: http://forum.openscad.org/The-variable-does-not-retain-the-changed-value-tp18219p18277.html
Sent from the OpenSCAD mailing list archive at Nabble.com.