Hi,

Guest

FH

Father Horton

Fri, Sep 1, 2023 4:58 PM

But because there are two reasonable interpretations of two+three, indeed

an error seems best.

My thoughts exactly. We've seen already differing ideas of what the

"natural" result should be, and someone who chooses the un-implemented one

is going to have a frustrating bug to hunt down.

On Fri, Sep 1, 2023 at 11:15 AM Jordan Brown openscad@jordan.maileater.net

wrote:

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.

OpenSCAD mailing list

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

>
> But because there are two reasonable interpretations of two+three, indeed
> an error seems best.
>
My thoughts exactly. We've seen already differing ideas of what the
"natural" result should be, and someone who chooses the un-implemented one
is going to have a frustrating bug to hunt down.
On Fri, Sep 1, 2023 at 11:15 AM Jordan Brown <openscad@jordan.maileater.net>
wrote:
> 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.
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>

JB

Jordan Brown

Fri, Sep 1, 2023 5:04 PM

On 9/1/2023 9:46 AM, Torsten Paul wrote:

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:

I had blissfully forgotten swizzling. I don't like it, but indeed it

provides an easy way to chop from 3 to 2, and with the enhancement there

provides an easy way to extend from 2 to 3.

(To be clear, the add2() and add3() functions I described were intended

to add two vectors of arbitrary length, yielding a vector of the

specified length.)

On 9/1/2023 9:46 AM, Torsten Paul wrote:
> 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
I had blissfully forgotten swizzling. I don't like it, but indeed it
provides an easy way to chop from 3 to 2, and with the enhancement there
provides an easy way to extend from 2 to 3.
(To be clear, the add2() and add3() functions I described were intended
to add two vectors of arbitrary length, yielding a vector of the
specified length.)

NH

nop head

Fri, Sep 1, 2023 5:22 PM

Yes one could imagine a long list of 3D points and wanting to offset a few

at the beginning.

On Fri, 1 Sept 2023 at 18:04, Jordan Brown openscad@jordan.maileater.net

wrote:

On 9/1/2023 9:46 AM, Torsten Paul wrote:

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

I had blissfully forgotten swizzling. I don't like it, but indeed it

provides an easy way to chop from 3 to 2, and with the enhancement there

provides an easy way to extend from 2 to 3.

(To be clear, the add2() and add3() functions I described were intended to

add two vectors of arbitrary length, yielding a vector of the specified

length.)

OpenSCAD mailing list

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

Yes one could imagine a long list of 3D points and wanting to offset a few
at the beginning.
On Fri, 1 Sept 2023 at 18:04, Jordan Brown <openscad@jordan.maileater.net>
wrote:
> On 9/1/2023 9:46 AM, Torsten Paul wrote:
>
> 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
>
>
> I had blissfully forgotten swizzling. I don't like it, but indeed it
> provides an easy way to chop from 3 to 2, and with the enhancement there
> provides an easy way to extend from 2 to 3.
>
> (To be clear, the add2() and add3() functions I described were intended to
> add two vectors of arbitrary length, yielding a vector of the specified
> length.)
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>

AM

Adrian Mariano

Fri, Sep 1, 2023 5:34 PM

Adding two vectors of different length absolutely does NOT make sense

mathematically. Such objects are from different spaces and they cannot be

added. I know of one other language that allows this abomination, IDL, and

it is basically a bug generator. I have encountered multiple bugs in IDL

code that were enabled by that poor design decision.

Note also that despite your claim that the result should obviously be the

length of the longer argument to the sum, IDL does the same as openscad and

returns just the overlap region. The point is that really the result of

this undefined operation is in fact not obvious.

The operation to add two length 3 factors takes 1.4 microseconds in my

testing, so I think efficiency is unimportant. If you have a computation

big enough where the vector adds take a second you have million adds and

something else will dominate. Using concat or a matrix multiply to extend

the short vector brings run time to 2.7 microseconds.

On Fri, Sep 1, 2023, 07:31 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:

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

OpenSCAD mailing list

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

