Empty group counts as child.

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Empty group counts as child.

nophead
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.



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Empty group counts as child.

Parkinbot
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/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Empty group counts as child.

Ronaldo


2017-11-25 11:59 GMT-02:00 Parkinbot <[hidden email]>:

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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Empty group counts as child.

nophead
>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 <[hidden email]> wrote:


2017-11-25 11:59 GMT-02:00 Parkinbot <[hidden email]>:

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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Empty group counts as child.

Ronaldo
2017-11-25 13:58 GMT-02:00 nop head <[hidden email]>:
>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() ;

   }

}



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Empty group counts as child.

kintel
Administrator
In reply to this post by nophead
> On Nov 25, 2017, at 10:58 AM, nop head <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Empty group counts as child.

nophead
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 <[hidden email]> wrote:
> On Nov 25, 2017, at 10:58 AM, nop head <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Empty group counts as child.

Ronaldo
2017-11-25 16:49 GMT-02:00 nop head <[hidden email]>:
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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Empty group counts as child.

nophead
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 <[hidden email]> wrote:
2017-11-25 16:49 GMT-02:00 nop head <[hidden email]>:
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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Empty group counts as child.

Parkinbot
In reply to this post by nophead
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/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Empty group counts as child.

doug.moen
In reply to this post by kintel
Marius said: "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."

My suggestion is to treat "if" as a language construct, consistent with how "if" is treated in a list comprehension.
Just as
   [..., if (false) expr, ...]
does not add any elements to the list under construction, so should
  {...; if (false) shape_expr; ...}
not add any shapes or groups to the group under construction.

On 25 November 2017 at 12:11, Marius Kintel <[hidden email]> wrote:
> On Nov 25, 2017, at 10:58 AM, nop head <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Empty group counts as child.

nophead
Yes It should be a language construct. How many other bits of language are modules? and would they benefit from not being?

On 26 November 2017 at 19:04, doug moen <[hidden email]> wrote:
Marius said: "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."

My suggestion is to treat "if" as a language construct, consistent with how "if" is treated in a list comprehension.
Just as
   [..., if (false) expr, ...]
does not add any elements to the list under construction, so should
  {...; if (false) shape_expr; ...}
not add any shapes or groups to the group under construction.

On 25 November 2017 at 12:11, Marius Kintel <[hidden email]> wrote:
> On Nov 25, 2017, at 10:58 AM, nop head <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Empty group counts as child.

kintel
Administrator
> On Nov 26, 2017, at 3:06 PM, nop head <[hidden email]> wrote:
>
> Yes It should be a language construct. How many other bits of language are modules? and would they benefit from not being?
>
Quite a few. The language of OpenSCAD is really quite minimal.
The language, in its entirety, as Doug has lobbied extensively for, is ripe for a redesign. Some of this is possible to do through iteration and some will eventually require us to break backwards compatibility.

Switching out if-else statements from being modules to being language constructs, while marking that switch as experimental, is a pretty low-risk endeavor. if-else is already managed by the parser, so this is mostly about separating modules from these statements on the AST level.

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Problem with Forum - Inoperative

MichaelAtOz
Administrator

It appears that someone is tinkering with Nabble.

To me the Forum looks inoperative.

When you click the Post button on a reply or new topic you get this:

and the post is not committed.

 

I’ve reported it to Nabble support:

http://support.nabble.com/Another-NAML-change-redirect-to-td7599057.html (lower down)

 

 

Could someone else please try to post just to confirm it is not something re my account setup.

 

Until it is fixed use the mailing-list…

 

 

MichaelAtOz

Forum Admin - when it works…


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Admin - PM me if you need anything,
or if I've done something stupid...

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work.
Obviously inclusion of works of previous authors is not included in the above.


The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Reply | Threaded
Open this post in threaded view
|

Re: Empty group counts as child.

JordanBrown
In reply to this post by nophead
I don't claim to grok all of the implications, and I certainly know nothing of the implementation, but empty nodes seem useful to represent placeholders in the "argument list" that the children represent.

// make first child red, second child green, third child blue
module rgb() {
    color("red") children(0);
    color("green") children(1);
    color("blue") children(2);
}

rgb() {         // only wants green and blue children
    union() ;   // or anything that emits an empty node
    translate([1,1,1]) sphere(1);
    translate([2,2,2]) sphere(1);
}

or

red = true;
green = false;
blue = true;
rgb() {
    if (red) sphere(1);
    if (green) translate([1,1,1]) sphere(1);
    if (blue) translate([2,2,2]) sphere(1);
}


It does seem simple and consistent that every statement produces exactly one node.  Unfortunately, not always adequate - consider the need for intersection_for().  I am not sure whether the simplicity and consistency outweighs the flexibility of allowing some statements to produce zero nodes (and some to produce more than one?).



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Empty group counts as child.

kintel
Administrator
>
> It does seem simple and consistent that every statement produces exactly one node.  Unfortunately, not always adequate - consider the need for intersection_for().  I am not sure whether the simplicity and consistency outweighs the flexibility of allowing some statements to produce zero nodes (and some to produce more than one?).
>
My view is that intersection_for() is a hack to work around exactly this.
In the work-in-progress branch for #350, intersection_for() has been deprecated: https://github.com/openscad/openscad/issues/350

That branch does break a bunch of stuff so I lost momentum implementing it as I haven’t found a good point in time to introduce such changes, or found a middle ground that maintains current behavior for existing designs.

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org