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