Adding two vectors of different length absolutely does NOT make sense
mathematically. Such objects are from different spaces and they cannot be
added. I know of one other language that allows this abomination, IDL, and
it is basically a bug generator. I have encountered multiple bugs in IDL
code that were enabled by that poor design decision.
Note also that despite your claim that the result should obviously be the
length of the longer argument to the sum, IDL does the same as openscad and
returns just the overlap region. The point is that really the result of
this undefined operation is in fact not obvious.
The operation to add two length 3 factors takes 1.4 microseconds in my
testing, so I think efficiency is unimportant. If you have a computation
big enough where the vector adds take a second you have million adds and
something else will dominate. Using concat or a matrix multiply to extend
the short vector brings run time to 2.7 microseconds.
On Fri, Sep 1, 2023, 07:31 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:
>
>> 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
>>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>

NH

nop head

Fri, Sep 1, 2023 5:56 PM

They might be from different spaces but a 2D translation in the XY plane

makes perfect sense in a 3D space. It doesn't affect the z ordinate but it

doesn't drop it.

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

Adding two vectors of different length absolutely does NOT make sense

mathematically. Such objects are from different spaces and they cannot be

added. I know of one other language that allows this abomination, IDL, and

it is basically a bug generator. I have encountered multiple bugs in IDL

code that were enabled by that poor design decision.

Note also that despite your claim that the result should obviously be the

length of the longer argument to the sum, IDL does the same as openscad and

returns just the overlap region. The point is that really the result of

this undefined operation is in fact not obvious.

The operation to add two length 3 factors takes 1.4 microseconds in my

testing, so I think efficiency is unimportant. If you have a computation

big enough where the vector adds take a second you have million adds and

something else will dominate. Using concat or a matrix multiply to extend

the short vector brings run time to 2.7 microseconds.

On Fri, Sep 1, 2023, 07:31 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:

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

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

They might be from different spaces but a 2D translation in the XY plane
makes perfect sense in a 3D space. It doesn't affect the z ordinate but it
doesn't drop it.
On Fri, 1 Sept 2023 at 18:34, Adrian Mariano <avm4@cornell.edu> wrote:
> Adding two vectors of different length absolutely does NOT make sense
> mathematically. Such objects are from different spaces and they cannot be
> added. I know of one other language that allows this abomination, IDL, and
> it is basically a bug generator. I have encountered multiple bugs in IDL
> code that were enabled by that poor design decision.
>
> Note also that despite your claim that the result should obviously be the
> length of the longer argument to the sum, IDL does the same as openscad and
> returns just the overlap region. The point is that really the result of
> this undefined operation is in fact not obvious.
>
> The operation to add two length 3 factors takes 1.4 microseconds in my
> testing, so I think efficiency is unimportant. If you have a computation
> big enough where the vector adds take a second you have million adds and
> something else will dominate. Using concat or a matrix multiply to extend
> the short vector brings run time to 2.7 microseconds.
>
> On Fri, Sep 1, 2023, 07:31 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:
>>
>>> 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
>>>
>> _______________________________________________
>> 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

Fri, Sep 1, 2023 9:23 PM

Yes, you can think of ways in which this or that invalid operation "make

sense" because you're mentally modifying the operation so that it does make

sense. Like in the case of 2D translation of 3D objects you're implicitly

promoting the 2D translation operator to 3D. But in a formal mathematical

development you can't just apply an operator that operates on R^2 onto R^3

instead. The problem is that you're thinking of some certain situation

where you have in mind a way to make an invalid operation valid, and think

OpenSCAD should do what you're thinking automatically, but there's no

reason to believe it's always the right thing. In some other context the

"obvious" right thing may be to restrict the result to the smaller output

size. And in some other category of cases, the programmer screwed up and

the right thing is an error message. (In my broader experience with that

other language, this case is the usual one.)

Why should applying a 3d translation to a 2d data point suddenly make my 2d

data into 3d?

It seems to me like in the case where you want to modify the first few

entries of a long vector, probably the code should have been structured

differently so that the first few entries were kept in a separate

variable.

On Fri, Sep 1, 2023 at 1:59 PM nop head nop.head@gmail.com wrote:

They might be from different spaces but a 2D translation in the XY plane

makes perfect sense in a 3D space. It doesn't affect the z ordinate but it

doesn't drop it.

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

Adding two vectors of different length absolutely does NOT make sense

mathematically. Such objects are from different spaces and they cannot be

added. I know of one other language that allows this abomination, IDL, and

it is basically a bug generator. I have encountered multiple bugs in IDL

code that were enabled by that poor design decision.

Note also that despite your claim that the result should obviously be the

length of the longer argument to the sum, IDL does the same as openscad and

returns just the overlap region. The point is that really the result of

this undefined operation is in fact not obvious.

The operation to add two length 3 factors takes 1.4 microseconds in my

testing, so I think efficiency is unimportant. If you have a computation

big enough where the vector adds take a second you have million adds and

something else will dominate. Using concat or a matrix multiply to extend

the short vector brings run time to 2.7 microseconds.

On Fri, Sep 1, 2023, 07:31 nop head nop.head@gmail.com wrote:

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

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

Yes, you can think of ways in which this or that invalid operation "make
sense" because you're mentally modifying the operation so that it does make
sense. Like in the case of 2D translation of 3D objects you're implicitly
promoting the 2D translation operator to 3D. But in a formal mathematical
development you can't just apply an operator that operates on R^2 onto R^3
instead. The problem is that you're thinking of some certain situation
where you have in mind a way to make an invalid operation valid, and think
OpenSCAD should do what you're thinking automatically, but there's no
reason to believe it's always the right thing. In some other context the
"obvious" right thing may be to restrict the result to the smaller output
size. And in some other category of cases, the programmer screwed up and
the right thing is an error message. (In my broader experience with that
other language, this case is the usual one.)
Why should applying a 3d translation to a 2d data point suddenly make my 2d
data into 3d?
It seems to me like in the case where you want to modify the first few
entries of a long vector, probably the code should have been structured
differently so that the first few entries were kept in a separate
variable.
On Fri, Sep 1, 2023 at 1:59 PM nop head <nop.head@gmail.com> wrote:
> They might be from different spaces but a 2D translation in the XY plane
> makes perfect sense in a 3D space. It doesn't affect the z ordinate but it
> doesn't drop it.
>
> On Fri, 1 Sept 2023 at 18:34, Adrian Mariano <avm4@cornell.edu> wrote:
>
>> Adding two vectors of different length absolutely does NOT make sense
>> mathematically. Such objects are from different spaces and they cannot be
>> added. I know of one other language that allows this abomination, IDL, and
>> it is basically a bug generator. I have encountered multiple bugs in IDL
>> code that were enabled by that poor design decision.
>>
>> Note also that despite your claim that the result should obviously be the
>> length of the longer argument to the sum, IDL does the same as openscad and
>> returns just the overlap region. The point is that really the result of
>> this undefined operation is in fact not obvious.
>>
>> The operation to add two length 3 factors takes 1.4 microseconds in my
>> testing, so I think efficiency is unimportant. If you have a computation
>> big enough where the vector adds take a second you have million adds and
>> something else will dominate. Using concat or a matrix multiply to extend
>> the short vector brings run time to 2.7 microseconds.
>>
>> On Fri, Sep 1, 2023, 07:31 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:
>>>
>>>> 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
>>>>
>>> _______________________________________________
>>> 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
>

NH

nop head

Fri, Sep 1, 2023 10:47 PM

Why should applying a 3d translation to a 2d data point suddenly make my

2d data into 3d?

Because the 3D space has the 2D space embedded in it. I.e. the XY plane. So

if you translate a 3D point along Z it becomes a 3D point. I don't see why

anybody would be surprised by that interpretation whereas ignoring the Z

ordinate certainly surprised me.

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

Yes, you can think of ways in which this or that invalid operation "make

sense" because you're mentally modifying the operation so that it does make

sense. Like in the case of 2D translation of 3D objects you're implicitly

promoting the 2D translation operator to 3D. But in a formal mathematical

development you can't just apply an operator that operates on R^2 onto R^3

instead. The problem is that you're thinking of some certain situation

where you have in mind a way to make an invalid operation valid, and think

OpenSCAD should do what you're thinking automatically, but there's no

reason to believe it's always the right thing. In some other context the

"obvious" right thing may be to restrict the result to the smaller output

size. And in some other category of cases, the programmer screwed up and

the right thing is an error message. (In my broader experience with that

other language, this case is the usual one.)

Why should applying a 3d translation to a 2d data point suddenly make my

2d data into 3d?

It seems to me like in the case where you want to modify the first few

entries of a long vector, probably the code should have been structured

differently so that the first few entries were kept in a separate

variable.

