On Thu, Aug 31, 2023 at 04:06:14PM -0400, Adrian Mariano wrote:

When given an option when implementing a primitive, you should consider
if based on one option you could easily build the other. In that case,
that's the option you should chose.

So for the Unix SORT program, should you discard equal lines if you
encounter them? It'll improve performance if you encounter that.

The answer is no: You can't magically resurrect those equal lines after
you've discarded them. but the other way around, discarding them later is
easy. (Use the Unix "uniq" program or, nowadays, the -u option on sort).

Same here: Can you magically resurrect the third coordinate after the
primitive has discarded it? no! Can you discard it afterwards if you
don't need it? Yes! So the right decision would've been to do as nop
head suggests: Keep the extra coofdinate and allow the user to drop it
if necessary.

Roger. 

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
f equals m times a. When your f is steady, and your m is going down
your a is going up.  -- Chris Hadfield about flying up the space shuttle.

"obviously" result in [4,5,0] which is now 3d instead of 2d?

Because the XY plane exists in XYZ space and addition is commutative and XY
translations in OpenSCAD work in 3D space.

So translate(v3) translate(v2) is the same as translate(v2) translate(v3)
and both work and should be the same as translate(v2 + v3) or
translate(v3 + v2)

I hate typing because nearly everything I type is a typo, so I prefer terse
and expressive languages.

I have no requirement to offset the first few points in a long list, it was
just a possibility that occured to me after Jordan's comment that should
also work and be efficient.

On Sat, 2 Sept 2023 at 08:33, Rogier Wolff R.E.Wolff@bitwizard.nl wrote:

Why is addition of incompatible operands commutative?  Since it's an
undefined, invalid operation, anything is possible.  You can't lean on
mathematical theory to justify a position which is theoretically invalid.
I don't want my 2d data jumping unexpectedly into 3d.  If that happens then
2d operations won't work on it any more.  Note also that the example I
laid out is not symmetric the way you interpreted it.  I have a point, not
a translation.  A point, like [3,4].  Then I add to it a vector.  What
does adding vectors mean?  Well, it means translation, so that's one
interpretation of what's going on.  When we actually represent operators in
openscad it's with 3x3 or 4x4 matrices and you'll get into trouble if you
try to mix them with the wrong dimension.

You can extend a 2d vector to 3d with a matrix product, which would be
pretty terse if you named the matrix something short, so like E*v1+v2,
where E is previously defined by E=[[1,0],[0,1],[0,0]];  Or you could use
the transpose of that matrix, and multiply on the right, and then it would
work for lists of 2-vectors as well.

Roger makes what may be the strongest argument for the extension behavior
nophead favors, that it's less "lossy".  Of course, the idea that you can
"throw away the extra" is just as true as the idea that you can "extend
vectors to match".  Both require some effort, e.g. a loop or matrix
product, or concat. The big downside of allowing mismatched operations is
that it promotes bugs, and having the language catch your mistakes is, in
my opinion, at least 10x more valuable than making the code slightly easier
to write by doing something "clever" on invalid input.

On Sat, Sep 2, 2023 at 6:57 AM nop head nop.head@gmail.com wrote:

Because addition is commutative and the operands are not incompatible. 2D
space is a subset of 3D space and x,y is a subset of x,y,z  so you can
translate a point on the XY plane in 3 dimensions and it becomes a 3 vector
and you can translate a 3D point by a 2 vector on the XY plane and again
the result is the same 3D point. OpenSCADs translate module has always done
both of these, so it isn't a new concept.

On Sat, 2 Sept 2023 at 13:26, Adrian Mariano avm4@cornell.edu wrote:

On 2023-09-02 5:25 a.m., Adrian Mariano wrote:

I'm with you on that.

Anyway, my take on this whole discussion is that adding vector elements
ought to behave in the same way as adding the corresponding ordinary
variables. So for example, with 'stop at first warning' turned off, the code

a = 1;
c = a + b;
echo(c);

produces

WARNING: Ignoring unknown variable 'b' in file , line 2
WARNING: undefined operation (number + undefined) in file OpenSCAD, line 2
ECHO: undef

This behaviour implies that adding vectors of unequal lengths should
result in undef for the trailing elements of the resulting vector. And,
checking just now, I see that the documentation indicates undef as the
outcome of adding elements of different types.

If OpenSCAD is going to assume a value for a missing operand, that value
really ought to be undef. In which case, it would calculate the
resulting element as number + undef, which is undef.

So to me, the current behaviour can almost be considered a bug -
truncation with no warning, ouch!

But using 0 for a missing operand isn't the best solution.

My 2 cents,

Steve

While that is true for random missing variables the XY plane is embedded in
the XYZ space at Z = 0, so when the vectors are geometry I think it is
perfectly reasonable to notionally add a zero. In practice the loop would
probably just copy the remaining elements instead of terminating early.

On Sat, 2 Sept 2023 at 15:39, Steve Lelievre <
steve.lelievre.canada@gmail.com> wrote:

A 2-vector, meaning two numbers [a,b] can be a whole host of things.  It is
not necessarily "The XY plane embedded in 3-space at Z=0".  That's only one
possible meaning for a 2-vector.  It could be a plane embedded somewhere
else, a plane embedded with some kind of rotation or other transformation.
A plane embedded into a curved surface in R^3, for example, points on the
sphere (with one point missing via stereographic projection).  It could be
the two coefficients that define a line.  It could be a point in the plane
defined by polar coordinates.  It could be the thickness and diameter of a
part in my assembly.  The minimum and maximum value of the y coordinate of
a data set.  It could be anything.

When you say you KNOW how a 2-vector should behave in a 3d context what
you're really saying is that you have made an ASSUMPTION about the meaning
of the 2-vector and an ASSUMPTION about how to embed it into 3 space.  It's
not a truth or a fact.  It's a choice.  And there are other choices, which
result in different outcomes.

On Sat, Sep 2, 2023 at 10:47 AM nop head nop.head@gmail.com wrote:

On 2023-09-02 7:43 a.m., nop head wrote:

And I think that internal self-consistency is more important so ideally
the behaviour for non-vector addition would be followed, as in my
previous email. Namely (1) output warning message if one of the operands
hasn't been created, and (2) proceed as if it was created as undef if
the user preferences are set to keep going after a warning.

Of course, OpenSCAD doesn't work like that at present, so I reckon
safest option is for the developers to leave it alone, noting Adrian's
concerns that existing code might rely on the current behaviour.

Well an OpenSCAD 2 vector has elements .x and .y and a 3 vector has
elements .x, .y and..z. If you are using them for something else then don't
add them with different lengths if it isn't appropriate.

On Sat, 2 Sept 2023 at 16:51, Adrian Mariano avm4@cornell.edu wrote:

The fact that the language happens to allow the notation of .x, .y, and .z
for vectors doesn't mean that vectors are necessarily the x, y, and z
components in R^3.  That would only be a reasonable claim if there was
another data type that could be used instead.  In other words, if we had a
"point" data type that had x, y, and z supported and a generic "vector"
data type that did not.  Then you could justifiably claim that the "point"
data should be treated as living in R^3 and make special assumptions.  But
we don't have that.  We have one generic data type and a convenience
notation that may make no sense much of the time.

When you say, "if you are using them for something else then don't add them
with different lengths" you're basically saying "don't screw up or the
language will punish you".  That's precisely the problematic design choice
I'm arguing against.  The language should help reveal your bugs, not hide
them from you.  People screw up.

Steve, on the matter of consistency, note also that multiplication of
incompatible matrices produces a warning:

WARNING: vector*matrix requires vector length to match matrix row count (3
!= 4) in file ptest.scad, line 61 <61,/home/adrian/scad/ptest.scad>

So in fact if I form a 2d point and try to multiply it on the right by a 3d
transformation matrix, I get an error. If we were to extend nophead's
concept of how things work, OpenSCAD would automatically transform the 2d
point into 3d and then apply the matrix. And note that a 2d point being
used with an affine transformation matrix of the sort OpenSCAD uses has the
form [x,y,1] and a 3d point has the form [x,y,z,1] so the transformation is
actually that the z coordinate must be inserted into the 3rd position, not
at the end, so it's not even obvious geometrically what exactly to do. That
is, a simple rotation matrix would require different embedding rules than
an affine transformation matrix. So ultimately, it's a conception that only
makes sense if we have real objects with methods, where you can create a
point object, and have methods that act on it and do the right thing in
these various situations.

On Sat, Sep 2, 2023 at 12:00 PM nop head nop.head@gmail.com wrote: