# [OpenSCAD] Clarifying behaviors

doug moen doug at moens.org
Sat Oct 1 15:52:47 EDT 2016

```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 at 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 at lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20161001/38c1512c/attachment-0002.html>
```

More information about the Discuss mailing list