### Adding vectors of unequal length

NH
Thu, Aug 31, 2023 3:11 PM

echo([1,2] + [1,2,3]); // ECHO: [2, 4]

It seems that OpenSCAD truncates the longer vector to the length of the
shorter one. It would seem more logical to extend the shorter one with
zeros so the result is the same length as the longer one rather than just
ignoring some elements.

echo([1,2] + [1,2,3]); // ECHO: [2, 4] It seems that OpenSCAD truncates the longer vector to the length of the shorter one. It would seem more logical to extend the shorter one with zeros so the result is the same length as the longer one rather than just ignoring some elements.
FH
Father Horton
Thu, Aug 31, 2023 4:03 PM

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:

echo([1,2] + [1,2,3]); // ECHO: [2, 4]

It seems that OpenSCAD truncates the longer vector to the length of the
shorter one. It would seem more logical to extend the shorter one with
zeros so the result is the same length as the longer one rather than just
ignoring some elements.

To unsubscribe send an email to discuss-leave@lists.openscad.org

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: > echo([1,2] + [1,2,3]); // ECHO: [2, 4] > > It seems that OpenSCAD truncates the longer vector to the length of the > shorter one. It would seem more logical to extend the shorter one with > zeros so the result is the same length as the longer one rather than just > ignoring some elements. > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >
NH
Thu, Aug 31, 2023 4:04 PM

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:

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:

echo([1,2] + [1,2,3]); // ECHO: [2, 4]

It seems that OpenSCAD truncates the longer vector to the length of the
shorter one. It would seem more logical to extend the shorter one with
zeros so the result is the same length as the longer one rather than just
ignoring some elements.

To unsubscribe send an email to discuss-leave@lists.openscad.org

To unsubscribe send an email to discuss-leave@lists.openscad.org

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: > 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: > >> echo([1,2] + [1,2,3]); // ECHO: [2, 4] >> >> It seems that OpenSCAD truncates the longer vector to the length of the >> shorter one. It would seem more logical to extend the shorter one with >> zeros so the result is the same length as the longer one rather than just >> ignoring some elements. >> _______________________________________________ >> OpenSCAD mailing list >> To unsubscribe send an email to discuss-leave@lists.openscad.org >> > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >
AM
Thu, Aug 31, 2023 8:06 PM

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:

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:

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:

echo([1,2] + [1,2,3]); // ECHO: [2, 4]

It seems that OpenSCAD truncates the longer vector to the length of the
shorter one. It would seem more logical to extend the shorter one with
zeros so the result is the same length as the longer one rather than just
ignoring some elements.

To unsubscribe send an email to discuss-leave@lists.openscad.org

To unsubscribe send an email to discuss-leave@lists.openscad.org

To unsubscribe send an email to discuss-leave@lists.openscad.org

JB
Jordan Brown
Thu, Aug 31, 2023 11:40 PM

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

Consider

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

Of course the right behavior is an error---

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
for some discussion of more general support for various numbers of
dimensions.

On 8/31/2023 1:06 PM, Adrian Mariano wrote: > Consider  > > translate([2,3,4])square([3,4]); > > Of course the right behavior is an error--- 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.
NH
Fri, Sep 1, 2023 8:22 AM

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:

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

Consider

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

Of course the right behavior is an error---

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
for some discussion of more general support for various numbers of
dimensions.

To unsubscribe send an email to discuss-leave@lists.openscad.org

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: > On 8/31/2023 1:06 PM, Adrian Mariano wrote: > > Consider > > translate([2,3,4])square([3,4]); > > Of course the right behavior is an error--- > > > 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. > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >
AM
Fri, Sep 1, 2023 10:42 AM

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:

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:

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

Consider

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

Of course the right behavior is an error---

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
for some discussion of more general support for various numbers of
dimensions.

To unsubscribe send an email to discuss-leave@lists.openscad.org

To unsubscribe send an email to discuss-leave@lists.openscad.org

NH
Fri, Sep 1, 2023 11:28 AM

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:

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:

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:

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

Consider

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

Of course the right behavior is an error---

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
for some discussion of more general support for various numbers of
dimensions.

To unsubscribe send an email to discuss-leave@lists.openscad.org

To unsubscribe send an email to discuss-leave@lists.openscad.org

To unsubscribe send an email to discuss-leave@lists.openscad.org

JB
Jordan Brown
Fri, Sep 1, 2023 4:14 PM

On 9/1/2023 4:28 AM, nop head 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.

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

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
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.

TP
Torsten Paul
Fri, Sep 1, 2023 4:46 PM

On 01.09.23 18:14, Jordan Brown wrote: