Hi,

Guest

NH

nop head

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.

OpenSCAD mailing list

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

nop head

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.

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

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

Adrian Mariano

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]

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

OpenSCAD mailing list

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

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.
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> OpenSCAD mailing list
> 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

https://github.com/openscad/openscad/wiki/OEP7%3A-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

nop head

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

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

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

Adrian Mariano

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

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

OpenSCAD mailing list

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

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
>> <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
>>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>

NH

nop head

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

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

could similarly imagine floating 1D lines in 3D space, like the axis lines

and ticks.

boolean operations should work with those objects.

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

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

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

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

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

TP

Torsten Paul

Fri, Sep 1, 2023 4:46 PM

On 01.09.23 18:14, Jordan Brown wrote:

If add2() and add3() were builtins, they'd probably be just as

performance-efficient as any alternative.

On 01.09.23 18:14, Jordan Brown wrote:
> If add2() and add3() were builtins, they'd probably be just as
> performance-efficient as any alternative.
Just throwing that in:
https://github.com/openscad/openscad/issues/4027
ciao,
Torsten.

Replying to:

Empathy v1.0
2024 ©Harmonylists.com