nophead wrote

I have understood you are comparing here my proposal of sum_list without
recursion with your recursive sum_points.
First of all, your sum_points is not tail recursive and always returns
[0,0]. A tail recursive version of it might be:

I could not compare the running time of both alternatives (tail recursion X
non recursion) because my sum_list is limited to lists of less than 1000000
points due to the for inside. Thats is an advantage of a tail-recursive
solution indeed.

I did compared the running time of my rel_to_abs2 with your rel_to_abs. They
both required approximately the same running time. However, what bugged me
was that the running time seems to be a lot more than O(n). May be O(n^2).

Anyway, ll those alternatives are toys compared with the Torsten's code! It
runs a lot faster and I could not find a limit of it.

--
View this message in context: http://forum.openscad.org/Polygon-using-relative-points-rather-than-absolute-tp17414p17427.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

droftarts wrote

Ian, to understand the codes people have posted in the thread I would
suggest that you study the following topics and their examples:
a)  OpenSCAD User Manual/For C/Java/Python Programmers
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/For_C/Java/Python_Programmers
b)  user defined functions
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/User-Defined_Functions_and_Modules
,
c)  list comprehension
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/List_Comprehensions

List comprehension is very powerful specially combined with recursive
functions and there are some basic techniques of its use that should be
learned. Study people code from other threads as well.

To understand Torsten's code you will need to understand the  experimental
features https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/WIP  of the
latest snapshot version http://www.openscad.org/downloads.html  .

Finally, to understand tail recursion technique in OpenSCAD read the thread
on  Tail recursion http://forum.openscad.org/Tail-recursion-td17040.html
.

--
View this message in context: http://forum.openscad.org/Polygon-using-relative-points-rather-than-absolute-tp17414p17429.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Nah, if lisp can have a loop macro, we should also have
something controversial to discuss about :-).

Yeah, it's possible to abuse it and make horrible code, but
that's probably true for most constructs in pretty much all
languages.
Right now the feature is still marked as experimental so it
would not go automatically into the next release, so there's
still a chance to discuss it. But it seems to help expressing
some things easily that require much more effort from people
who are not so much into functional programming.

You also said: "Yeah, summing up things with OpenSCAD is
not real fun."

Which language construct could make it fun again? With
the current list of language changes, it might be easy
to just add another change if it makes things easier.

ciao,
Torsten.

There’s an old saying: “It is possible to write FORTRAN programs in any language”.

—
Kenneth Sloan
KennethRSloan@gmail.com mailto:KennethRSloan@gmail.com
Vision is the art of seeing what is invisible to others.

On 25 May 2016 at 13:48, Ronaldo rcmpersiano@gmail.com wrote:

No I was comparing my second version of rel_2_abs with the first version
with your non-recursive sum_list.

That is probably because adding to the end of a list is proportional to the
length of the list when it involves a new memory allocation and then a
copy. I expect that becomes dominant when the list gets big.

Perhaps list comprehensions have some way of growing the list without
copying it as the list being built is expected to grow.

tp3 wrote

Ok, but this languages offer proper constructs, which are neglected for
horribleness, OpenSCAD doesn't.

tp3 wrote

Good point. Seriously spoken, I'd be happy to have this imperative backdoor
as a feature to do exactly what you do, but NOT within the head of the
forloop. Say as a feature of let:

function pandora(n) =
let(a = 1)
[for (i=[1:n])
let(a = a+i) [i, a]];
</code>

Currently this code answers with functional semantics:
[[1, 2], [2, 3], [3, 4], [4, 5], [5, 6], [6, 7], [7, 8], [8, 9], [9, 10],
[10, 11]]
so it uses outer scope 'a' as R-value set an inner scope L-value 'a'.

with imperative semantics you'd obviously get (and that's the aim of the
game):
[[1, 2], [2, 4], [3, 7], [4, 11], [5, 16], [6, 22], [7, 29], [8, 37], [9,
46], [10, 56]]

To discriminate between definition (with implicit declaration) and (now
forbidden) update of a local outer (or even inner) scope variable, pandora
could introduce a 'set' keyword for the new semantics. And the expression
with imperative semantics would be:

--
View this message in context: http://forum.openscad.org/Polygon-using-relative-points-rather-than-absolute-tp17414p17436.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Hi Parkinbot. I have accepted your challenge, and designed a way to add
mutable variables to OpenSCAD without violating the declarative semantics.

The benefit is: it's easier to port traditional algorithms to OpenSCAD,
because now you can use standard imperative idioms. For example, you can
implement an efficient quicksort with in-place array update.

The drawback is: more language complexity. OpenSCAD is now a hybrid of a
declarative language with an imperative language.

I honestly don't know if we actually want to make this change. Do we want
to turn OpenSCAD into a general purpose programming language? However, it's
worth having the discussion, since the topic is often raised in the forum,
so I wrote a design paper to show people what this would look like.

https://github.com/openscad/openscad/wiki/Mutable-Variables

Doug Moen.

On 25 May 2016 at 16:22, Parkinbot rudolf@parkinbot.com wrote: