discuss@lists.openscad.org

OpenSCAD general discussion Mailing-list

View all threads

Something odd about the product of lists

R
Ronaldo
Mon, Aug 29, 2016 3:39 PM

Let a, b, c and d be floats. For instante:

a = 1; b = 2; c = 3; d = 4;

So the following two lines are valid and equivalent:

echo( [a,b] * [c,d] );
echo( ac + bd );

The next two are not valid and their results are undef:

echo( [a,b] * [c,[d]] );
echo( ac + b[d] );

However, the following two are surprisingly not equivalent:

echo( [a,[b]] * [[c],d] ); // ECHO: undef
echo( a*[c] + [b]*d );    // ECHO: [11]

We may go a little further and observe that the following pair of
expressions are valid and equivalent:

echo( [[a,b],[c,d]] * [[e,f],[g,h]] );
echo([ a*[e,f] + b*[g,h], c*[e,f] + d*[g,h] ]);

for any floats e,..h. But, the following two are not equivalent:

echo( [[a,b],[c,d]] * [[e,[f]],[g,[h]]] );  // ECHO: [undef,undef]
echo([ a*[e,[f]] + b*[g,[h]], c*[e,[f]] + d*[g,[h]] ]); // ECHO: [[7,
[4]], [15, [10]]]

Surprisingly, the scalar product seems to apply to any list of floats:

echo( b*[e,[f,[g,[h]]]]);                  // ECHO: [2, [4, [6, [2]]]]

It seems to me that in evaluating some list expressions, OpenSCAD stops the
recursive process when some of the operands are not an expected float. This
may be a bug or an intentional behavior. But if intended, it it should be
well documented. I vote for a bug.

I think that the product of lists should evaluate deep enough until a valid
expression is found or an intermediate result is invalid. Something like:

a @ b = if a==undef or b==undef return undef
else if a is float
if b is float return a * b
else return [ a @ b[i] | i=0..len(b)-1 ]
else if b is float return [ a[i] @ b | i=0..len(a)-1 ]
else if len(a)== len(b) return sum( { a[i] @ b[i] | i=0..len(a)-1 } )
else return undef

where a and A are floats or lists and @ stands for the operator product of
lists. Note that this is a definition and so it is not a proposal of a new
operator. Certainly, this operator symbol in the language should be *. I
used @ to distinguish the product operator of lists from *, the product
operator of floats.

Any comments?

--
View this message in context: http://forum.openscad.org/Something-odd-about-the-product-of-lists-tp18248.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Let a, b, c and d be floats. For instante: > a = 1; b = 2; c = 3; d = 4; So the following two lines are valid and equivalent: > echo( [a,b] * [c,d] ); > echo( a*c + b*d ); The next two are not valid and their results are undef: > echo( [a,b] * [c,[d]] ); > echo( a*c + b*[d] ); However, the following two are surprisingly not equivalent: > echo( [a,[b]] * [[c],d] ); // ECHO: undef > echo( a*[c] + [b]*d ); // ECHO: [11] We may go a little further and observe that the following pair of expressions are valid and equivalent: > echo( [[a,b],[c,d]] * [[e,f],[g,h]] ); > echo([ a*[e,f] + b*[g,h], c*[e,f] + d*[g,h] ]); for any floats e,..h. But, the following two are not equivalent: > echo( [[a,b],[c,d]] * [[e,[f]],[g,[h]]] ); // ECHO: [undef,undef] > echo([ a*[e,[f]] + b*[g,[h]], c*[e,[f]] + d*[g,[h]] ]); // ECHO: [[7, > [4]], [15, [10]]] Surprisingly, the scalar product seems to apply to any list of floats: > echo( b*[e,[f,[g,[h]]]]); // ECHO: [2, [4, [6, [2]]]] It seems to me that in evaluating some list expressions, OpenSCAD stops the recursive process when some of the operands are not an expected float. This may be a bug or an intentional behavior. But if intended, it it should be well documented. I vote for a bug. I think that the product of lists should evaluate deep enough until a valid expression is found or an intermediate result is invalid. Something like: > a @ b = if a==undef or b==undef return undef > else if a is float > if b is float return a * b > else return [ a @ b[i] | i=0..len(b)-1 ] > else if b is float return [ a[i] @ b | i=0..len(a)-1 ] > else if len(a)== len(b) return sum( { a[i] @ b[i] | i=0..len(a)-1 } ) > else return undef where a and A are floats or lists and @ stands for the operator product of lists. Note that this is a definition and so it is not a proposal of a new operator. Certainly, this operator symbol in the language should be *. I used @ to distinguish the product operator of lists from *, the product operator of floats. Any comments? -- View this message in context: http://forum.openscad.org/Something-odd-about-the-product-of-lists-tp18248.html Sent from the OpenSCAD mailing list archive at Nabble.com.