RW
Raymond West
Tue, Oct 31, 2023 10:42 PM
Hi Jordan,
Thanks for the reply. I think the main reason I used the development
version, IIRC, was to be able to adjust the fonts. As you describe it
working in 2021.01, is as described in the user manual.
I think, if string handling was better, then I could pull out the values
between commas, say. I'm uncertain, since I've never used it, if perhaps
'search' can pull out a list of numbers from a string such as
"45,63,98,15,6,89" .
On 31/10/2023 16:28, Jordan Brown wrote:
On 10/31/2023 5:33 AM, Raymond West wrote:
However, does its customizer act the same as that within openscad
(apart from appearance of font, etc). I'm using openscad version
2022.11.18.ci12805 (git 1746d5a83) but I find that the example on
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Customizer
//Text box for vector with more than 4 elements
Vector6=[12,34,44,43,23,23];
does not show in my openscad customizer window.
Hmm. Works in 2021.01, not in the development snapshot. (Mine is a few
days old.)
In 2021.01, with up to four values they're shown in individual boxes;
with five or more they're shown as a single box with a bracketed list.
In a current build, with five or more the parameter just disappears.
How can I allow values to be entered into a list via the customiser,
when the length of the list is unknown?
That's a good question. Even with 2021.01, if you want to start with
one, two, three, or four entries there's no way for the user to add more
(or remove them). There should probably be markup to control the
behavior.
Also, is it possible to move /resize the customizer panel?
It appears that, like the other panes, if you check "Enable docking of
Editor and Console in different places" in Edit/Preferences/Advanced,
you can move the customizer pane around. If you further check "Enable
undocking of Editor and Console to separate windows", you can undock it
and move and resize it freely.
It would be nice if there was markup that you could put on a file that
said "this is intended for customization", so that the customizer could
appear and disappear automatically. I'd rather not spend the screen
space when I really don't intend the model to be customized, without
having to manually turn the customizer on and off.
Hi Jordan,
Thanks for the reply. I think the main reason I used the development
version, IIRC, was to be able to adjust the fonts. As you describe it
working in 2021.01, is as described in the user manual.
I think, if string handling was better, then I could pull out the values
between commas, say. I'm uncertain, since I've never used it, if perhaps
'search' can pull out a list of numbers from a string such as
"45,63,98,15,6,89" .
On 31/10/2023 16:28, Jordan Brown wrote:
> On 10/31/2023 5:33 AM, Raymond West wrote:
>> However, does its customizer act the same as that within openscad
>> (apart from appearance of font, etc). I'm using openscad version
>> 2022.11.18.ci12805 (git 1746d5a83) but I find that the example on
>> https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Customizer
>>
>> //Text box for vector with more than 4 elements
>> Vector6=[12,34,44,43,23,23];
>>
>> does not show in my openscad customizer window.
> Hmm. Works in 2021.01, not in the development snapshot. (Mine is a few
> days old.)
>
> In 2021.01, with up to four values they're shown in individual boxes;
> with five or more they're shown as a single box with a bracketed list.
> In a current build, with five or more the parameter just disappears.
>
>> How can I allow values to be entered into a list via the customiser,
>> when the length of the list is unknown?
>>
> That's a good question. Even with 2021.01, if you want to start with
> one, two, three, or four entries there's no way for the user to add more
> (or remove them). There should probably be markup to control the
> behavior.
>
>
>> Also, is it possible to move /resize the customizer panel?
>>
> It appears that, like the other panes, if you check "Enable docking of
> Editor and Console in different places" in Edit/Preferences/Advanced,
> you can move the customizer pane around. If you further check "Enable
> undocking of Editor and Console to separate windows", you can undock it
> and move and resize it freely.
>
> ---
>
> It would be nice if there was markup that you could put on a file that
> said "this is intended for customization", so that the customizer could
> appear and disappear automatically. I'd rather not spend the screen
> space when I really don't intend the model to be customized, without
> having to manually turn the customizer on and off.
JB
Jordan Brown
Wed, Nov 1, 2023 5:25 AM
On 10/31/2023 3:42 PM, Raymond West wrote:
I think, if string handling was better, then I could pull out the
values between commas, say. I'm uncertain, since I've never used it,
if perhaps 'search' can pull out a list of numbers from a string such
as "45,63,98,15,6,89" .
People have done it. It's just a pain in the neck.
On 10/31/2023 3:42 PM, Raymond West wrote:
> I think, if string handling was better, then I could pull out the
> values between commas, say. I'm uncertain, since I've never used it,
> if perhaps 'search' can pull out a list of numbers from a string such
> as "45,63,98,15,6,89" .
People have done it. It's just a pain in the neck.
RW
Raymond West
Wed, Nov 1, 2023 11:06 AM
For this item, it is a box with partitions. I enter the distances
between partitions, so I can get up to four distances for each x and y
direction, giving 16 pockets (if I gave the postilion of each partition,
then I could get 25 pockets., but that would be more awkward to enter
the locations). I then use a recursive function to go through each list
of x and y distances selecting only the values with a positive value,
so I can enter zero (or negative values) in the customizer, and generate
new lists with only positive values. If the customizer worked for me for
more than four in a list, then the same function could be used, but
then, since the list is variable length, there would be no point in
entering zeros anyway.
// remove 0 from vector
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);
(ChatGPT is handy)
On 01/11/2023 05:25, Jordan Brown wrote:
On 10/31/2023 3:42 PM, Raymond West wrote:
I think, if string handling was better, then I could pull out the
values between commas, say. I'm uncertain, since I've never used it,
if perhaps 'search' can pull out a list of numbers from a string such
as "45,63,98,15,6,89" .
People have done it. It's just a pain in the neck.
For this item, it is a box with partitions. I enter the distances
between partitions, so I can get up to four distances for each x and y
direction, giving 16 pockets (if I gave the postilion of each partition,
then I could get 25 pockets., but that would be more awkward to enter
the locations). I then use a recursive function to go through each list
of x and y distances selecting only the values with a positive value,
so I can enter zero (or negative values) in the customizer, and generate
new lists with only positive values. If the customizer worked for me for
more than four in a list, then the same function could be used, but
then, since the list is variable length, there would be no point in
entering zeros anyway.
// remove 0 from vector
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);
(ChatGPT is handy)
On 01/11/2023 05:25, Jordan Brown wrote:
> On 10/31/2023 3:42 PM, Raymond West wrote:
>> I think, if string handling was better, then I could pull out the
>> values between commas, say. I'm uncertain, since I've never used it,
>> if perhaps 'search' can pull out a list of numbers from a string such
>> as "45,63,98,15,6,89" .
> People have done it. It's just a pain in the neck.
>
AM
Adrian Mariano
Wed, Nov 1, 2023 11:23 AM
ChatGPT wrote filter_gt_zero?
The way it should be done is:
function remove_zeros(vec) = [for(val=vec) if (val!=0) val];
On Wed, Nov 1, 2023 at 7:06 AM Raymond West raywest@raywest.com wrote:
For this item, it is a box with partitions. I enter the distances
between partitions, so I can get up to four distances for each x and y
direction, giving 16 pockets (if I gave the postilion of each partition,
then I could get 25 pockets., but that would be more awkward to enter
the locations). I then use a recursive function to go through each list
of x and y distances selecting only the values with a positive value,
so I can enter zero (or negative values) in the customizer, and generate
new lists with only positive values. If the customizer worked for me for
more than four in a list, then the same function could be used, but
then, since the list is variable length, there would be no point in
entering zeros anyway.
// remove 0 from vector
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);
(ChatGPT is handy)
On 01/11/2023 05:25, Jordan Brown wrote:
On 10/31/2023 3:42 PM, Raymond West wrote:
I think, if string handling was better, then I could pull out the
values between commas, say. I'm uncertain, since I've never used it,
if perhaps 'search' can pull out a list of numbers from a string such
as "45,63,98,15,6,89" .
People have done it. It's just a pain in the neck.
ChatGPT wrote filter_gt_zero?
The way it should be done is:
function remove_zeros(vec) = [for(val=vec) if (val!=0) val];
On Wed, Nov 1, 2023 at 7:06 AM Raymond West <raywest@raywest.com> wrote:
> For this item, it is a box with partitions. I enter the distances
> between partitions, so I can get up to four distances for each x and y
> direction, giving 16 pockets (if I gave the postilion of each partition,
> then I could get 25 pockets., but that would be more awkward to enter
> the locations). I then use a recursive function to go through each list
> of x and y distances selecting only the values with a positive value,
> so I can enter zero (or negative values) in the customizer, and generate
> new lists with only positive values. If the customizer worked for me for
> more than four in a list, then the same function could be used, but
> then, since the list is variable length, there would be no point in
> entering zeros anyway.
>
> // remove 0 from vector
> 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);
>
>
> (ChatGPT is handy)
>
> On 01/11/2023 05:25, Jordan Brown wrote:
> > On 10/31/2023 3:42 PM, Raymond West wrote:
> >> I think, if string handling was better, then I could pull out the
> >> values between commas, say. I'm uncertain, since I've never used it,
> >> if perhaps 'search' can pull out a list of numbers from a string such
> >> as "45,63,98,15,6,89" .
> > People have done it. It's just a pain in the neck.
> >
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
RW
Raymond West
Wed, Nov 1, 2023 11:55 AM
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];
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];
>
RW
Ray West
Wed, Nov 1, 2023 3:02 PM
note that this is in the version running in Bing/Edge, not the paid for
version
On 01/11/2023 11:55, Raymond West 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
note that this is in the version running in Bing/Edge, not the paid for
version
On 01/11/2023 11:55, Raymond West 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
AM
Adrian Mariano
Wed, Nov 1, 2023 3:49 PM
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.
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
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.
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
>
RW
Rogier Wolff
Wed, Nov 1, 2023 5:45 PM
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 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
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. 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.
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. 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.
P
pca006132
Wed, Nov 1, 2023 6:03 PM
To be fair, CGAL's algorithm is actually not that bad if you use
corefinement + floating point arithmetic.
We have a simple benchmark comparing manifold and CGAL corefinement using
floating point computation and we are not orders of magnitude faster in the
single threaded case. See https://github.com/elalish/manifold/pull/575 for
details.
IMO the real problem is robustness with inexact arithmetic and
multi-threaded performance, these are what manifold solves.
On Thu, Nov 2, 2023, 1:46 AM 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
To be fair, CGAL's algorithm is actually not that bad if you use
corefinement + floating point arithmetic.
We have a simple benchmark comparing manifold and CGAL corefinement using
floating point computation and we are not orders of magnitude faster in the
single threaded case. See https://github.com/elalish/manifold/pull/575 for
details.
IMO the real problem is robustness with inexact arithmetic and
multi-threaded performance, these are what manifold solves.
On Thu, Nov 2, 2023, 1:46 AM 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. 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
>
AM
Adrian Mariano
Wed, Nov 1, 2023 7:13 PM
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
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. 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
>