Clarifying behaviors
I see three possible behaviors in the evaluation of an expression by
OpenSCAD: it does what is expected, it does something surprising but
reasonable and it does something unreasonable. The last one is clearly a
bug. The first one is the normal case. My interest now is on the second
case: a reasonable surprising behavior. It is surprising when it comprises
less common conditions that are not documented. Being undocumented make them
not eligible to be a feature and that is the issue.
A first example is the product of a list by a float. It is mentioned in the
manual just for vectors. But it works as expected with any list of floats,
like matrices, n-dimensional matrices or even trees of floats. The same
happens with the addition (subtraction) of lists. I cannot expect to add two
lists with different structures (like a vector and a bi-dimensional matrix)
but OpenSCAD is able to add lists of floats with the same structure: [ 1,
[2, 3] ] + [ 5, [5, 5] ] = [ 6, [7, 8] ] . It works even with void lists.
As those more general cases are missing in the documentation, I can not rely
on it as a feature. However, a lot of code I have been written (my
Bezier/Spline library, for instance) benefits from that generality. If
needed I can provide simple examples.
So, my question is: could we rely on the current behavior of those operators
as a feature? Is there a commitment with this feature for the future
versions? This should be clarified and the documentation be expanded
accordingly. I hope the answer be yes :)
I have a couple of other issues like that. I will post about them later.
--
View this message in context: http://forum.openscad.org/Clarifying-behaviors-tp18492.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Here's the behaviour of the + operator, as I understand it.
n is a number, a, b are arbitrary values.
n0 + n1 == the sum of two numbers
[a0, a1, ... ai] + [b0, b1, ... bi] == [a0+b0, a1+b1, ... ai+bi]
(both lists have the same length i)
This is a recursive definition, from which it follows that
[] + [] == []
[1,[2]] + [1,[1]] == [2,[3]]
etc.
Is this expected behaviour? From my perspective, yes. 1. OpenSCAD is a
language for computational geometry, which puts it into the same family as
"math and science" languages like Mathematica, Matlab, Julia, and many
more. 2. All of the "math and science" languages I know support
element-wise addition of vectors, matrices, etc, so it is familiar and
expected behaviour.
Most math-and-science languages represent matrices using a built-in
multi-dimensional array type, which constrains these arrays to have a
"rectangular" shape. If nested arrays are supported at all, then they are
less convenient/more complex to use than normal arrays.
However, there are a few math-and-science languages that don't have
multi-dimensional arrays as a primitive concept: instead, they have
1-dimensional lists, and represent 2-D matrices as lists of lists of
numbers. Examples include Mathematica/Wolfram, K and OpenSCAD. These
languages happen to all be dynamically typed, and element-wise addition
works as it does in OpenSCAD. Elementwise addition of lists works even if
the structure is irregular.
The one thing I find surprising is that OpenSCAD doesn't support
"broadcasting", unlike all of the other math-and-science languages I know.
That is, I expect that
1 + [2,3,4] == [3,4,5]
but that's not supported in OpenSCAD.
On 30 September 2016 at 10:52, Ronaldo rcmpersiano@gmail.com wrote:
I see three possible behaviors in the evaluation of an expression by
OpenSCAD: it does what is expected, it does something surprising but
reasonable and it does something unreasonable. The last one is clearly a
bug. The first one is the normal case. My interest now is on the second
case: a reasonable surprising behavior. It is surprising when it comprises
less common conditions that are not documented. Being undocumented make
them
not eligible to be a feature and that is the issue.
A first example is the product of a list by a float. It is mentioned in the
manual just for vectors. But it works as expected with any list of floats,
like matrices, n-dimensional matrices or even trees of floats. The same
happens with the addition (subtraction) of lists. I cannot expect to add
two
lists with different structures (like a vector and a bi-dimensional matrix)
but OpenSCAD is able to add lists of floats with the same structure: [ 1,
[2, 3] ] + [ 5, [5, 5] ] = [ 6, [7, 8] ] . It works even with void lists.
As those more general cases are missing in the documentation, I can not
rely
on it as a feature. However, a lot of code I have been written (my
Bezier/Spline library, for instance) benefits from that generality. If
needed I can provide simple examples.
So, my question is: could we rely on the current behavior of those
operators
as a feature? Is there a commitment with this feature for the future
versions? This should be clarified and the documentation be expanded
accordingly. I hope the answer be yes :)
I have a couple of other issues like that. I will post about them later.
--
View this message in context: http://forum.openscad.org/
Clarifying-behaviors-tp18492.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 10/01/2016 09:52 PM, doug moen wrote:
The one thing I find surprising is that OpenSCAD doesn't support
"broadcasting", unlike all of the other math-and-science languages
I know.
That is, I expect that
1 + [2,3,4] == [3,4,5]
but that's not supported in OpenSCAD.
Maybe we can collect a list of all those cases and just implement
them. The risk breaking existing scripts is probably not very big,
I hope nobody relies on the fact 1 + [2,3,4] returns undef.
Or is there a formal description of all cases for one of the
existing languages, so we can see if we can (start to) match
features?
ciao,
Torsten.
Thank you, doug, for your answer.
Yes, that is also what I expect from the scalar product and sum of lists. I
could not say, however, that this was my understanding unless I had read the
OpenSCAD code (what I am not able to do :( ). Without a language
specification, the only source to solve this kind of doubts are the manual
and you, the team is working hard for a fantastic open software. And the
manual is sometimes incomplete or misleading. I have started a small
contribution to the manual but in respect to some issues I need your
confirmation.
I don't like the way the manual presents those operator. I don't like the
name vectors for lists. It is misleading for the beginner that may think of
a list of two or three numbers, the coordinates of a 2D or 3D vector. If you
understand [x, [y, z, [w]] ], where x, y, z, w are numbers, as an element of
a vector space, well, I agree that the addition of lists is an addition of
vectors defined for vectors in the same vector space and undef otherwise.
But how many OpenSCAD users have this understanding?
When, by means of lots of tests, I realized that and saw how beautiful is
the language and how misleading is this topic in the manual. And I use it in
my codes.
So, if this behavior is part of the language specification, nice!, I would
try to express it in a manual review. And I can trust in it and keep using
it.
I have never seen the "broadcasting" addition before. Combining this
operator with the recursive nature of the addition of lists, may I expect
that [1, 1] + [[2, 3], [4, 5]] == [[3, 4], [5, 6]] ?
Ronaldo
--
View this message in context: http://forum.openscad.org/Clarifying-behaviors-tp18492p18502.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
There is no language specification. The language manual is actually a wiki
that is edited by end users. Some parts of that documentation is based on
experiments to reverse engineer the specification (that's what I do a lot
of the time), other parts of the documentation are written by developers
when new features are added. Parts of the documentation are great, other
parts are bad and misleading. You can edit it yourself to clarify the
meaning of the + operator.
Ronaldo wrote:
I have never seen the "broadcasting" addition before. Combining this
operator with the recursive nature of the addition of lists, may I expect
that [1, 1] + [[2, 3], [4, 5]] == [[3, 4], [5, 6]] ?
Yes, that's correct.
On 1 October 2016 at 17:05, Ronaldo rcmpersiano@gmail.com wrote:
Thank you, doug, for your answer.
Yes, that is also what I expect from the scalar product and sum of lists. I
could not say, however, that this was my understanding unless I had read
the
OpenSCAD code (what I am not able to do :( ). Without a language
specification, the only source to solve this kind of doubts are the manual
and you, the team is working hard for a fantastic open software. And the
manual is sometimes incomplete or misleading. I have started a small
contribution to the manual but in respect to some issues I need your
confirmation.
I don't like the way the manual presents those operator. I don't like the
name vectors for lists. It is misleading for the beginner that may think of
a list of two or three numbers, the coordinates of a 2D or 3D vector. If
you
understand [x, [y, z, [w]] ], where x, y, z, w are numbers, as an element
of
a vector space, well, I agree that the addition of lists is an addition of
vectors defined for vectors in the same vector space and undef otherwise.
But how many OpenSCAD users have this understanding?
When, by means of lots of tests, I realized that and saw how beautiful is
the language and how misleading is this topic in the manual. And I use it
in
my codes.
So, if this behavior is part of the language specification, nice!, I would
try to express it in a manual review. And I can trust in it and keep using
it.
I have never seen the "broadcasting" addition before. Combining this
operator with the recursive nature of the addition of lists, may I expect
that [1, 1] + [[2, 3], [4, 5]] == [[3, 4], [5, 6]] ?
Ronaldo
--
View this message in context: http://forum.openscad.org/
Clarifying-behaviors-tp18492p18502.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I asked this before but got no answer. By mistake, I found that I could use a
3x3 matrix instead of a 4x4 in the multmatrix() operator to get a linear
transformation. It seems that, in general, extra lines and columns of the
input matrix (if more then 4 is present) are discarded and missing elements
from the 4x4 standard are fulfilled by the respective elements of the
identity matrix. You can confirm this displaying the CSG tree. The important
case for me is the possibility to input a 3x3 matrix when I don't need a
translation. Don't you think this simplifies the code and should be
documented in the on line manual?
--
View this message in context: http://forum.openscad.org/Clarifying-behaviors-tp18492p18505.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
In my experience the "de facto" language spec is in the several hundred
regression tests.
Just as a simple example, here is the test for "min, max" functions
https://github.com/openscad/openscad/blob/master/testdata/scad/functions/min-max-tests.scad
Here are the expected results
If a build doesnt produce those results, the test will fail.
I have a feeling that most of the people working on the project do not
want to make changes that break the regression tests.
If you dig around the tests/scad you can find tests for vector / list
operations. I am not sure if the complicated ones you are using are in
there, but they might be.
There is a Travis CI automatic test that gets run every time someone
commits code to the master branch. It actually runs the regression tests
as part of it's "build". You can see results here
https://travis-ci.org/openscad/openscad
past results here
https://travis-ci.org/openscad/openscad/builds
--
don bright
hmbright@fastmail.com
On Sat, Oct 1, 2016, at 05:50 PM, Ronaldo wrote:
I asked this before but got no answer. By mistake, I found that I could
use a
3x3 matrix instead of a 4x4 in the multmatrix() operator to get a linear
transformation. It seems that, in general, extra lines and columns of the
input matrix (if more then 4 is present) are discarded and missing
elements
from the 4x4 standard are fulfilled by the respective elements of the
identity matrix. You can confirm this displaying the CSG tree. The
important
case for me is the possibility to input a 3x3 matrix when I don't need a
translation. Don't you think this simplifies the code and should be
documented in the on line manual?
--
View this message in context:
http://forum.openscad.org/Clarifying-behaviors-tp18492p18505.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Valuable information, don bright. Thank you.
donbright wrote
If you dig around the tests/scad you can find tests for vector / list
operations. I am not sure if the complicated ones you are using are in
there, but they might be.
In a first quick look, I found just simple tests with homogeneous uni and
bi-dimensional lists. But I found many interesting and surprising others. As
a lazy man, when I want to check something I generate random data, animate
the code and sit back staring at the console...
My use of those properties is neither exoctic nor complicated. I will give
you a simple example. Suppose you define a function performing the
calculations of a polynomial given its coefficients:
function polynomial(coef, u) =
sum_list([ for(i=[0:len(coef)-1]) coef[i]*pow(u,i) ]);
Although, the code has been written for a polynomial with real coefficients
it can be used for more general cases if you observe that the only
operations with parameter coef inside this function are additions and scalar
products by the power factors. In fact, we may use 2D or 3D points and
vectors as coefficients of the function and define a parametric curve in the
space without any change in its code:
function curve(p,n) = [ for(i=[0:n]) polynomial(p,i/n)];
p = [ [0,0], [1,0], [1,1] ];
echo(curve(p,5));
// ECHO: [[0, 0], [0.24, 0.04], [0.56, 0.16], [0.96, 0.36], [1.44, 0.64],
[2, 1]]
We may go further and compute the mesh of parametric 3D surfaces from
curve() and polynomial() by:
function surface(q, n, m) =
let( c = curve(q, n) ) [ for(i=[0:m]) polynomial(c,i/m) ];
q = [ [ [0,0,0], [1,0,0], [1,1,0] ],
[ [0,0,1], [1,0,1], [1,1,1] ],
[ [0,0,2], [1,0,2], [1,1,2] ] ];
echo(surface(q,2,3));
// ECHO: [ [[0, 0, 0], [1, 0, 0], [1, 1, 0]],
// [[0, 0, 0.666667], [1.91667, 0, 0.666667], [1.91667,
1.91667, 0.666667]],
// [[0, 0, 2], [3.5, 0, 2], [3.5, 3.5, 2]], [[0, 0, 4], [5.75,
0, 4], [5.75, 5.75, 4]]]
Note that the input argument coef of polynomial() is a list of points in
curve() and a matrix of points in surface(). And that the results of the
function polynomial() are homogeneous list of objects of the same type of
coef. The fundamental concept here is that the starting function is linear
in respect to the argument coef.
That code conciseness is impossible with typed programming languages.
--
View this message in context: http://forum.openscad.org/Clarifying-behaviors-tp18492p18509.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
In another thread
http://forum.openscad.org/Can-you-sweep-a-object-with-fingers-tc19057.html#a19218
:
Parkinbot wrote
CGAL seems to collapse all vertices with same coordinates and connect
faces based on vertex coordinates, similar to STL processing. This
observation simplified a lot the task of integrating many surfaces in one
polyhedron: each face may be processed individually.
but as far as I know, this is not documented and might change in future.
Usually it is not a good idea, to build new cities on such grounding.
Maybe one from the dev team can say more about this.
Many things are not documented in OpenSCAD and some of them are very basic
ones like variable scopes. That is why I opened the current discussion.
My hyphotesis is reasonable. It is the same behind the STL format. So if
OpenSCAD is able to import STL files it should be able to comply with the
rule I rely on. Further, if OpenSCAD do not comply with this rule in the
future, either using CGAL or any other geometric engine, I will claim that
rejecting the union of two cubes with just one vertex in common is a bug.
Either the topology is consistent with the geometry or not. If it is not I
will abandon OpenSCAD.
--
View this message in context: http://forum.openscad.org/Clarifying-behaviors-tp18492p19222.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On Nov 18, 2016, at 13:47, Ronaldo rcmpersiano@gmail.com wrote:
I will claim that rejecting the union of two cubes with just one vertex in common is a bug.
I’d love to be able to robustly process such objects, at the very least since they can be valuable partial results.
However, our path into CGAL uses software components with a strict manifold requirement, so this is no trivial to implement.
So no, it’s not a bug, it’s a missing feature. It needs resources to implement properly.
If anyone wants to have a crack at it:
https://github.com/openscad/openscad/issues/584
https://github.com/openscad/openscad/issues/591
https://github.com/openscad/openscad/blob/master/src/cgalutils.cc#L37
-> The challenge is that a CGAL Nef polyhedron is created from a CGAL Polyhedron_3. The latter cannot be created from a non-manifold mesh.
-Marius