<div dir="ltr"><div><div><div><div>The hull() case WOULD evaluate to a cube despite having void as the second operand. The hull definition is the minimal convex shape that encloses all solids in it, and despite the differece returninig void the first operand is still a solid.<br><br></div><div>For the minkowski it is another story... If our math is not supposed to be right what would be the point of a programming language? The only example you found to justify the current behavior is based on a preexisting error... Openscad should warn that C() is void, but do exactly as instructed. Remember: Computers (especially programming languages) are not supposed to do what they believe you want, they are supposed to do exactly what you tell them to.<br></div><div><br>Anyway... I just finished compiling 2016.06.15 (wow, that's today!) and the issue is still the same.<br><br></div>- If a nothing() is originated from a difference or a previous intersection, then intersection() { nothing(); something();} works.<br></div>- intersection with void module or void union fails.<br></div>- minkowski fails with any voids.<br><br></div><b>And I got ifsolid() to work!</b> I just made sure the condition is never void by adding a far_far_away() particle, and limiting the result to universe(). See attached files, animated, from above.<br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>--<br>Lucas Vinicius Hartmann<br><br></div>Dizem que se você rodar o CD do Windows ao contrário ele mostra uma mensagem demoníaca... Mas isso nem é o pior, se você rodar ele normal ele instala o Windows!<br></div></div></div></div></div>
<br><div class="gmail_quote">2016-06-15 20:45 GMT-03:00 Parkinbot <span dir="ltr"><<a href="mailto:rudolf@parkinbot.com" target="_blank">rudolf@parkinbot.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is one of the typical pathological cases, not worth discussing much in<br>
programming context. You are both right, mathematically an empty set used as<br>
operand for Minkowski will "eat up" any other operand.<br>
<br>
But in programming an operator is better defined and implemented to be as<br>
robust as possible.<br>
<br>
It is easy to "prove", that there is no [0,0,0] involved, otherwise the<br>
following code would not evaluate to a cube.<br>
<br>
<br>
> hull()<br>
> {<br>
>   translate([10, 0])<br>
>   cube(5);<br>
>   difference() // nothing<br>
>   {<br>
>     sphere(1);<br>
>     sphere(2);<br>
>   }<br>
> }<br>
<br>
OpenSCAD implements Minkowski as I would expect it, and do it myself.<br>
<br>
I would want<br>
<br>
<br>
> minkowski(){}<br>
<br>
not to throw an error. And<br>
<br>
<br>
> minkowski(){<br>
> cube[a,b,c];<br>
> };<br>
<br>
to have cube[a,b,c] as unchanged result, instead of getting a not-defined<br>
error. Same applies for intersection(), union() and so on.<br>
<br>
Second, I would not want any shape evaluating to empty to eat up everthing.<br>
<br>
<br>
> minkowski(){<br>
> A();<br>
> B();<br>
> C();<br>
> ...<br>
> }<br>
<br>
Imagine C() is not defined (missing library) and a warning is issued. Should<br>
the result then be empty? For what? For mathematical correctness?<br>
<br>
<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://forum.openscad.org/Evaluating-imported-STL-s-tp17682p17702.html" rel="noreferrer" target="_blank">http://forum.openscad.org/Evaluating-imported-STL-s-tp17682p17702.html</a><br>
<div class="HOEnZb"><div class="h5">Sent from the OpenSCAD mailing list archive at Nabble.com.<br>
<br>
_______________________________________________<br>
OpenSCAD mailing list<br>
<a href="mailto:Discuss@lists.openscad.org">Discuss@lists.openscad.org</a><br>
<a href="http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org" rel="noreferrer" target="_blank">http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org</a><br>
</div></div></blockquote></div><br></div>