FH
Father Horton
Wed, Nov 1, 2023 7:22 PM
I thought OpenSCAD did tail recursion.
On Wed, Nov 1, 2023 at 2:13 PM Adrian Mariano avm4@cornell.edu wrote:
In this case I would argue that the nonrecursive code is easier to read.
A situation may occur where you are sure that you never need to run on a
vector with more than 5k entries, so the recursive solution suffices if it
is fast enough. You do understand that due to limits on recursion depth,
recursive solutions simply fail on long inputs? I think that pretty,
readable code that does not work is inferior to any code that does work.
Regarding performance the 20x speed gain I got with nonrecursive bezier
surface calculation matters, at least on machines that I use. Many things
that I do in openscad with few or just one object are slower than I wish,
like 90 seconds to preview a model containing ten objects. Maybe
optimization can be seen as a necessary evil, but we do not have an
optimizing compiler here, and I don't think efficiency can be dismissed,
particularly when writing core functions that could be called thousands of
times to make a single object.
On Wed, Nov 1, 2023, 13:46 Rogier Wolff R.E.Wolff@bitwizard.nl wrote:
On Wed, Nov 01, 2023 at 11:49:40AM -0400, Adrian Mariano wrote:
My solution is not merely more succinct. Because it is not
recursive it will be much faster and also able to work on arrays
with more than 5000 entries. A nonrecursive solution is always
better if it exists for these reasons. It would be better even if
the code were longer.
No. The better solution would be the "more readable code". I have been
a proponent of "readable code" for 35 years. (all my adult life. I did
some optimized unreadable stuff in highschool and learned my
lesson....).
We did "real time video processing" in 1995. They guys down the
hallway here are now doing that stuff on a 275TOPS machine. We had
about 30-60M operations per second back then (first dual issue CPU!,
but hard to get the second instruction stream filled.).
Nowadays writing "somewhat inefficient" code is acceptable. As long as
the algorithm is reasonable and not O(n^3) when it should be O(n),
that sort of stuff.
Openscad is VERY inefficient in stuff that should not be all that
inefficent. For example, intersection is O(n^2), right? No it isn't!
it should be O(n log n). Divide the universe in 2 halves (X+ ,
X-). Divide each of those in half (Y+, Y-). After that, each 1/8th
gets split in half again and again, until O(n^2) objects within that
region is actually O(1).
Now it isn't all Openscad's fault. It uses a couple of libraries that
were written expecting to run with tens or maybe hundreds of objects,
but openscad makes it easy to push that into the thousands (still
works fine with 10 years of Moore's law) and millions. And that's when
the trouble starts and you should've used a better algorithm in the
first place.
Roger.
Yes. now It seems to be better at writing code that works, but you
to prod it in the right direction. it sometimes gives more weight to
problem, rather than the language, and gives a 'pythonesk' response.
I asked it what it thought of your solution (which is more succinct)
function remove_zeros(vec) = [for(val=vec) if (val>0) val];
it gave a good explanation, then added -
vec = remove_zeros(vec);
This line of code would update vec to be a new vector with all
values removed.
I hope this helps! Let me know if you have any other questions
OpenSCAD or anything else. 😊
win some, lose some...
On 01/11/2023 11:23, Adrian Mariano wrote:
ChatGPT wrote filter_gt_zero?
The way it should be done is:
function remove_zeros(vec) = [for(val=vec) if (val!=0) val];
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
I thought OpenSCAD did tail recursion.
On Wed, Nov 1, 2023 at 2:13 PM Adrian Mariano <avm4@cornell.edu> wrote:
> In this case I would argue that the nonrecursive code is easier to read.
> A situation may occur where you are sure that you never need to run on a
> vector with more than 5k entries, so the recursive solution suffices if it
> is fast enough. You do understand that due to limits on recursion depth,
> recursive solutions simply fail on long inputs? I think that pretty,
> readable code that does not work is inferior to any code that does work.
>
> Regarding performance the 20x speed gain I got with nonrecursive bezier
> surface calculation matters, at least on machines that I use. Many things
> that I do in openscad with few or just one object are slower than I wish,
> like 90 seconds to preview a model containing ten objects. Maybe
> optimization can be seen as a necessary evil, but we do not have an
> optimizing compiler here, and I don't think efficiency can be dismissed,
> particularly when writing core functions that could be called thousands of
> times to make a single object.
>
> On Wed, Nov 1, 2023, 13:46 Rogier Wolff <R.E.Wolff@bitwizard.nl> wrote:
>
>> On Wed, Nov 01, 2023 at 11:49:40AM -0400, Adrian Mariano wrote:
>>
>> > My solution is not merely more succinct. Because it is not
>> > recursive it will be much faster and also able to work on arrays
>> > with more than 5000 entries. A nonrecursive solution is always
>> > better if it exists for these reasons. It would be better even if
>> > the code were longer.
>>
>> No. The better solution would be the "more readable code". I have been
>> a proponent of "readable code" for 35 years. (all my adult life. I did
>> some optimized unreadable stuff in highschool and learned my
>> lesson....).
>>
>> We did "real time video processing" in 1995. They guys down the
>> hallway here are now doing that stuff on a 275TOPS machine. We had
>> about 30-60M operations per second back then (first dual issue CPU!,
>> but hard to get the second instruction stream filled.).
>>
>> Nowadays writing "somewhat inefficient" code is acceptable. As long as
>> the algorithm is reasonable and not O(n^3) when it should be O(n),
>> that sort of stuff.
>>
>> Openscad is VERY inefficient in stuff that should not be all that
>> inefficent. For example, intersection is O(n^2), right? No it isn't!
>> it should be O(n log n). Divide the universe in 2 halves (X+ ,
>> X-). Divide each of those in half (Y+, Y-). After that, each 1/8th
>> gets split in half again and again, until O(n^2) objects within that
>> region is actually O(1).
>>
>> Now it isn't all Openscad's fault. It uses a couple of libraries that
>> were written expecting to run with tens or maybe hundreds of objects,
>> but openscad makes it easy to push that into the thousands (still
>> works fine with 10 years of Moore's law) and millions. And that's when
>> the trouble starts and you should've used a better algorithm in the
>> first place.
>>
>> Roger.
>>
>> > On Wed, Nov 1, 2023, 07:56 Raymond West <raywest@raywest.com> wrote:
>> >
>> > > Yes. now It seems to be better at writing code that works, but you
>> have
>> > > to prod it in the right direction. it sometimes gives more weight to
>> the
>> > > problem, rather than the language, and gives a 'pythonesk' response.
>> > >
>> > > I asked it what it thought of your solution (which is more succinct)
>> > >
>> > > function remove_zeros(vec) = [for(val=vec) if (val>0) val];
>> > >
>> > > it gave a good explanation, then added -
>> > >
>> > > vec = remove_zeros(vec);
>> > >
>> > >
>> > > This line of code would update vec to be a new vector with all
>> zero
>> > > values removed.
>> > >
>> > > I hope this helps! Let me know if you have any other questions
>> about
>> > > OpenSCAD or anything else. 😊
>> > >
>> > >
>> > > win some, lose some...
>> > > On 01/11/2023 11:23, Adrian Mariano wrote:
>> > >
>> > > ChatGPT wrote filter_gt_zero?
>> > >
>> > >
>> > > The way it should be done is:
>> > >
>> > > function remove_zeros(vec) = [for(val=vec) if (val!=0) val];
>> > >
>> > > _______________________________________________
>> > > OpenSCAD mailing list
>> > > To unsubscribe send an email to discuss-leave@lists.openscad.org
>> > >
>>
>> > _______________________________________________
>> > OpenSCAD mailing list
>> > To unsubscribe send an email to discuss-leave@lists.openscad.org
>>
>>
>> --
>> ** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110
>> **
>> ** Delftechpark 11 2628 XJ Delft, The Netherlands
>> <https://www.google.com/maps/search/Delftechpark+11+2628+XJ%C2%A0+Delft,+The+Netherlands?entry=gmail&source=g>.
>> KVK: 27239233 **
>> f equals m times a. When your f is steady, and your m is going down
>> your a is going up. -- Chris Hadfield about flying up the space shuttle.
>> _______________________________________________
>> OpenSCAD mailing list
>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
AM
Adrian Mariano
Wed, Nov 1, 2023 7:40 PM
If your code has the right structure it will do tail recursion. Right
structure used to be very limited (and often hostile to readability). I
think it has improved, but I don't know what the rules are. If I want to
know if I have tail recursion i feed a long vector to the code to see if it
bombs. Also not all recursion can be tail recursion. The bezier
computation is such a case. And tail recursion is still slower than list
comprehension.
On Wed, Nov 1, 2023, 15:23 Father Horton fatherhorton@gmail.com wrote:
I thought OpenSCAD did tail recursion.
On Wed, Nov 1, 2023 at 2:13 PM Adrian Mariano avm4@cornell.edu wrote:
In this case I would argue that the nonrecursive code is easier to read.
A situation may occur where you are sure that you never need to run on a
vector with more than 5k entries, so the recursive solution suffices if it
is fast enough. You do understand that due to limits on recursion depth,
recursive solutions simply fail on long inputs? I think that pretty,
readable code that does not work is inferior to any code that does work.
Regarding performance the 20x speed gain I got with nonrecursive bezier
surface calculation matters, at least on machines that I use. Many things
that I do in openscad with few or just one object are slower than I wish,
like 90 seconds to preview a model containing ten objects. Maybe
optimization can be seen as a necessary evil, but we do not have an
optimizing compiler here, and I don't think efficiency can be dismissed,
particularly when writing core functions that could be called thousands of
times to make a single object.
On Wed, Nov 1, 2023, 13:46 Rogier Wolff R.E.Wolff@bitwizard.nl wrote:
On Wed, Nov 01, 2023 at 11:49:40AM -0400, Adrian Mariano wrote:
My solution is not merely more succinct. Because it is not
recursive it will be much faster and also able to work on arrays
with more than 5000 entries. A nonrecursive solution is always
better if it exists for these reasons. It would be better even if
the code were longer.
No. The better solution would be the "more readable code". I have been
a proponent of "readable code" for 35 years. (all my adult life. I did
some optimized unreadable stuff in highschool and learned my
lesson....).
We did "real time video processing" in 1995. They guys down the
hallway here are now doing that stuff on a 275TOPS machine. We had
about 30-60M operations per second back then (first dual issue CPU!,
but hard to get the second instruction stream filled.).
Nowadays writing "somewhat inefficient" code is acceptable. As long as
the algorithm is reasonable and not O(n^3) when it should be O(n),
that sort of stuff.
Openscad is VERY inefficient in stuff that should not be all that
inefficent. For example, intersection is O(n^2), right? No it isn't!
it should be O(n log n). Divide the universe in 2 halves (X+ ,
X-). Divide each of those in half (Y+, Y-). After that, each 1/8th
gets split in half again and again, until O(n^2) objects within that
region is actually O(1).
Now it isn't all Openscad's fault. It uses a couple of libraries that
were written expecting to run with tens or maybe hundreds of objects,
but openscad makes it easy to push that into the thousands (still
works fine with 10 years of Moore's law) and millions. And that's when
the trouble starts and you should've used a better algorithm in the
first place.
Roger.
Yes. now It seems to be better at writing code that works, but you
to prod it in the right direction. it sometimes gives more weight to
problem, rather than the language, and gives a 'pythonesk' response.
I asked it what it thought of your solution (which is more succinct)
function remove_zeros(vec) = [for(val=vec) if (val>0) val];
it gave a good explanation, then added -
vec = remove_zeros(vec);
This line of code would update vec to be a new vector with all
values removed.
I hope this helps! Let me know if you have any other questions
OpenSCAD or anything else. 😊
win some, lose some...
On 01/11/2023 11:23, Adrian Mariano wrote:
ChatGPT wrote filter_gt_zero?
The way it should be done is:
function remove_zeros(vec) = [for(val=vec) if (val!=0) val];
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
If your code has the right structure it will do tail recursion. Right
structure used to be very limited (and often hostile to readability). I
think it has improved, but I don't know what the rules are. If I want to
know if I have tail recursion i feed a long vector to the code to see if it
bombs. Also not all recursion can be tail recursion. The bezier
computation is such a case. And tail recursion is still slower than list
comprehension.
On Wed, Nov 1, 2023, 15:23 Father Horton <fatherhorton@gmail.com> wrote:
> I thought OpenSCAD did tail recursion.
>
> On Wed, Nov 1, 2023 at 2:13 PM Adrian Mariano <avm4@cornell.edu> wrote:
>
>> In this case I would argue that the nonrecursive code is easier to read.
>> A situation may occur where you are sure that you never need to run on a
>> vector with more than 5k entries, so the recursive solution suffices if it
>> is fast enough. You do understand that due to limits on recursion depth,
>> recursive solutions simply fail on long inputs? I think that pretty,
>> readable code that does not work is inferior to any code that does work.
>>
>> Regarding performance the 20x speed gain I got with nonrecursive bezier
>> surface calculation matters, at least on machines that I use. Many things
>> that I do in openscad with few or just one object are slower than I wish,
>> like 90 seconds to preview a model containing ten objects. Maybe
>> optimization can be seen as a necessary evil, but we do not have an
>> optimizing compiler here, and I don't think efficiency can be dismissed,
>> particularly when writing core functions that could be called thousands of
>> times to make a single object.
>>
>> On Wed, Nov 1, 2023, 13:46 Rogier Wolff <R.E.Wolff@bitwizard.nl> wrote:
>>
>>> On Wed, Nov 01, 2023 at 11:49:40AM -0400, Adrian Mariano wrote:
>>>
>>> > My solution is not merely more succinct. Because it is not
>>> > recursive it will be much faster and also able to work on arrays
>>> > with more than 5000 entries. A nonrecursive solution is always
>>> > better if it exists for these reasons. It would be better even if
>>> > the code were longer.
>>>
>>> No. The better solution would be the "more readable code". I have been
>>> a proponent of "readable code" for 35 years. (all my adult life. I did
>>> some optimized unreadable stuff in highschool and learned my
>>> lesson....).
>>>
>>> We did "real time video processing" in 1995. They guys down the
>>> hallway here are now doing that stuff on a 275TOPS machine. We had
>>> about 30-60M operations per second back then (first dual issue CPU!,
>>> but hard to get the second instruction stream filled.).
>>>
>>> Nowadays writing "somewhat inefficient" code is acceptable. As long as
>>> the algorithm is reasonable and not O(n^3) when it should be O(n),
>>> that sort of stuff.
>>>
>>> Openscad is VERY inefficient in stuff that should not be all that
>>> inefficent. For example, intersection is O(n^2), right? No it isn't!
>>> it should be O(n log n). Divide the universe in 2 halves (X+ ,
>>> X-). Divide each of those in half (Y+, Y-). After that, each 1/8th
>>> gets split in half again and again, until O(n^2) objects within that
>>> region is actually O(1).
>>>
>>> Now it isn't all Openscad's fault. It uses a couple of libraries that
>>> were written expecting to run with tens or maybe hundreds of objects,
>>> but openscad makes it easy to push that into the thousands (still
>>> works fine with 10 years of Moore's law) and millions. And that's when
>>> the trouble starts and you should've used a better algorithm in the
>>> first place.
>>>
>>> Roger.
>>>
>>> > On Wed, Nov 1, 2023, 07:56 Raymond West <raywest@raywest.com> wrote:
>>> >
>>> > > Yes. now It seems to be better at writing code that works, but you
>>> have
>>> > > to prod it in the right direction. it sometimes gives more weight to
>>> the
>>> > > problem, rather than the language, and gives a 'pythonesk' response.
>>> > >
>>> > > I asked it what it thought of your solution (which is more succinct)
>>> > >
>>> > > function remove_zeros(vec) = [for(val=vec) if (val>0) val];
>>> > >
>>> > > it gave a good explanation, then added -
>>> > >
>>> > > vec = remove_zeros(vec);
>>> > >
>>> > >
>>> > > This line of code would update vec to be a new vector with all
>>> zero
>>> > > values removed.
>>> > >
>>> > > I hope this helps! Let me know if you have any other questions
>>> about
>>> > > OpenSCAD or anything else. 😊
>>> > >
>>> > >
>>> > > win some, lose some...
>>> > > On 01/11/2023 11:23, Adrian Mariano wrote:
>>> > >
>>> > > ChatGPT wrote filter_gt_zero?
>>> > >
>>> > >
>>> > > The way it should be done is:
>>> > >
>>> > > function remove_zeros(vec) = [for(val=vec) if (val!=0) val];
>>> > >
>>> > > _______________________________________________
>>> > > OpenSCAD mailing list
>>> > > To unsubscribe send an email to discuss-leave@lists.openscad.org
>>> > >
>>>
>>> > _______________________________________________
>>> > OpenSCAD mailing list
>>> > To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>
>>>
>>> --
>>> ** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ **
>>> +31-15-2049110 **
>>> ** Delftechpark 11 2628 XJ Delft, The Netherlands
>>> <https://www.google.com/maps/search/Delftechpark+11+2628+XJ%C2%A0+Delft,+The+Netherlands?entry=gmail&source=g>.
>>> KVK: 27239233 **
>>> f equals m times a. When your f is steady, and your m is going down
>>> your a is going up. -- Chris Hadfield about flying up the space shuttle.
>>> _______________________________________________
>>> OpenSCAD mailing list
>>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>
>> _______________________________________________
>> OpenSCAD mailing list
>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
FH
Father Horton
Wed, Nov 1, 2023 9:51 PM
To tail recurse, the expression after the : can’t do anything other than
call the function again, possibly (hopefully) with changed arguments.
On Wed, Nov 1, 2023 at 2:41 PM Adrian Mariano avm4@cornell.edu wrote:
If your code has the right structure it will do tail recursion. Right
structure used to be very limited (and often hostile to readability). I
think it has improved, but I don't know what the rules are. If I want to
know if I have tail recursion i feed a long vector to the code to see if it
bombs. Also not all recursion can be tail recursion. The bezier
computation is such a case. And tail recursion is still slower than list
comprehension.
On Wed, Nov 1, 2023, 15:23 Father Horton fatherhorton@gmail.com wrote:
I thought OpenSCAD did tail recursion.
On Wed, Nov 1, 2023 at 2:13 PM Adrian Mariano avm4@cornell.edu wrote:
In this case I would argue that the nonrecursive code is easier to
read. A situation may occur where you are sure that you never need to run
on a vector with more than 5k entries, so the recursive solution suffices
if it is fast enough. You do understand that due to limits on recursion
depth, recursive solutions simply fail on long inputs? I think that
pretty, readable code that does not work is inferior to any code that does
work.
Regarding performance the 20x speed gain I got with nonrecursive bezier
surface calculation matters, at least on machines that I use. Many things
that I do in openscad with few or just one object are slower than I wish,
like 90 seconds to preview a model containing ten objects. Maybe
optimization can be seen as a necessary evil, but we do not have an
optimizing compiler here, and I don't think efficiency can be dismissed,
particularly when writing core functions that could be called thousands of
times to make a single object.
On Wed, Nov 1, 2023, 13:46 Rogier Wolff R.E.Wolff@bitwizard.nl wrote:
On Wed, Nov 01, 2023 at 11:49:40AM -0400, Adrian Mariano wrote:
My solution is not merely more succinct. Because it is not
recursive it will be much faster and also able to work on arrays
with more than 5000 entries. A nonrecursive solution is always
better if it exists for these reasons. It would be better even if
the code were longer.
No. The better solution would be the "more readable code". I have been
a proponent of "readable code" for 35 years. (all my adult life. I did
some optimized unreadable stuff in highschool and learned my
lesson....).
We did "real time video processing" in 1995. They guys down the
hallway here are now doing that stuff on a 275TOPS machine. We had
about 30-60M operations per second back then (first dual issue CPU!,
but hard to get the second instruction stream filled.).
Nowadays writing "somewhat inefficient" code is acceptable. As long as
the algorithm is reasonable and not O(n^3) when it should be O(n),
that sort of stuff.
Openscad is VERY inefficient in stuff that should not be all that
inefficent. For example, intersection is O(n^2), right? No it isn't!
it should be O(n log n). Divide the universe in 2 halves (X+ ,
X-). Divide each of those in half (Y+, Y-). After that, each 1/8th
gets split in half again and again, until O(n^2) objects within that
region is actually O(1).
Now it isn't all Openscad's fault. It uses a couple of libraries that
were written expecting to run with tens or maybe hundreds of objects,
but openscad makes it easy to push that into the thousands (still
works fine with 10 years of Moore's law) and millions. And that's when
the trouble starts and you should've used a better algorithm in the
first place.
Roger.
Yes. now It seems to be better at writing code that works, but you
to prod it in the right direction. it sometimes gives more weight
problem, rather than the language, and gives a 'pythonesk' response.
I asked it what it thought of your solution (which is more succinct)
function remove_zeros(vec) = [for(val=vec) if (val>0) val];
it gave a good explanation, then added -
vec = remove_zeros(vec);
This line of code would update vec to be a new vector with all
values removed.
I hope this helps! Let me know if you have any other questions
OpenSCAD or anything else. 😊
win some, lose some...
On 01/11/2023 11:23, Adrian Mariano wrote:
ChatGPT wrote filter_gt_zero?
The way it should be done is:
function remove_zeros(vec) = [for(val=vec) if (val!=0) val];
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
To tail recurse, the expression after the : can’t do anything other than
call the function again, possibly (hopefully) with changed arguments.
On Wed, Nov 1, 2023 at 2:41 PM Adrian Mariano <avm4@cornell.edu> wrote:
> If your code has the right structure it will do tail recursion. Right
> structure used to be very limited (and often hostile to readability). I
> think it has improved, but I don't know what the rules are. If I want to
> know if I have tail recursion i feed a long vector to the code to see if it
> bombs. Also not all recursion can be tail recursion. The bezier
> computation is such a case. And tail recursion is still slower than list
> comprehension.
>
> On Wed, Nov 1, 2023, 15:23 Father Horton <fatherhorton@gmail.com> wrote:
>
>> I thought OpenSCAD did tail recursion.
>>
>> On Wed, Nov 1, 2023 at 2:13 PM Adrian Mariano <avm4@cornell.edu> wrote:
>>
>>> In this case I would argue that the nonrecursive code is easier to
>>> read. A situation may occur where you are sure that you never need to run
>>> on a vector with more than 5k entries, so the recursive solution suffices
>>> if it is fast enough. You do understand that due to limits on recursion
>>> depth, recursive solutions simply fail on long inputs? I think that
>>> pretty, readable code that does not work is inferior to any code that does
>>> work.
>>>
>>> Regarding performance the 20x speed gain I got with nonrecursive bezier
>>> surface calculation matters, at least on machines that I use. Many things
>>> that I do in openscad with few or just one object are slower than I wish,
>>> like 90 seconds to preview a model containing ten objects. Maybe
>>> optimization can be seen as a necessary evil, but we do not have an
>>> optimizing compiler here, and I don't think efficiency can be dismissed,
>>> particularly when writing core functions that could be called thousands of
>>> times to make a single object.
>>>
>>> On Wed, Nov 1, 2023, 13:46 Rogier Wolff <R.E.Wolff@bitwizard.nl> wrote:
>>>
>>>> On Wed, Nov 01, 2023 at 11:49:40AM -0400, Adrian Mariano wrote:
>>>>
>>>> > My solution is not merely more succinct. Because it is not
>>>> > recursive it will be much faster and also able to work on arrays
>>>> > with more than 5000 entries. A nonrecursive solution is always
>>>> > better if it exists for these reasons. It would be better even if
>>>> > the code were longer.
>>>>
>>>> No. The better solution would be the "more readable code". I have been
>>>> a proponent of "readable code" for 35 years. (all my adult life. I did
>>>> some optimized unreadable stuff in highschool and learned my
>>>> lesson....).
>>>>
>>>> We did "real time video processing" in 1995. They guys down the
>>>> hallway here are now doing that stuff on a 275TOPS machine. We had
>>>> about 30-60M operations per second back then (first dual issue CPU!,
>>>> but hard to get the second instruction stream filled.).
>>>>
>>>> Nowadays writing "somewhat inefficient" code is acceptable. As long as
>>>> the algorithm is reasonable and not O(n^3) when it should be O(n),
>>>> that sort of stuff.
>>>>
>>>> Openscad is VERY inefficient in stuff that should not be all that
>>>> inefficent. For example, intersection is O(n^2), right? No it isn't!
>>>> it should be O(n log n). Divide the universe in 2 halves (X+ ,
>>>> X-). Divide each of those in half (Y+, Y-). After that, each 1/8th
>>>> gets split in half again and again, until O(n^2) objects within that
>>>> region is actually O(1).
>>>>
>>>> Now it isn't all Openscad's fault. It uses a couple of libraries that
>>>> were written expecting to run with tens or maybe hundreds of objects,
>>>> but openscad makes it easy to push that into the thousands (still
>>>> works fine with 10 years of Moore's law) and millions. And that's when
>>>> the trouble starts and you should've used a better algorithm in the
>>>> first place.
>>>>
>>>> Roger.
>>>>
>>>> > On Wed, Nov 1, 2023, 07:56 Raymond West <raywest@raywest.com> wrote:
>>>> >
>>>> > > Yes. now It seems to be better at writing code that works, but you
>>>> have
>>>> > > to prod it in the right direction. it sometimes gives more weight
>>>> to the
>>>> > > problem, rather than the language, and gives a 'pythonesk' response.
>>>> > >
>>>> > > I asked it what it thought of your solution (which is more succinct)
>>>> > >
>>>> > > function remove_zeros(vec) = [for(val=vec) if (val>0) val];
>>>> > >
>>>> > > it gave a good explanation, then added -
>>>> > >
>>>> > > vec = remove_zeros(vec);
>>>> > >
>>>> > >
>>>> > > This line of code would update vec to be a new vector with all
>>>> zero
>>>> > > values removed.
>>>> > >
>>>> > > I hope this helps! Let me know if you have any other questions
>>>> about
>>>> > > OpenSCAD or anything else. 😊
>>>> > >
>>>> > >
>>>> > > win some, lose some...
>>>> > > On 01/11/2023 11:23, Adrian Mariano wrote:
>>>> > >
>>>> > > ChatGPT wrote filter_gt_zero?
>>>> > >
>>>> > >
>>>> > > The way it should be done is:
>>>> > >
>>>> > > function remove_zeros(vec) = [for(val=vec) if (val!=0) val];
>>>> > >
>>>> > > _______________________________________________
>>>> > > OpenSCAD mailing list
>>>> > > To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>> > >
>>>>
>>>> > _______________________________________________
>>>> > OpenSCAD mailing list
>>>> > To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>>
>>>>
>>>> --
>>>> ** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ **
>>>> +31-15-2049110 **
>>>> ** Delftechpark 11 2628 XJ Delft, The Netherlands
>>>> <https://www.google.com/maps/search/Delftechpark+11+2628+XJ%C2%A0+Delft,+The+Netherlands?entry=gmail&source=g>.
>>>> KVK: 27239233 **
>>>> f equals m times a. When your f is steady, and your m is going down
>>>> your a is going up. -- Chris Hadfield about flying up the space
>>>> shuttle.
>>>> _______________________________________________
>>>> OpenSCAD mailing list
>>>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>>
>>> _______________________________________________
>>> OpenSCAD mailing list
>>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>
>> _______________________________________________
>> OpenSCAD mailing list
>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
FH
Father Horton
Thu, Nov 2, 2023 12:05 AM
When I look at it, ChatGPT did come up with a tail-recursive definition.
This works:
function filter_gt_zero(vec, i=0, res=[]) =
i == len(vec) ?
res :
filter_gt_zero(vec, i+1, vec[i] > 0 ? concat(res, [vec[i]]) : res);
testvector = [for (i = [0:99999]) floor(rands(0, 10, 1)[0])];
echo(filter_gt_zero(testvector));
On Wed, Nov 1, 2023 at 4:51 PM Father Horton fatherhorton@gmail.com wrote:
To tail recurse, the expression after the : can’t do anything other than
call the function again, possibly (hopefully) with changed arguments.
On Wed, Nov 1, 2023 at 2:41 PM Adrian Mariano avm4@cornell.edu wrote:
If your code has the right structure it will do tail recursion. Right
structure used to be very limited (and often hostile to readability). I
think it has improved, but I don't know what the rules are. If I want to
know if I have tail recursion i feed a long vector to the code to see if it
bombs. Also not all recursion can be tail recursion. The bezier
computation is such a case. And tail recursion is still slower than list
comprehension.
On Wed, Nov 1, 2023, 15:23 Father Horton fatherhorton@gmail.com wrote:
I thought OpenSCAD did tail recursion.
On Wed, Nov 1, 2023 at 2:13 PM Adrian Mariano avm4@cornell.edu wrote:
In this case I would argue that the nonrecursive code is easier to
read. A situation may occur where you are sure that you never need to run
on a vector with more than 5k entries, so the recursive solution suffices
if it is fast enough. You do understand that due to limits on recursion
depth, recursive solutions simply fail on long inputs? I think that
pretty, readable code that does not work is inferior to any code that does
work.
Regarding performance the 20x speed gain I got with nonrecursive bezier
surface calculation matters, at least on machines that I use. Many things
that I do in openscad with few or just one object are slower than I wish,
like 90 seconds to preview a model containing ten objects. Maybe
optimization can be seen as a necessary evil, but we do not have an
optimizing compiler here, and I don't think efficiency can be dismissed,
particularly when writing core functions that could be called thousands of
times to make a single object.
On Wed, Nov 1, 2023, 13:46 Rogier Wolff R.E.Wolff@bitwizard.nl wrote:
On Wed, Nov 01, 2023 at 11:49:40AM -0400, Adrian Mariano wrote:
My solution is not merely more succinct. Because it is not
recursive it will be much faster and also able to work on arrays
with more than 5000 entries. A nonrecursive solution is always
better if it exists for these reasons. It would be better even if
the code were longer.
No. The better solution would be the "more readable code". I have been
a proponent of "readable code" for 35 years. (all my adult life. I did
some optimized unreadable stuff in highschool and learned my
lesson....).
We did "real time video processing" in 1995. They guys down the
hallway here are now doing that stuff on a 275TOPS machine. We had
about 30-60M operations per second back then (first dual issue CPU!,
but hard to get the second instruction stream filled.).
Nowadays writing "somewhat inefficient" code is acceptable. As long as
the algorithm is reasonable and not O(n^3) when it should be O(n),
that sort of stuff.
Openscad is VERY inefficient in stuff that should not be all that
inefficent. For example, intersection is O(n^2), right? No it isn't!
it should be O(n log n). Divide the universe in 2 halves (X+ ,
X-). Divide each of those in half (Y+, Y-). After that, each 1/8th
gets split in half again and again, until O(n^2) objects within that
region is actually O(1).
Now it isn't all Openscad's fault. It uses a couple of libraries that
were written expecting to run with tens or maybe hundreds of objects,
but openscad makes it easy to push that into the thousands (still
works fine with 10 years of Moore's law) and millions. And that's when
the trouble starts and you should've used a better algorithm in the
first place.
Roger.
Yes. now It seems to be better at writing code that works, but
to prod it in the right direction. it sometimes gives more weight
problem, rather than the language, and gives a 'pythonesk'
I asked it what it thought of your solution (which is more
function remove_zeros(vec) = [for(val=vec) if (val>0) val];
it gave a good explanation, then added -
vec = remove_zeros(vec);
This line of code would update vec to be a new vector with
values removed.
I hope this helps! Let me know if you have any other
OpenSCAD or anything else. 😊
win some, lose some...
On 01/11/2023 11:23, Adrian Mariano wrote:
ChatGPT wrote filter_gt_zero?
The way it should be done is:
function remove_zeros(vec) = [for(val=vec) if (val!=0) val];
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
When I look at it, ChatGPT did come up with a tail-recursive definition.
This works:
function filter_gt_zero(vec, i=0, res=[]) =
i == len(vec) ?
res :
filter_gt_zero(vec, i+1, vec[i] > 0 ? concat(res, [vec[i]]) : res);
testvector = [for (i = [0:99999]) floor(rands(0, 10, 1)[0])];
echo(filter_gt_zero(testvector));
On Wed, Nov 1, 2023 at 4:51 PM Father Horton <fatherhorton@gmail.com> wrote:
> To tail recurse, the expression after the : can’t do anything other than
> call the function again, possibly (hopefully) with changed arguments.
>
> On Wed, Nov 1, 2023 at 2:41 PM Adrian Mariano <avm4@cornell.edu> wrote:
>
>> If your code has the right structure it will do tail recursion. Right
>> structure used to be very limited (and often hostile to readability). I
>> think it has improved, but I don't know what the rules are. If I want to
>> know if I have tail recursion i feed a long vector to the code to see if it
>> bombs. Also not all recursion can be tail recursion. The bezier
>> computation is such a case. And tail recursion is still slower than list
>> comprehension.
>>
>> On Wed, Nov 1, 2023, 15:23 Father Horton <fatherhorton@gmail.com> wrote:
>>
>>> I thought OpenSCAD did tail recursion.
>>>
>>> On Wed, Nov 1, 2023 at 2:13 PM Adrian Mariano <avm4@cornell.edu> wrote:
>>>
>>>> In this case I would argue that the nonrecursive code is easier to
>>>> read. A situation may occur where you are sure that you never need to run
>>>> on a vector with more than 5k entries, so the recursive solution suffices
>>>> if it is fast enough. You do understand that due to limits on recursion
>>>> depth, recursive solutions simply fail on long inputs? I think that
>>>> pretty, readable code that does not work is inferior to any code that does
>>>> work.
>>>>
>>>> Regarding performance the 20x speed gain I got with nonrecursive bezier
>>>> surface calculation matters, at least on machines that I use. Many things
>>>> that I do in openscad with few or just one object are slower than I wish,
>>>> like 90 seconds to preview a model containing ten objects. Maybe
>>>> optimization can be seen as a necessary evil, but we do not have an
>>>> optimizing compiler here, and I don't think efficiency can be dismissed,
>>>> particularly when writing core functions that could be called thousands of
>>>> times to make a single object.
>>>>
>>>> On Wed, Nov 1, 2023, 13:46 Rogier Wolff <R.E.Wolff@bitwizard.nl> wrote:
>>>>
>>>>> On Wed, Nov 01, 2023 at 11:49:40AM -0400, Adrian Mariano wrote:
>>>>>
>>>>> > My solution is not merely more succinct. Because it is not
>>>>> > recursive it will be much faster and also able to work on arrays
>>>>> > with more than 5000 entries. A nonrecursive solution is always
>>>>> > better if it exists for these reasons. It would be better even if
>>>>> > the code were longer.
>>>>>
>>>>> No. The better solution would be the "more readable code". I have been
>>>>> a proponent of "readable code" for 35 years. (all my adult life. I did
>>>>> some optimized unreadable stuff in highschool and learned my
>>>>> lesson....).
>>>>>
>>>>> We did "real time video processing" in 1995. They guys down the
>>>>> hallway here are now doing that stuff on a 275TOPS machine. We had
>>>>> about 30-60M operations per second back then (first dual issue CPU!,
>>>>> but hard to get the second instruction stream filled.).
>>>>>
>>>>> Nowadays writing "somewhat inefficient" code is acceptable. As long as
>>>>> the algorithm is reasonable and not O(n^3) when it should be O(n),
>>>>> that sort of stuff.
>>>>>
>>>>> Openscad is VERY inefficient in stuff that should not be all that
>>>>> inefficent. For example, intersection is O(n^2), right? No it isn't!
>>>>> it should be O(n log n). Divide the universe in 2 halves (X+ ,
>>>>> X-). Divide each of those in half (Y+, Y-). After that, each 1/8th
>>>>> gets split in half again and again, until O(n^2) objects within that
>>>>> region is actually O(1).
>>>>>
>>>>> Now it isn't all Openscad's fault. It uses a couple of libraries that
>>>>> were written expecting to run with tens or maybe hundreds of objects,
>>>>> but openscad makes it easy to push that into the thousands (still
>>>>> works fine with 10 years of Moore's law) and millions. And that's when
>>>>> the trouble starts and you should've used a better algorithm in the
>>>>> first place.
>>>>>
>>>>> Roger.
>>>>>
>>>>> > On Wed, Nov 1, 2023, 07:56 Raymond West <raywest@raywest.com> wrote:
>>>>> >
>>>>> > > Yes. now It seems to be better at writing code that works, but
>>>>> you have
>>>>> > > to prod it in the right direction. it sometimes gives more weight
>>>>> to the
>>>>> > > problem, rather than the language, and gives a 'pythonesk'
>>>>> response.
>>>>> > >
>>>>> > > I asked it what it thought of your solution (which is more
>>>>> succinct)
>>>>> > >
>>>>> > > function remove_zeros(vec) = [for(val=vec) if (val>0) val];
>>>>> > >
>>>>> > > it gave a good explanation, then added -
>>>>> > >
>>>>> > > vec = remove_zeros(vec);
>>>>> > >
>>>>> > >
>>>>> > > This line of code would update vec to be a new vector with
>>>>> all zero
>>>>> > > values removed.
>>>>> > >
>>>>> > > I hope this helps! Let me know if you have any other
>>>>> questions about
>>>>> > > OpenSCAD or anything else. 😊
>>>>> > >
>>>>> > >
>>>>> > > win some, lose some...
>>>>> > > On 01/11/2023 11:23, Adrian Mariano wrote:
>>>>> > >
>>>>> > > ChatGPT wrote filter_gt_zero?
>>>>> > >
>>>>> > >
>>>>> > > The way it should be done is:
>>>>> > >
>>>>> > > function remove_zeros(vec) = [for(val=vec) if (val!=0) val];
>>>>> > >
>>>>> > > _______________________________________________
>>>>> > > OpenSCAD mailing list
>>>>> > > To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>>> > >
>>>>>
>>>>> > _______________________________________________
>>>>> > OpenSCAD mailing list
>>>>> > To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>>>
>>>>>
>>>>> --
>>>>> ** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ **
>>>>> +31-15-2049110 **
>>>>> ** Delftechpark 11 2628 XJ Delft, The Netherlands
>>>>> <https://www.google.com/maps/search/Delftechpark+11+2628+XJ%C2%A0+Delft,+The+Netherlands?entry=gmail&source=g>.
>>>>> KVK: 27239233 **
>>>>> f equals m times a. When your f is steady, and your m is going down
>>>>> your a is going up. -- Chris Hadfield about flying up the space
>>>>> shuttle.
>>>>> _______________________________________________
>>>>> OpenSCAD mailing list
>>>>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>>>
>>>> _______________________________________________
>>>> OpenSCAD mailing list
>>>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>>
>>> _______________________________________________
>>> OpenSCAD mailing list
>>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>
>> _______________________________________________
>> OpenSCAD mailing list
>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>
>
P
pca006132
Thu, Nov 2, 2023 12:45 AM
We can do CPS transform to automatically convert code into tail recursive
forms, and we can restrict the transform a bit so it does not create higher
order functions.
However, I would argue that recursive function calls can be made more
efficient if we optimize our interpreter. The current interpreter is quite
slow. See https://github.com/openscad/openscad/issues/4771 for discussion...
On Thu, Nov 2, 2023, 8:06 AM Father Horton fatherhorton@gmail.com wrote:
When I look at it, ChatGPT did come up with a tail-recursive definition.
This works:
function filter_gt_zero(vec, i=0, res=[]) =
i == len(vec) ?
res :
filter_gt_zero(vec, i+1, vec[i] > 0 ? concat(res, [vec[i]]) :
res);
testvector = [for (i = [0:99999]) floor(rands(0, 10, 1)[0])];
echo(filter_gt_zero(testvector));
On Wed, Nov 1, 2023 at 4:51 PM Father Horton fatherhorton@gmail.com
wrote:
To tail recurse, the expression after the : can’t do anything other than
call the function again, possibly (hopefully) with changed arguments.
On Wed, Nov 1, 2023 at 2:41 PM Adrian Mariano avm4@cornell.edu wrote:
If your code has the right structure it will do tail recursion. Right
structure used to be very limited (and often hostile to readability). I
think it has improved, but I don't know what the rules are. If I want to
know if I have tail recursion i feed a long vector to the code to see if it
bombs. Also not all recursion can be tail recursion. The bezier
computation is such a case. And tail recursion is still slower than list
comprehension.
On Wed, Nov 1, 2023, 15:23 Father Horton fatherhorton@gmail.com wrote:
I thought OpenSCAD did tail recursion.
On Wed, Nov 1, 2023 at 2:13 PM Adrian Mariano avm4@cornell.edu wrote:
In this case I would argue that the nonrecursive code is easier to
read. A situation may occur where you are sure that you never need to run
on a vector with more than 5k entries, so the recursive solution suffices
if it is fast enough. You do understand that due to limits on recursion
depth, recursive solutions simply fail on long inputs? I think that
pretty, readable code that does not work is inferior to any code that does
work.
Regarding performance the 20x speed gain I got with nonrecursive
bezier surface calculation matters, at least on machines that I use. Many
things that I do in openscad with few or just one object are slower than I
wish, like 90 seconds to preview a model containing ten objects. Maybe
optimization can be seen as a necessary evil, but we do not have an
optimizing compiler here, and I don't think efficiency can be dismissed,
particularly when writing core functions that could be called thousands of
times to make a single object.
On Wed, Nov 1, 2023, 13:46 Rogier Wolff R.E.Wolff@bitwizard.nl
wrote:
On Wed, Nov 01, 2023 at 11:49:40AM -0400, Adrian Mariano wrote:
My solution is not merely more succinct. Because it is not
recursive it will be much faster and also able to work on arrays
with more than 5000 entries. A nonrecursive solution is always
better if it exists for these reasons. It would be better even if
the code were longer.
No. The better solution would be the "more readable code". I have been
a proponent of "readable code" for 35 years. (all my adult life. I did
some optimized unreadable stuff in highschool and learned my
lesson....).
We did "real time video processing" in 1995. They guys down the
hallway here are now doing that stuff on a 275TOPS machine. We had
about 30-60M operations per second back then (first dual issue CPU!,
but hard to get the second instruction stream filled.).
Nowadays writing "somewhat inefficient" code is acceptable. As long as
the algorithm is reasonable and not O(n^3) when it should be O(n),
that sort of stuff.
Openscad is VERY inefficient in stuff that should not be all that
inefficent. For example, intersection is O(n^2), right? No it isn't!
it should be O(n log n). Divide the universe in 2 halves (X+ ,
X-). Divide each of those in half (Y+, Y-). After that, each 1/8th
gets split in half again and again, until O(n^2) objects within that
region is actually O(1).
Now it isn't all Openscad's fault. It uses a couple of libraries that
were written expecting to run with tens or maybe hundreds of objects,
but openscad makes it easy to push that into the thousands (still
works fine with 10 years of Moore's law) and millions. And that's when
the trouble starts and you should've used a better algorithm in the
first place.
Roger.
Yes. now It seems to be better at writing code that works, but
to prod it in the right direction. it sometimes gives more weight
problem, rather than the language, and gives a 'pythonesk'
I asked it what it thought of your solution (which is more
function remove_zeros(vec) = [for(val=vec) if (val>0) val];
it gave a good explanation, then added -
vec = remove_zeros(vec);
This line of code would update vec to be a new vector with
values removed.
I hope this helps! Let me know if you have any other
OpenSCAD or anything else. 😊
win some, lose some...
On 01/11/2023 11:23, Adrian Mariano wrote:
ChatGPT wrote filter_gt_zero?
The way it should be done is:
function remove_zeros(vec) = [for(val=vec) if (val!=0) val];
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
We can do CPS transform to automatically convert code into tail recursive
forms, and we can restrict the transform a bit so it does not create higher
order functions.
However, I would argue that recursive function calls can be made more
efficient if we optimize our interpreter. The current interpreter is quite
slow. See https://github.com/openscad/openscad/issues/4771 for discussion...
On Thu, Nov 2, 2023, 8:06 AM Father Horton <fatherhorton@gmail.com> wrote:
> When I look at it, ChatGPT did come up with a tail-recursive definition.
> This works:
>
> function filter_gt_zero(vec, i=0, res=[]) =
> i == len(vec) ?
> res :
> filter_gt_zero(vec, i+1, vec[i] > 0 ? concat(res, [vec[i]]) :
> res);
>
> testvector = [for (i = [0:99999]) floor(rands(0, 10, 1)[0])];
>
> echo(filter_gt_zero(testvector));
>
>
>
> On Wed, Nov 1, 2023 at 4:51 PM Father Horton <fatherhorton@gmail.com>
> wrote:
>
>> To tail recurse, the expression after the : can’t do anything other than
>> call the function again, possibly (hopefully) with changed arguments.
>>
>> On Wed, Nov 1, 2023 at 2:41 PM Adrian Mariano <avm4@cornell.edu> wrote:
>>
>>> If your code has the right structure it will do tail recursion. Right
>>> structure used to be very limited (and often hostile to readability). I
>>> think it has improved, but I don't know what the rules are. If I want to
>>> know if I have tail recursion i feed a long vector to the code to see if it
>>> bombs. Also not all recursion can be tail recursion. The bezier
>>> computation is such a case. And tail recursion is still slower than list
>>> comprehension.
>>>
>>> On Wed, Nov 1, 2023, 15:23 Father Horton <fatherhorton@gmail.com> wrote:
>>>
>>>> I thought OpenSCAD did tail recursion.
>>>>
>>>> On Wed, Nov 1, 2023 at 2:13 PM Adrian Mariano <avm4@cornell.edu> wrote:
>>>>
>>>>> In this case I would argue that the nonrecursive code is easier to
>>>>> read. A situation may occur where you are sure that you never need to run
>>>>> on a vector with more than 5k entries, so the recursive solution suffices
>>>>> if it is fast enough. You do understand that due to limits on recursion
>>>>> depth, recursive solutions simply fail on long inputs? I think that
>>>>> pretty, readable code that does not work is inferior to any code that does
>>>>> work.
>>>>>
>>>>> Regarding performance the 20x speed gain I got with nonrecursive
>>>>> bezier surface calculation matters, at least on machines that I use. Many
>>>>> things that I do in openscad with few or just one object are slower than I
>>>>> wish, like 90 seconds to preview a model containing ten objects. Maybe
>>>>> optimization can be seen as a necessary evil, but we do not have an
>>>>> optimizing compiler here, and I don't think efficiency can be dismissed,
>>>>> particularly when writing core functions that could be called thousands of
>>>>> times to make a single object.
>>>>>
>>>>> On Wed, Nov 1, 2023, 13:46 Rogier Wolff <R.E.Wolff@bitwizard.nl>
>>>>> wrote:
>>>>>
>>>>>> On Wed, Nov 01, 2023 at 11:49:40AM -0400, Adrian Mariano wrote:
>>>>>>
>>>>>> > My solution is not merely more succinct. Because it is not
>>>>>> > recursive it will be much faster and also able to work on arrays
>>>>>> > with more than 5000 entries. A nonrecursive solution is always
>>>>>> > better if it exists for these reasons. It would be better even if
>>>>>> > the code were longer.
>>>>>>
>>>>>> No. The better solution would be the "more readable code". I have been
>>>>>> a proponent of "readable code" for 35 years. (all my adult life. I did
>>>>>> some optimized unreadable stuff in highschool and learned my
>>>>>> lesson....).
>>>>>>
>>>>>> We did "real time video processing" in 1995. They guys down the
>>>>>> hallway here are now doing that stuff on a 275TOPS machine. We had
>>>>>> about 30-60M operations per second back then (first dual issue CPU!,
>>>>>> but hard to get the second instruction stream filled.).
>>>>>>
>>>>>> Nowadays writing "somewhat inefficient" code is acceptable. As long as
>>>>>> the algorithm is reasonable and not O(n^3) when it should be O(n),
>>>>>> that sort of stuff.
>>>>>>
>>>>>> Openscad is VERY inefficient in stuff that should not be all that
>>>>>> inefficent. For example, intersection is O(n^2), right? No it isn't!
>>>>>> it should be O(n log n). Divide the universe in 2 halves (X+ ,
>>>>>> X-). Divide each of those in half (Y+, Y-). After that, each 1/8th
>>>>>> gets split in half again and again, until O(n^2) objects within that
>>>>>> region is actually O(1).
>>>>>>
>>>>>> Now it isn't all Openscad's fault. It uses a couple of libraries that
>>>>>> were written expecting to run with tens or maybe hundreds of objects,
>>>>>> but openscad makes it easy to push that into the thousands (still
>>>>>> works fine with 10 years of Moore's law) and millions. And that's when
>>>>>> the trouble starts and you should've used a better algorithm in the
>>>>>> first place.
>>>>>>
>>>>>> Roger.
>>>>>>
>>>>>> > On Wed, Nov 1, 2023, 07:56 Raymond West <raywest@raywest.com>
>>>>>> wrote:
>>>>>> >
>>>>>> > > Yes. now It seems to be better at writing code that works, but
>>>>>> you have
>>>>>> > > to prod it in the right direction. it sometimes gives more weight
>>>>>> to the
>>>>>> > > problem, rather than the language, and gives a 'pythonesk'
>>>>>> response.
>>>>>> > >
>>>>>> > > I asked it what it thought of your solution (which is more
>>>>>> succinct)
>>>>>> > >
>>>>>> > > function remove_zeros(vec) = [for(val=vec) if (val>0) val];
>>>>>> > >
>>>>>> > > it gave a good explanation, then added -
>>>>>> > >
>>>>>> > > vec = remove_zeros(vec);
>>>>>> > >
>>>>>> > >
>>>>>> > > This line of code would update vec to be a new vector with
>>>>>> all zero
>>>>>> > > values removed.
>>>>>> > >
>>>>>> > > I hope this helps! Let me know if you have any other
>>>>>> questions about
>>>>>> > > OpenSCAD or anything else. 😊
>>>>>> > >
>>>>>> > >
>>>>>> > > win some, lose some...
>>>>>> > > On 01/11/2023 11:23, Adrian Mariano wrote:
>>>>>> > >
>>>>>> > > ChatGPT wrote filter_gt_zero?
>>>>>> > >
>>>>>> > >
>>>>>> > > The way it should be done is:
>>>>>> > >
>>>>>> > > function remove_zeros(vec) = [for(val=vec) if (val!=0) val];
>>>>>> > >
>>>>>> > > _______________________________________________
>>>>>> > > OpenSCAD mailing list
>>>>>> > > To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>>>> > >
>>>>>>
>>>>>> > _______________________________________________
>>>>>> > OpenSCAD mailing list
>>>>>> > To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>>>>
>>>>>>
>>>>>> --
>>>>>> ** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ **
>>>>>> +31-15-2049110 **
>>>>>> ** Delftechpark 11 2628 XJ Delft, The Netherlands
>>>>>> <https://www.google.com/maps/search/Delftechpark+11+2628+XJ%C2%A0+Delft,+The+Netherlands?entry=gmail&source=g>.
>>>>>> KVK: 27239233 **
>>>>>> f equals m times a. When your f is steady, and your m is going down
>>>>>> your a is going up. -- Chris Hadfield about flying up the space
>>>>>> shuttle.
>>>>>> _______________________________________________
>>>>>> OpenSCAD mailing list
>>>>>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>>>>
>>>>> _______________________________________________
>>>>> OpenSCAD mailing list
>>>>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>>>
>>>> _______________________________________________
>>>> OpenSCAD mailing list
>>>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>>
>>> _______________________________________________
>>> OpenSCAD mailing list
>>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>
>> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
