discuss@lists.openscad.org

OpenSCAD general discussion Mailing-list

View all threads

Empty group counts as child.

NH
nop head
Fri, Nov 24, 2017 10:15 PM

This doesn't seem correct to me

module test() {
echo($i, $children);

children();

}

for($i = [0,1])
test()
if($i)
sphere();

ECHO: 0, 1

ECHO: 1, 1

When $i is 0 test() has no child but $children is still one. The CSG tree
look like this:

group() {

group() {

group();

group() {

group();

}

}

group() {

group();

group() {

group() {

sphere($fn = 0, $fa = 12, $fs = 2, r = 1);

}

}

}

}

So it looks like a false if generates an empty group, why? And that an
empty group counts as a child.

Both look like bugs to me. Why so many groups? All the empty ones and the
ones with one entry look like they can be recursively pruned without any
semantic change. Applying that here would just give.

sphere($fn = 0, $fa = 12, $fs = 2, r = 1);

Which is exactly what is on the screen.

This doesn't seem correct to me module test() { echo($i, $children); children(); } for($i = [0,1]) test() if($i) sphere(); ECHO: 0, 1 ECHO: 1, 1 When $i is 0 test() has no child but $children is still one. The CSG tree look like this: group() { group() { group(); group() { group(); } } group() { group(); group() { group() { sphere($fn = 0, $fa = 12, $fs = 2, r = 1); } } } } So it looks like a false if generates an empty group, why? And that an empty group counts as a child. Both look like bugs to me. Why so many groups? All the empty ones and the ones with one entry look like they can be recursively pruned without any semantic change. Applying that here would just give. sphere($fn = 0, $fa = 12, $fs = 2, r = 1); Which is exactly what is on the screen.
P
Parkinbot
Sat, Nov 25, 2017 1:59 PM
  1. Yes this looks like a flaw indeed. $children seems to have wrong default
    value, which might indeed lead to wrong semantics e.g. in code like this:

module test() {
if($children)
echo("children exist");
}

for(i = [0,1])
test()
if(i)
sphere();

  1. You are also right that empty structures could be extinguished. That
    would demand some postprocessing with respect to the recursive nature of
    such a structure. On the other hand, empty groups are for sure not very too
    time consuming. So why not just live with them?

--
Sent from: http://forum.openscad.org/

1. Yes this looks like a flaw indeed. $children seems to have wrong default value, which might indeed lead to wrong semantics e.g. in code like this: > module test() { > if($children) > echo("children exist"); > } > > for(i = [0,1]) > test() > if(i) > sphere(); 2. You are also right that empty structures could be extinguished. That would demand some postprocessing with respect to the recursive nature of such a structure. On the other hand, empty groups are for sure not very too time consuming. So why not just live with them? -- Sent from: http://forum.openscad.org/
RP
Ronaldo Persiano
Sat, Nov 25, 2017 3:38 PM

2017-11-25 11:59 GMT-02:00 Parkinbot rudolf@parkinbot.com:

  1. You are also right that empty structures could be extinguished. That
    would demand some postprocessing with respect to the recursive nature of
    such a structure.
  • On the other hand, empty groups are for sure not very too time
    consuming.* So why not just live with them?

​That is not exactly true. It may require a lot of time and memory. See:
http://forum.openscad.org/Recursion-issue-td20882.html

2017-11-25 11:59 GMT-02:00 Parkinbot <rudolf@parkinbot.com>: > > 2. You are also right that empty structures could be extinguished. That > would demand some postprocessing with respect to the recursive nature of > such a structure. > * On the other hand, empty groups are for sure not very too time > consuming.* So why not just live with them? > > ​That is not exactly true. It may require a lot of time and memory. See: http://forum.openscad.org/Recursion-issue-td20882.html​
NH
nop head
Sat, Nov 25, 2017 3:58 PM

So why not just live with them?

They totally bloat out the CSG view and make $children report the wrong
number. But why create them in the first place? Why does an if that is
false need to create anything?

On 25 November 2017 at 15:38, Ronaldo Persiano rcmpersiano@gmail.com
wrote:

2017-11-25 11:59 GMT-02:00 Parkinbot rudolf@parkinbot.com:

  1. You are also right that empty structures could be extinguished. That
    would demand some postprocessing with respect to the recursive nature of
    such a structure.
  • On the other hand, empty groups are for sure not very too time
    consuming.* So why not just live with them?