On Fri, Sep 1, 2023 at 1:59 PM nop head nop.head@gmail.com wrote:

They might be from different spaces but a 2D translation in the XY plane

makes perfect sense in a 3D space. It doesn't affect the z ordinate but it

doesn't drop it.

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

mathematically. Such objects are from different spaces and they cannot be

added. I know of one other language that allows this abomination, IDL, and

it is basically a bug generator. I have encountered multiple bugs in IDL

code that were enabled by that poor design decision.

the length of the longer argument to the sum, IDL does the same as openscad

and returns just the overlap region. The point is that really the result

of this undefined operation is in fact not obvious.

testing, so I think efficiency is unimportant. If you have a computation

big enough where the vector adds take a second you have million adds and

something else will dominate. Using concat or a matrix multiply to extend

the short vector brings run time to 2.7 microseconds.

On Fri, Sep 1, 2023, 07:31 nop head nop.head@gmail.com wrote:

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.

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:

vectors, You can already do translate([x, y], cube([a,b,c]);

by a 2D vector and not have to manually zero pad the 2D vector.

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

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

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

lines and ticks.

how 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

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

OpenSCAD mailing list

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

>Why should applying a 3d translation to a 2d data point suddenly make my
2d data into 3d?
Because the 3D space has the 2D space embedded in it. I.e. the XY plane. So
if you translate a 3D point along Z it becomes a 3D point. I don't see why
anybody would be surprised by that interpretation whereas ignoring the Z
ordinate certainly surprised me.
On Fri, 1 Sept 2023 at 22:24, Adrian Mariano <avm4@cornell.edu> wrote:
> Yes, you can think of ways in which this or that invalid operation "make
> sense" because you're mentally modifying the operation so that it does make
> sense. Like in the case of 2D translation of 3D objects you're implicitly
> promoting the 2D translation operator to 3D. But in a formal mathematical
> development you can't just apply an operator that operates on R^2 onto R^3
> instead. The problem is that you're thinking of some certain situation
> where you have in mind a way to make an invalid operation valid, and think
> OpenSCAD should do what you're thinking automatically, but there's no
> reason to believe it's always the right thing. In some other context the
> "obvious" right thing may be to restrict the result to the smaller output
> size. And in some other category of cases, the programmer screwed up and
> the right thing is an error message. (In my broader experience with that
> other language, this case is the usual one.)
>
> Why should applying a 3d translation to a 2d data point suddenly make my
> 2d data into 3d?
>
> It seems to me like in the case where you want to modify the first few
> entries of a long vector, probably the code should have been structured
> differently so that the first few entries were kept in a separate
> variable.
>
>
>
>
> On Fri, Sep 1, 2023 at 1:59 PM nop head <nop.head@gmail.com> wrote:
>
>> They might be from different spaces but a 2D translation in the XY plane
>> makes perfect sense in a 3D space. It doesn't affect the z ordinate but it
>> doesn't drop it.
>>
>> On Fri, 1 Sept 2023 at 18:34, Adrian Mariano <avm4@cornell.edu> wrote:
>>
>>> Adding two vectors of different length absolutely does NOT make sense
>>> mathematically. Such objects are from different spaces and they cannot be
>>> added. I know of one other language that allows this abomination, IDL, and
>>> it is basically a bug generator. I have encountered multiple bugs in IDL
>>> code that were enabled by that poor design decision.
>>>
>>> Note also that despite your claim that the result should obviously be
>>> the length of the longer argument to the sum, IDL does the same as openscad
>>> and returns just the overlap region. The point is that really the result
>>> of this undefined operation is in fact not obvious.
>>>
>>> The operation to add two length 3 factors takes 1.4 microseconds in my
>>> testing, so I think efficiency is unimportant. If you have a computation
>>> big enough where the vector adds take a second you have million adds and
>>> something else will dominate. Using concat or a matrix multiply to extend
>>> the short vector brings run time to 2.7 microseconds.
>>>
>>> On Fri, Sep 1, 2023, 07:31 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:
>>>>
>>>>> 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
>>>>>
>>>> _______________________________________________
>>>> 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
>>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>

AM

Adrian Mariano

Sat, Sep 2, 2023 12:14 AM

I didn't say anything about translating "along Z". I said "applying a 3d

translation." Why does translating the point [3,4] by the translation

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

I contend that one can definitely be surprised by this outcome.

It seems reasonably clear to me that the current behavior is bad as a

language design choice, but it's the legacy behavior, so the only

acceptable paths forward are to leave it as-is or make it an error. It

seems like you're trying to make a case for a different bad language design

choice, when it should be apparent that somebody thought the existing

choice was right, so clearly there's not an agreed-upon notion of what the

right behavior is for these undefined cases.

On Fri, Sep 1, 2023 at 6:51 PM nop head nop.head@gmail.com wrote:

Why should applying a 3d translation to a 2d data point suddenly make my

2d data into 3d?

Because the 3D space has the 2D space embedded in it. I.e. the XY plane.

So if you translate a 3D point along Z it becomes a 3D point. I don't see

why anybody would be surprised by that interpretation whereas ignoring the

Z ordinate certainly surprised me.

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

Yes, you can think of ways in which this or that invalid operation "make

sense" because you're mentally modifying the operation so that it does make

sense. Like in the case of 2D translation of 3D objects you're implicitly

promoting the 2D translation operator to 3D. But in a formal mathematical

development you can't just apply an operator that operates on R^2 onto R^3

instead. The problem is that you're thinking of some certain situation

where you have in mind a way to make an invalid operation valid, and think

OpenSCAD should do what you're thinking automatically, but there's no

reason to believe it's always the right thing. In some other context the

"obvious" right thing may be to restrict the result to the smaller output

size. And in some other category of cases, the programmer screwed up and

the right thing is an error message. (In my broader experience with that

other language, this case is the usual one.)

Why should applying a 3d translation to a 2d data point suddenly make my

2d data into 3d?

It seems to me like in the case where you want to modify the first few

entries of a long vector, probably the code should have been structured

differently so that the first few entries were kept in a separate

variable.

On Fri, Sep 1, 2023 at 1:59 PM nop head nop.head@gmail.com wrote:

makes perfect sense in a 3D space. It doesn't affect the z ordinate but it

doesn't drop it.

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

mathematically. Such objects are from different spaces and they cannot be

added. I know of one other language that allows this abomination, IDL, and

it is basically a bug generator. I have encountered multiple bugs in IDL

code that were enabled by that poor design decision.

the length of the longer argument to the sum, IDL does the same as openscad

and returns just the overlap region. The point is that really the result

of this undefined operation is in fact not obvious.

testing, so I think efficiency is unimportant. If you have a computation

big enough where the vector adds take a second you have million adds and

something else will dominate. Using concat or a matrix multiply to extend

the short vector brings run time to 2.7 microseconds.

On Fri, Sep 1, 2023, 07:31 nop head nop.head@gmail.com wrote:

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.

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:

vectors, You can already do translate([x, y], cube([a,b,c]);

by a 2D vector and not have to manually zero pad the 2D vector.

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

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

are. One could similarly imagine floating 1D lines in 3D space, like the

axis lines and ticks.

how 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

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

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 didn't say anything about translating "along Z". I said "applying a 3d
translation." Why does translating the point [3,4] by the translation
[1,1,0] "obviously" result in [4,5,0] which is now 3d instead of 2d?
I contend that one can definitely be surprised by this outcome.
It seems reasonably clear to me that the current behavior is bad as a
language design choice, but it's the legacy behavior, so the only
acceptable paths forward are to leave it as-is or make it an error. It
seems like you're trying to make a case for a different bad language design
choice, when it should be apparent that somebody thought the existing
choice was right, so clearly there's not an agreed-upon notion of what the
right behavior is for these undefined cases.
On Fri, Sep 1, 2023 at 6:51 PM nop head <nop.head@gmail.com> wrote:
> >Why should applying a 3d translation to a 2d data point suddenly make my
> 2d data into 3d?
>
> Because the 3D space has the 2D space embedded in it. I.e. the XY plane.
> So if you translate a 3D point along Z it becomes a 3D point. I don't see
> why anybody would be surprised by that interpretation whereas ignoring the
> Z ordinate certainly surprised me.
>
> On Fri, 1 Sept 2023 at 22:24, Adrian Mariano <avm4@cornell.edu> wrote:
>
>> Yes, you can think of ways in which this or that invalid operation "make
>> sense" because you're mentally modifying the operation so that it does make
>> sense. Like in the case of 2D translation of 3D objects you're implicitly
>> promoting the 2D translation operator to 3D. But in a formal mathematical
>> development you can't just apply an operator that operates on R^2 onto R^3
>> instead. The problem is that you're thinking of some certain situation
>> where you have in mind a way to make an invalid operation valid, and think
>> OpenSCAD should do what you're thinking automatically, but there's no
>> reason to believe it's always the right thing. In some other context the
>> "obvious" right thing may be to restrict the result to the smaller output
>> size. And in some other category of cases, the programmer screwed up and
>> the right thing is an error message. (In my broader experience with that
>> other language, this case is the usual one.)
>>
>> Why should applying a 3d translation to a 2d data point suddenly make my
>> 2d data into 3d?
>>
>> It seems to me like in the case where you want to modify the first few
>> entries of a long vector, probably the code should have been structured
>> differently so that the first few entries were kept in a separate
>> variable.
>>
>>
>>
>>
>> On Fri, Sep 1, 2023 at 1:59 PM nop head <nop.head@gmail.com> wrote:
>>
>>> They might be from different spaces but a 2D translation in the XY plane
>>> makes perfect sense in a 3D space. It doesn't affect the z ordinate but it
>>> doesn't drop it.
>>>
>>> On Fri, 1 Sept 2023 at 18:34, Adrian Mariano <avm4@cornell.edu> wrote:
>>>
>>>> Adding two vectors of different length absolutely does NOT make sense
>>>> mathematically. Such objects are from different spaces and they cannot be
>>>> added. I know of one other language that allows this abomination, IDL, and
>>>> it is basically a bug generator. I have encountered multiple bugs in IDL
>>>> code that were enabled by that poor design decision.
>>>>
>>>> Note also that despite your claim that the result should obviously be
>>>> the length of the longer argument to the sum, IDL does the same as openscad
>>>> and returns just the overlap region. The point is that really the result
>>>> of this undefined operation is in fact not obvious.
>>>>
>>>> The operation to add two length 3 factors takes 1.4 microseconds in my
>>>> testing, so I think efficiency is unimportant. If you have a computation
>>>> big enough where the vector adds take a second you have million adds and
>>>> something else will dominate. Using concat or a matrix multiply to extend
>>>> the short vector brings run time to 2.7 microseconds.
>>>>
>>>> On Fri, Sep 1, 2023, 07:31 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:
>>>>>
>>>>>> 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
>>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>> _______________________________________________
>> 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
>

DM

Douglas Miller

Sat, Sep 2, 2023 1:17 AM

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

length vectors, which seems to make sense mathematically to me.

Currently it has to be done element wise.

Of course there's an efficient way of adding unequal length vectors:

extend the shorter one with zeros until they are the same length, vis --

function extend(a,b) =

len(a) == len(b)

? a

: len(a) < len(b)

? extend(concat(a,[0]), b)

: extend(a, concat(b,[0]))

;

function AddVectors(a,b) = extend(a,b) + extend(b,a);

A = [1,2,3];

B = [4,5,6];

C = [7,8];

D = [3,1,4,1,5,9];

E = [];

echo(A + B);

echo(AddVectors(A,B));

echo(C + D);

echo(AddVectors(C,D));

echo(D + C);

echo(AddVectors(D,C));

echo(B + C);

echo(AddVectors(B,C));

echo(C + E);

echo(AddVectors(C,E));

On 9/1/2023 7: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.
>
Of course there's an efficient way of adding unequal length vectors:
extend the shorter one with zeros until they are the same length, vis --
function extend(a,b) =
len(a) == len(b)
? a
: len(a) < len(b)
? extend(concat(a,[0]), b)
: extend(a, concat(b,[0]))
;
function AddVectors(a,b) = extend(a,b) + extend(b,a);
A = [1,2,3];
B = [4,5,6];
C = [7,8];
D = [3,1,4,1,5,9];
E = [];
echo(A + B);
echo(AddVectors(A,B));
echo(C + D);
echo(AddVectors(C,D));
echo(D + C);
echo(AddVectors(D,C));
echo(B + C);
echo(AddVectors(B,C));
echo(C + E);
echo(AddVectors(C,E));

AM

Adrian Mariano

Sat, Sep 2, 2023 1:48 AM

Well, it's debatable if that counts as efficient. Adding two 3-vectors

takes 1.4 microseconds on my test machine. If I extend a 2-vector to

length 3 by matrix multiplication (the fastest way) then the run time is

nearly double. (Note: I found concat only slightly slower than matrix

multiply.) One could argue this is already not "efficient" and that's only

a low dimensional case. If nophead really wants to modify the first 3

entries of a length 1 million vector, I expect that a native add function

will be many times faster than anything we can do in user space. Of

course, there's the question of where the million data points came from and

whether the modification could be done earlier.

Your proposed method of extending the vectors is recursive, hence it will

be pretty slow, and it might run out of stack if it's not getting tail

recursion. (I never know until I test.)

The right way to extend is with a list comprehension.

function myextend(a,b) =

len(a)>=len(b) ? a

: [for(i=[0:1:len(b)-1]) i<len(a) ? a[i] : 0];

But if efficiency is important, then AddVectors should just do the addition

directly with a list comprehension when the lengths don't match. That all

said...efficiency shouldn't matter much for this, and certainly not in the

2d - 3d case.

On Fri, Sep 1, 2023 at 9:18 PM Douglas Miller doug@milmac.com wrote:

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

length vectors, which seems to make sense mathematically to me.

Currently it has to be done element wise.

Of course there's an efficient way of adding unequal length vectors:

extend the shorter one with zeros until they are the same length, vis --

function extend(a,b) =

len(a) == len(b)

? a

: len(a) < len(b)

? extend(concat(a,[0]), b)

: extend(a, concat(b,[0]))

;

function AddVectors(a,b) = extend(a,b) + extend(b,a);

A = [1,2,3];

B = [4,5,6];

C = [7,8];

D = [3,1,4,1,5,9];

E = [];

echo(A + B);

echo(AddVectors(A,B));

echo(C + D);

echo(AddVectors(C,D));

echo(D + C);

echo(AddVectors(D,C));

echo(B + C);

echo(AddVectors(B,C));

echo(C + E);

echo(AddVectors(C,E));

OpenSCAD mailing list

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

Well, it's debatable if that counts as efficient. Adding two 3-vectors
takes 1.4 microseconds on my test machine. If I extend a 2-vector to
length 3 by matrix multiplication (the fastest way) then the run time is
nearly double. (Note: I found concat only slightly slower than matrix
multiply.) One could argue this is already not "efficient" and that's only
a low dimensional case. If nophead really wants to modify the first 3
entries of a length 1 million vector, I expect that a native add function
will be many times faster than anything we can do in user space. Of
course, there's the question of where the million data points came from and
whether the modification could be done earlier.
Your proposed method of extending the vectors is recursive, hence it will
be pretty slow, and it might run out of stack if it's not getting tail
recursion. (I never know until I test.)
The right way to extend is with a list comprehension.
function myextend(a,b) =
len(a)>=len(b) ? a
: [for(i=[0:1:len(b)-1]) i<len(a) ? a[i] : 0];
But if efficiency is important, then AddVectors should just do the addition
directly with a list comprehension when the lengths don't match. That all
said...efficiency shouldn't matter much for this, and certainly not in the
2d - 3d case.
On Fri, Sep 1, 2023 at 9:18 PM Douglas Miller <doug@milmac.com> wrote:
> On 9/1/2023 7: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.
> >
> Of course there's an efficient way of adding unequal length vectors:
> extend the shorter one with zeros until they are the same length, vis --
>
> function extend(a,b) =
> len(a) == len(b)
> ? a
> : len(a) < len(b)
> ? extend(concat(a,[0]), b)
> : extend(a, concat(b,[0]))
> ;
>
> function AddVectors(a,b) = extend(a,b) + extend(b,a);
>
> A = [1,2,3];
> B = [4,5,6];
> C = [7,8];
> D = [3,1,4,1,5,9];
> E = [];
>
> echo(A + B);
> echo(AddVectors(A,B));
>
> echo(C + D);
> echo(AddVectors(C,D));
>
> echo(D + C);
> echo(AddVectors(D,C));
>
> echo(B + C);
> echo(AddVectors(B,C));
>
> echo(C + E);
> echo(AddVectors(C,E));
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>

Replying to:

Empathy v1.0
2023 ©Harmonylists.com