Given that it's an undefined operation, should it throw an error? Or at
least a warning?

On Thu, Aug 31, 2023 at 10:15 AM nop head nop.head@gmail.com wrote:

I would prefer it just did the logical thing, which is to pad with zeros
and return the longest one. It makes more sense when adding 2D vectors and
3D vectors that the X,Y elements get added and the Z is unchanged in the
result rather than dropped.

On Thu, 31 Aug 2023 at 17:04, Father Horton fatherhorton@gmail.com wrote:

Actually what "makes sense" when adding 2d and 3d vectors depends on the
application.  If you want to write generic code that works in 2D and 3d but
ignores extra 3d stuff when in 2d (like I think happens in core openscad)
then it "makes sense" to stay in 2D.

Consider

translate([2,3,4])square([3,4]);

Of course the right behavior is an error---for any situation where the data
doesn't match the correct type, be it translating in 2d, making a square
with a list of 3 dimensions, or mismatched vector additions---but at this
point, presumably this can't be changed because of the whole backward
compatibility thing.

On Thu, Aug 31, 2023 at 12:09 PM nop head nop.head@gmail.com wrote:

On 8/31/2023 1:06 PM, Adrian Mariano wrote:

Or having a 2D object floating in 3D space, which is what the previewer
does.  The renderer appears to project it down to the Z=0 plane.  (Give
or take the mildly odd behavior that the previewer has of displaying all
2D objects as if they are one unit thick.  It can actually do
infinitely-thin objects, but the preview boolean operators don't work on
them.)

Floating 2D labels in 3D space is exactly what the axis labels are.  One
could similarly imagine floating 1D lines in 3D space, like the axis
lines and ticks.

Not that there aren't a ton of ... interesting ... questions about how
boolean operations should work with those objects.

See OEP7: Mixed Dimension Geometry Support
https://github.com/openscad/openscad/wiki/OEP7%3A-Mixed-Dimension-Geometry-Support
for some discussion of more general support for various numbers of
dimensions.

I don't think mixing 2D and 3D geometry is is related to adding vectors,
You can already do translate([x, y], cube([a,b,c]);

It makes sense to be able to offset from a 3D point in the XY plane by a 2D
vector and not have to manually zero pad the 2D vector.

I doubt it would break anything either as who is going to rely on passing
extra values that are silently ignored?

On Fri, 1 Sept 2023 at 00:41, Jordan Brown openscad@jordan.maileater.net
wrote:

My example obviously didn't illustrated what I was trying to illustrate.

I'm believe (though I'm not 100% certain) that there are places in BOSL2
where the 2d case is handled together with the 3d case by allowing a 3d
vector under the expectation that the extra data will be ignored.  Having
it expand to the size of the larger case could potentially break such code,
if it exists,, causing the 2d case to come out as 3d.  I would support the
idea of making it an ERROR to mix sizes, because then people who rely on
this behavior could find and fix.  But changing the behavior is likely to
break existing code and be hard to debug.

On Fri, Sep 1, 2023 at 4:26 AM nop head nop.head@gmail.com wrote:

So you are happy that there is no efficient way of adding unequal length
vectors, which seems to make sense mathematically to me. Currently it
has to be done element wise.

On Fri, 1 Sept 2023 at 11:42, Adrian Mariano avm4@cornell.edu wrote:

On 9/1/2023 4:28 AM, nop head wrote:

Some slightly disorganized thoughts...

There could be "expand 2D to 3D" and "strip 3D to 2D" vector operations

• or, more generally, a "change size of vector" operation that would
  strip or expand as required.  Such a thing could either be built-in or
  written in OpenSCAD.

Similarly, there could be an "add 2D" function that strips (or expands!)
to 2D and adds, and a similar one for 3D.

If the names are short, they could be adequately efficient in a
readability sense.  Not as efficient as having "+" do it natively, but
then you would have the question of whether to expand or strip.

If implemented in OpenSCAD they would not be as performance-efficient as
a built-in mixed-add operation.
If add2() and add3() were builtins, they'd probably be just as
performance-efficient as any alternative.

Note that you can add a 2D vector to a 3D vector with concat(two, 0) +
three.

But because there are two reasonable interpretations of two+three,
indeed an error seems best.

On 01.09.23 18:14, Jordan Brown wrote:

Just throwing that in:

https://github.com/openscad/openscad/issues/4027

ciao,
Torsten.