​That is not exactly true. It may require a lot of time and memory. See:
http://forum.openscad.org/Recursion-issue-td20882.html


OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

>So why not just live with them? They totally bloat out the CSG view and make $children report the wrong number. But why create them in the first place? Why does an if that is false need to create anything? On 25 November 2017 at 15:38, Ronaldo Persiano <rcmpersiano@gmail.com> wrote: > > > 2017-11-25 11:59 GMT-02:00 Parkinbot <rudolf@parkinbot.com>: > >> >> 2. You are also right that empty structures could be extinguished. That >> would demand some postprocessing with respect to the recursive nature of >> such a structure. >> * On the other hand, empty groups are for sure not very too time >> consuming.* So why not just live with them? >> >> > ​That is not exactly true. It may require a lot of time and memory. See: > http://forum.openscad.org/Recursion-issue-td20882.html​ > > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >
RP
Ronaldo Persiano
Sat, Nov 25, 2017 5:03 PM


2017-11-25 13:58 GMT-02:00 nop head nop.head@gmail.com:

So why not just live with them?

They totally bloat out the CSG view and make $children report the wrong
number. But why create them in the first place? Why does an if that is
false need to create anything?

And not only conditionals cause wrong answers.

module test() {
if($children)
echo($children,"children exist");
}

module empty() {}

test() { translate(); }

test() { empty(); }

Tree dump:

group() {

group() {

    group() ;

}

}

group() {

group() {

    group() ;

}

}

​ 2017-11-25 13:58 GMT-02:00 nop head <nop.head@gmail.com>: > >So why not just live with them? > > They totally bloat out the CSG view and make $children report the wrong > number. But why create them in the first place? Why does an if that is > false need to create anything? > And not only conditionals cause wrong answers. module test() { if($children) echo($children,"children exist"); } module empty() {} test() { translate(); } test() { empty(); } Tree dump: group() { group() { group() ; } } group() { group() { group() ; } }
MK
Marius Kintel
Sat, Nov 25, 2017 5:11 PM

On Nov 25, 2017, at 10:58 AM, nop head nop.head@gmail.com wrote:

They totally bloat out the CSG view and make $children report the wrong number. But why create them in the first place? Why does an if that is false need to create anything?

The underlying reason for this is that “if” is not a language construct, it’s a built-in module. Since it’s a module, it always returns a node, even when it has no children, similar to an empty union.
Changing the contract of modules to optionally return nothing is possible. Pruning empty sub trees is also a possible post-processing step.
Another option would be to see this in connection with the old "implicit union” story, whose work-in-progress suggests allowing modules to return a (possibly empty) list of nodes, where emptyness is something we can manage in a better way: https://github.com/openscad/openscad/issues/350

-Marius

> On Nov 25, 2017, at 10:58 AM, nop head <nop.head@gmail.com> wrote: > > They totally bloat out the CSG view and make $children report the wrong number. But why create them in the first place? Why does an if that is false need to create anything? > The underlying reason for this is that “if” is not a language construct, it’s a built-in module. Since it’s a module, it always returns a node, even when it has no children, similar to an empty union. Changing the contract of modules to optionally return nothing is possible. Pruning empty sub trees is also a possible post-processing step. Another option would be to see this in connection with the old "implicit union” story, whose work-in-progress suggests allowing modules to return a (possibly empty) list of nodes, where emptyness is something we can manage in a better way: https://github.com/openscad/openscad/issues/350 -Marius
NH
nop head
Sat, Nov 25, 2017 6:49 PM

Hmm, I don't want a lazy union that outputs self intersecting objects
because the slicer I use does not union them it produces the symmetric
difference. I.e. each skin causes a transition from inside to outside.

My idea of a lazy union would only union things that actually do overlap
and take a short when they are disjoint. It would produce the same results
as now but a lot faster where ever you have multiple objects, for example
when you make an array of holes. Currently the only practical way to do
that is to do it in 2D and then extrude it to difference from a 3D object.

Getting rid of empty and single item groups seems like a separate issue as
children and for loops don't really work properly at the moment.

On 25 November 2017 at 17:11, Marius Kintel marius@kintel.net wrote:

On Nov 25, 2017, at 10:58 AM, nop head nop.head@gmail.com wrote:

They totally bloat out the CSG view and make $children report the wrong

number. But why create them in the first place? Why does an if that is
false need to create anything?

The underlying reason for this is that “if” is not a language construct,
it’s a built-in module. Since it’s a module, it always returns a node, even
when it has no children, similar to an empty union.
Changing the contract of modules to optionally return nothing is possible.
Pruning empty sub trees is also a possible post-processing step.
Another option would be to see this in connection with the old "implicit
union” story, whose work-in-progress suggests allowing modules to return a
(possibly empty) list of nodes, where emptyness is something we can manage
in a better way: https://github.com/openscad/openscad/issues/350

-Marius


OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

Hmm, I don't want a lazy union that outputs self intersecting objects because the slicer I use does not union them it produces the symmetric difference. I.e. each skin causes a transition from inside to outside. My idea of a lazy union would only union things that actually do overlap and take a short when they are disjoint. It would produce the same results as now but a lot faster where ever you have multiple objects, for example when you make an array of holes. Currently the only practical way to do that is to do it in 2D and then extrude it to difference from a 3D object. Getting rid of empty and single item groups seems like a separate issue as children and for loops don't really work properly at the moment. On 25 November 2017 at 17:11, Marius Kintel <marius@kintel.net> wrote: > > On Nov 25, 2017, at 10:58 AM, nop head <nop.head@gmail.com> wrote: > > > > They totally bloat out the CSG view and make $children report the wrong > number. But why create them in the first place? Why does an if that is > false need to create anything? > > > The underlying reason for this is that “if” is not a language construct, > it’s a built-in module. Since it’s a module, it always returns a node, even > when it has no children, similar to an empty union. > Changing the contract of modules to optionally return nothing is possible. > Pruning empty sub trees is also a possible post-processing step. > Another option would be to see this in connection with the old "implicit > union” story, whose work-in-progress suggests allowing modules to return a > (possibly empty) list of nodes, where emptyness is something we can manage > in a better way: https://github.com/openscad/openscad/issues/350 > > -Marius > > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >
RP
Ronaldo Persiano
Sat, Nov 25, 2017 8:14 PM

2017-11-25 16:49 GMT-02:00 nop head nop.head@gmail.com:

My idea of a lazy union would only union things that actually do overlap
and take a short when they are disjoint.

​But to check overlaps wouldn't be almost so time consuming as a regular
union?​

2017-11-25 16:49 GMT-02:00 nop head <nop.head@gmail.com>: > My idea of a lazy union would only union things that actually do overlap > and take a short when they are disjoint. > ​But to check overlaps wouldn't be almost so time consuming as a regular union?​
NH
nop head
Sat, Nov 25, 2017 8:31 PM

No in most case you can just check the bounding boxes. You don't get any
false negatives and false positives are no worse than the current situation.

On 25 November 2017 at 20:14, Ronaldo Persiano rcmpersiano@gmail.com
wrote:

2017-11-25 16:49 GMT-02:00 nop head nop.head@gmail.com:

My idea of a lazy union would only union things that actually do overlap
and take a short when they are disjoint.

​But to check overlaps wouldn't be almost so time consuming as a regular
union?​


OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

No in most case you can just check the bounding boxes. You don't get any false negatives and false positives are no worse than the current situation. On 25 November 2017 at 20:14, Ronaldo Persiano <rcmpersiano@gmail.com> wrote: > 2017-11-25 16:49 GMT-02:00 nop head <nop.head@gmail.com>: > >> My idea of a lazy union would only union things that actually do overlap >> and take a short when they are disjoint. >> > > ​But to check overlaps wouldn't be almost so time consuming as a regular > union?​ > > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >
P
Parkinbot
Sun, Nov 26, 2017 12:23 AM

My thought was that the CSG parser will do away with them anyway and will not
take more time than a decicated postprocessor step. But you are right, since
$children is a node count, proper semantics demands getting rid of empty
tails.

nophead wrote

So why not just live with them?

They totally bloat out the CSG view and make $children report the wrong
number. But why create them in the first place? Why does an if that is
false need to create anything?

My thought was that the CSG parser will do away with them anyway and will not take more time than a decicated postprocessor step. But you are right, since $children is a node count, proper semantics demands getting rid of empty tails. nophead wrote >>So why not just live with them? > > They totally bloat out the CSG view and make $children report the wrong > number. But why create them in the first place? Why does an if that is > false need to create anything? -- Sent from: http://forum.openscad.org/