NH
nop head
Sat, Sep 2, 2023 4:37 PM
don't screw up or the language will punish you
OpenSCAD gives more and more warnings forcing me to write more and more
code to work around them. I don't find that useful at all. My time is spent
writing code, not debugging it.
On Sat, 2 Sept 2023 at 17:26, Adrian Mariano avm4@cornell.edu wrote:
The fact that the language happens to allow the notation of .x, .y, and .z
for vectors doesn't mean that vectors are necessarily the x, y, and z
components in R^3. That would only be a reasonable claim if there was
another data type that could be used instead. In other words, if we had a
"point" data type that had x, y, and z supported and a generic "vector"
data type that did not. Then you could justifiably claim that the "point"
data should be treated as living in R^3 and make special assumptions. But
we don't have that. We have one generic data type and a convenience
notation that may make no sense much of the time.
When you say, "if you are using them for something else then don't add
them with different lengths" you're basically saying "don't screw up or the
language will punish you". That's precisely the problematic design choice
I'm arguing against. The language should help reveal your bugs, not hide
them from you. People screw up.
Steve, on the matter of consistency, note also that multiplication of
incompatible matrices produces a warning:
WARNING: vector*matrix requires vector length to match matrix row count (3
!= 4) in file ptest.scad, line 61 http://61,/home/adrian/scad/ptest.scad
So in fact if I form a 2d point and try to multiply it on the right by a
3d transformation matrix, I get an error. If we were to extend nophead's
concept of how things work, OpenSCAD would automatically transform the 2d
point into 3d and then apply the matrix. And note that a 2d point being
used with an affine transformation matrix of the sort OpenSCAD uses has the
form [x,y,1] and a 3d point has the form [x,y,z,1] so the transformation is
actually that the z coordinate must be inserted into the 3rd position, not
at the end, so it's not even obvious geometrically what exactly to do. That
is, a simple rotation matrix would require different embedding rules than
an affine transformation matrix. So ultimately, it's a conception that only
makes sense if we have real objects with methods, where you can create a
point object, and have methods that act on it and do the right thing in
these various situations.
On Sat, Sep 2, 2023 at 12:00 PM nop head nop.head@gmail.com wrote:
Well an OpenSCAD 2 vector has elements .x and .y and a 3 vector has
elements .x, .y and..z. If you are using them for something else then don't
add them with different lengths if it isn't appropriate.
On Sat, 2 Sept 2023 at 16:51, Adrian Mariano avm4@cornell.edu wrote:
A 2-vector, meaning two numbers [a,b] can be a whole host of things. It
is not necessarily "The XY plane embedded in 3-space at Z=0". That's only
one possible meaning for a 2-vector. It could be a plane embedded
somewhere else, a plane embedded with some kind of rotation or other
transformation. A plane embedded into a curved surface in R^3, for
example, points on the sphere (with one point missing via stereographic
projection). It could be the two coefficients that define a line. It
could be a point in the plane defined by polar coordinates. It could be
the thickness and diameter of a part in my assembly. The minimum and
maximum value of the y coordinate of a data set. It could be anything.
When you say you KNOW how a 2-vector should behave in a 3d context what
you're really saying is that you have made an ASSUMPTION about the meaning
of the 2-vector and an ASSUMPTION about how to embed it into 3 space. It's
not a truth or a fact. It's a choice. And there are other choices, which
result in different outcomes.
On Sat, Sep 2, 2023 at 10:47 AM nop head nop.head@gmail.com wrote:
While that is true for random missing variables the XY plane is
embedded in the XYZ space at Z = 0, so when the vectors are geometry I
think it is perfectly reasonable to notionally add a zero. In practice the
loop would probably just copy the remaining elements instead of
terminating early.
On Sat, 2 Sept 2023 at 15:39, Steve Lelievre <
steve.lelievre.canada@gmail.com> wrote:
On 2023-09-02 5:25 a.m., Adrian Mariano wrote:
Why is addition of incompatible operands commutative? Since it's an
undefined, invalid operation, anything is possible.
I'm with you on that.
Anyway, my take on this whole discussion is that adding vector
elements
ought to behave in the same way as adding the corresponding ordinary
variables. So for example, with 'stop at first warning' turned off,
the code
a = 1;
c = a + b;
echo(c);
produces
WARNING: Ignoring unknown variable 'b' in file , line 2
WARNING: undefined operation (number + undefined) in file OpenSCAD,
line 2
ECHO: undef
This behaviour implies that adding vectors of unequal lengths should
result in undef for the trailing elements of the resulting vector.
And,
checking just now, I see that the documentation indicates undef as the
outcome of adding elements of different types.
If OpenSCAD is going to assume a value for a missing operand, that
value
really ought to be undef. In which case, it would calculate the
resulting element as number + undef, which is undef.
So to me, the current behaviour can almost be considered a bug -
truncation with no warning, ouch!
But using 0 for a missing operand isn't the best solution.
My 2 cents,
Steve
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
> don't screw up or the language will punish you
OpenSCAD gives more and more warnings forcing me to write more and more
code to work around them. I don't find that useful at all. My time is spent
writing code, not debugging it.
On Sat, 2 Sept 2023 at 17:26, Adrian Mariano <avm4@cornell.edu> wrote:
> The fact that the language happens to allow the notation of .x, .y, and .z
> for vectors doesn't mean that vectors are necessarily the x, y, and z
> components in R^3. That would only be a reasonable claim if there was
> another data type that could be used instead. In other words, if we had a
> "point" data type that had x, y, and z supported and a generic "vector"
> data type that did not. Then you could justifiably claim that the "point"
> data should be treated as living in R^3 and make special assumptions. But
> we don't have that. We have one generic data type and a convenience
> notation that may make no sense much of the time.
>
> When you say, "if you are using them for something else then don't add
> them with different lengths" you're basically saying "don't screw up or the
> language will punish you". That's precisely the problematic design choice
> I'm arguing against. The language should help reveal your bugs, not hide
> them from you. People screw up.
>
> Steve, on the matter of consistency, note also that multiplication of
> incompatible matrices produces a warning:
>
> WARNING: vector*matrix requires vector length to match matrix row count (3
> != 4) in file ptest.scad, line 61 <http://61,/home/adrian/scad/ptest.scad>
>
> So in fact if I form a 2d point and try to multiply it on the right by a
> 3d transformation matrix, I get an error. If we were to extend nophead's
> concept of how things work, OpenSCAD would automatically transform the 2d
> point into 3d and then apply the matrix. And note that a 2d point being
> used with an affine transformation matrix of the sort OpenSCAD uses has the
> form [x,y,1] and a 3d point has the form [x,y,z,1] so the transformation is
> actually that the z coordinate must be inserted into the 3rd position, not
> at the end, so it's not even obvious geometrically what exactly to do. That
> is, a simple rotation matrix would require different embedding rules than
> an affine transformation matrix. So ultimately, it's a conception that only
> makes sense if we have real objects with methods, where you can create a
> point object, and have methods that act on it and do the right thing in
> these various situations.
>
> On Sat, Sep 2, 2023 at 12:00 PM nop head <nop.head@gmail.com> wrote:
>
>> Well an OpenSCAD 2 vector has elements .x and .y and a 3 vector has
>> elements .x, .y and..z. If you are using them for something else then don't
>> add them with different lengths if it isn't appropriate.
>>
>> On Sat, 2 Sept 2023 at 16:51, Adrian Mariano <avm4@cornell.edu> wrote:
>>
>>> A 2-vector, meaning two numbers [a,b] can be a whole host of things. It
>>> is not necessarily "The XY plane embedded in 3-space at Z=0". That's only
>>> one possible meaning for a 2-vector. It could be a plane embedded
>>> somewhere else, a plane embedded with some kind of rotation or other
>>> transformation. A plane embedded into a curved surface in R^3, for
>>> example, points on the sphere (with one point missing via stereographic
>>> projection). It could be the two coefficients that define a line. It
>>> could be a point in the plane defined by polar coordinates. It could be
>>> the thickness and diameter of a part in my assembly. The minimum and
>>> maximum value of the y coordinate of a data set. It could be anything.
>>>
>>> When you say you KNOW how a 2-vector should behave in a 3d context what
>>> you're really saying is that you have made an ASSUMPTION about the meaning
>>> of the 2-vector and an ASSUMPTION about how to embed it into 3 space. It's
>>> not a truth or a fact. It's a choice. And there are other choices, which
>>> result in different outcomes.
>>>
>>>
>>>
>>> On Sat, Sep 2, 2023 at 10:47 AM nop head <nop.head@gmail.com> wrote:
>>>
>>>> While that is true for random missing variables the XY plane is
>>>> embedded in the XYZ space at Z = 0, so when the vectors are geometry I
>>>> think it is perfectly reasonable to notionally add a zero. In practice the
>>>> loop would probably just copy the remaining elements instead of
>>>> terminating early.
>>>>
>>>> On Sat, 2 Sept 2023 at 15:39, Steve Lelievre <
>>>> steve.lelievre.canada@gmail.com> wrote:
>>>>
>>>>>
>>>>> On 2023-09-02 5:25 a.m., Adrian Mariano wrote:
>>>>> > Why is addition of incompatible operands commutative? Since it's an
>>>>> > undefined, invalid operation, anything is possible.
>>>>>
>>>>> I'm with you on that.
>>>>>
>>>>> Anyway, my take on this whole discussion is that adding vector
>>>>> elements
>>>>> ought to behave in the same way as adding the corresponding ordinary
>>>>> variables. So for example, with 'stop at first warning' turned off,
>>>>> the code
>>>>>
>>>>> a = 1;
>>>>> c = a + b;
>>>>> echo(c);
>>>>>
>>>>> produces
>>>>>
>>>>> WARNING: Ignoring unknown variable 'b' in file , line 2
>>>>> WARNING: undefined operation (number + undefined) in file OpenSCAD,
>>>>> line 2
>>>>> ECHO: undef
>>>>>
>>>>> This behaviour implies that adding vectors of unequal lengths should
>>>>> result in undef for the trailing elements of the resulting vector.
>>>>> And,
>>>>> checking just now, I see that the documentation indicates undef as the
>>>>> outcome of adding elements of different types.
>>>>>
>>>>> If OpenSCAD is going to assume a value for a missing operand, that
>>>>> value
>>>>> really ought to be undef. In which case, it would calculate the
>>>>> resulting element as number + undef, which is undef.
>>>>>
>>>>> So to me, the current behaviour can almost be considered a bug -
>>>>> truncation with no warning, ouch!
>>>>>
>>>>> But using 0 for a missing operand isn't the best solution.
>>>>>
>>>>>
>>>>> My 2 cents,
>>>>>
>>>>> Steve
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>
JB
Jordan Brown
Sat, Sep 2, 2023 5:00 PM
On 9/2/2023 12:33 AM, Rogier Wolff wrote:
So the right decision would've been to do as nop head suggests: Keep
the extra coofdinate and allow the user to drop it if necessary.
Fortunately or unfortunately, the emphasis should be on "would've
been". That's not the way it is today, so compatibility is a strong
argument for not making a change that could yield silent bugs.
Now if one wants to say "the current behavior was not what I expected
and so I had a bug", then that would be a fine argument for making this
case be a warning, so that the users are pushed towards explicitly
requesting what they want.
On 9/2/2023 12:33 AM, Rogier Wolff wrote:
> So the right decision would've been to do as nop head suggests: Keep
> the extra coofdinate and allow the user to drop it if necessary.
Fortunately or unfortunately, the emphasis should be on "would've
been". That's not the way it is today, so compatibility is a strong
argument for *not* making a change that could yield silent bugs.
Now if one wants to say "the current behavior was not what I expected
and so I had a bug", then that would be a fine argument for making this
case be a warning, so that the users are pushed towards explicitly
requesting what they want.
RW
Rogier Wolff
Sat, Sep 2, 2023 5:58 PM
On Sat, Sep 02, 2023 at 11:50:49AM -0400, Adrian Mariano wrote:
A 2-vector, meaning two numbers [a,b] can be a whole host of things. It is
not necessarily "The XY plane embedded in 3-space at Z=0". That's only one
possible meaning for a 2-vector. It could be a plane embedded somewhere
else, a plane embedded with some kind of rotation or other transformation.
A plane embedded into a curved surface in R^3, for example, points on the
sphere (with one point missing via stereographic projection). It could be
the two coefficients that define a line. It could be a point in the plane
defined by polar coordinates. It could be the thickness and diameter of a
part in my assembly. The minimum and maximum value of the y coordinate of
a data set. It could be anything.
When you say you KNOW how a 2-vector should behave in a 3d context what
you're really saying is that you have made an ASSUMPTION about the meaning
of the 2-vector and an ASSUMPTION about how to embed it into 3 space. It's
not a truth or a fact. It's a choice. And there are other choices, which
result in different outcomes.
If that is your stance, then a 2-vector can NEVER be added to a
3-vector. Types are incompatible. You can never add a 3 volts to 5m/s
and you can never add different sized vectors or matrices.
Now in many programming languages, there is an automatic promotion to
the "bigger"(*) type. If I add 3 ta float, the (integer!) three gets
promoted to float and the operation proceeds with a float+float ->
float calculation.
When a user writes a program that adds a 2-vector to a 3-vector,
openscad should assume that "somehow" this is sensible for whatever
the 2-vector and 3-vector represent.
I'd say that it makes sense to "promote" the 2-vector to a 3-vector
and return a 3-vector result. If the user wants a 2-vector as a
result... fine with me. You can downgrade the result if you want.
IMHO the two options are to upgrade the 2-vector to 3-vector, or to
simply refuse to do the operation. Just make sure the dimensions are
right.
Roger.
(*) I wrote a little C program to demonstrate that bigger isn't always
better:
float c;
c = (1 << 24) - 10;
for (int i =0;i<20;i++) {
printf ("c = %.1f\n", c);
c = c + 1;
}
While that is true for random missing variables the XY plane is embedded
in the XYZ space at Z = 0, so when the vectors are geometry I think it is
perfectly reasonable to notionally add a zero. In practice the loop would
probably just copy the remaining elements instead of terminating early.
On Sat, 2 Sept 2023 at 15:39, Steve Lelievre <
steve.lelievre.canada@gmail.com> wrote:
On 2023-09-02 5:25 a.m., Adrian Mariano wrote:
Why is addition of incompatible operands commutative? Since it's an
undefined, invalid operation, anything is possible.
I'm with you on that.
Anyway, my take on this whole discussion is that adding vector elements
ought to behave in the same way as adding the corresponding ordinary
variables. So for example, with 'stop at first warning' turned off, the
code
a = 1;
c = a + b;
echo(c);
produces
WARNING: Ignoring unknown variable 'b' in file , line 2
WARNING: undefined operation (number + undefined) in file OpenSCAD, line 2
ECHO: undef
This behaviour implies that adding vectors of unequal lengths should
result in undef for the trailing elements of the resulting vector. And,
checking just now, I see that the documentation indicates undef as the
outcome of adding elements of different types.
If OpenSCAD is going to assume a value for a missing operand, that value
really ought to be undef. In which case, it would calculate the
resulting element as number + undef, which is undef.
So to me, the current behaviour can almost be considered a bug -
truncation with no warning, ouch!
But using 0 for a missing operand isn't the best solution.
My 2 cents,
Steve
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a is going up. -- Chris Hadfield about flying up the space shuttle.
On Sat, Sep 02, 2023 at 11:50:49AM -0400, Adrian Mariano wrote:
> A 2-vector, meaning two numbers [a,b] can be a whole host of things. It is
> not necessarily "The XY plane embedded in 3-space at Z=0". That's only one
> possible meaning for a 2-vector. It could be a plane embedded somewhere
> else, a plane embedded with some kind of rotation or other transformation.
> A plane embedded into a curved surface in R^3, for example, points on the
> sphere (with one point missing via stereographic projection). It could be
> the two coefficients that define a line. It could be a point in the plane
> defined by polar coordinates. It could be the thickness and diameter of a
> part in my assembly. The minimum and maximum value of the y coordinate of
> a data set. It could be anything.
>
> When you say you KNOW how a 2-vector should behave in a 3d context what
> you're really saying is that you have made an ASSUMPTION about the meaning
> of the 2-vector and an ASSUMPTION about how to embed it into 3 space. It's
> not a truth or a fact. It's a choice. And there are other choices, which
> result in different outcomes.
If that is your stance, then a 2-vector can NEVER be added to a
3-vector. Types are incompatible. You can never add a 3 volts to 5m/s
and you can never add different sized vectors or matrices.
Now in many programming languages, there is an automatic promotion to
the "bigger"(*) type. If I add 3 ta float, the (integer!) three gets
promoted to float and the operation proceeds with a float+float ->
float calculation.
When a user writes a program that adds a 2-vector to a 3-vector,
openscad should assume that "somehow" this is sensible for whatever
the 2-vector and 3-vector represent.
I'd say that it makes sense to "promote" the 2-vector to a 3-vector
and return a 3-vector result. If the user wants a 2-vector as a
result... fine with me. You can downgrade the result if you want.
IMHO the two options are to upgrade the 2-vector to 3-vector, or to
simply refuse to do the operation. Just make sure the dimensions are
right.
Roger.
(*) I wrote a little C program to demonstrate that bigger isn't always
better:
float c;
c = (1 << 24) - 10;
for (int i =0;i<20;i++) {
printf ("c = %.1f\n", c);
c = c + 1;
}
>
>
>
> On Sat, Sep 2, 2023 at 10:47 AM nop head <nop.head@gmail.com> wrote:
>
> > While that is true for random missing variables the XY plane is embedded
> > in the XYZ space at Z = 0, so when the vectors are geometry I think it is
> > perfectly reasonable to notionally add a zero. In practice the loop would
> > probably just copy the remaining elements instead of terminating early.
> >
> > On Sat, 2 Sept 2023 at 15:39, Steve Lelievre <
> > steve.lelievre.canada@gmail.com> wrote:
> >
> >>
> >> On 2023-09-02 5:25 a.m., Adrian Mariano wrote:
> >> > Why is addition of incompatible operands commutative? Since it's an
> >> > undefined, invalid operation, anything is possible.
> >>
> >> I'm with you on that.
> >>
> >> Anyway, my take on this whole discussion is that adding vector elements
> >> ought to behave in the same way as adding the corresponding ordinary
> >> variables. So for example, with 'stop at first warning' turned off, the
> >> code
> >>
> >> a = 1;
> >> c = a + b;
> >> echo(c);
> >>
> >> produces
> >>
> >> WARNING: Ignoring unknown variable 'b' in file , line 2
> >> WARNING: undefined operation (number + undefined) in file OpenSCAD, line 2
> >> ECHO: undef
> >>
> >> This behaviour implies that adding vectors of unequal lengths should
> >> result in undef for the trailing elements of the resulting vector. And,
> >> checking just now, I see that the documentation indicates undef as the
> >> outcome of adding elements of different types.
> >>
> >> If OpenSCAD is going to assume a value for a missing operand, that value
> >> really ought to be undef. In which case, it would calculate the
> >> resulting element as number + undef, which is undef.
> >>
> >> So to me, the current behaviour can almost be considered a bug -
> >> truncation with no warning, ouch!
> >>
> >> But using 0 for a missing operand isn't the best solution.
> >>
> >>
> >> My 2 cents,
> >>
> >> Steve
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> 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
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a is going up. -- Chris Hadfield about flying up the space shuttle.
CM
Curt McDowell
Sat, Sep 2, 2023 10:07 PM
Adding two differently shaped lists/vectors/arrays/matrixes is
nonsensical and is an error in all of the best software (Mathematica,
MATLAB, numpy, Sage, Wolfram Alpha, etc).
OpenSCAD should deprecate this by producing a warning, while continuing
to truncate. It already produces a warning & undef when multiplying (*)
wrongly shaped lists/vectors/arrays/matrixes.
On 9/2/23 10:58, Rogier Wolff wrote:
On Sat, Sep 02, 2023 at 11:50:49AM -0400, Adrian Mariano wrote:
A 2-vector, meaning two numbers [a,b] can be a whole host of things. It is
not necessarily "The XY plane embedded in 3-space at Z=0". That's only one
possible meaning for a 2-vector. It could be a plane embedded somewhere
else, a plane embedded with some kind of rotation or other transformation.
A plane embedded into a curved surface in R^3, for example, points on the
sphere (with one point missing via stereographic projection). It could be
the two coefficients that define a line. It could be a point in the plane
defined by polar coordinates. It could be the thickness and diameter of a
part in my assembly. The minimum and maximum value of the y coordinate of
a data set. It could be anything.
When you say you KNOW how a 2-vector should behave in a 3d context what
you're really saying is that you have made an ASSUMPTION about the meaning
of the 2-vector and an ASSUMPTION about how to embed it into 3 space. It's
not a truth or a fact. It's a choice. And there are other choices, which
result in different outcomes.
If that is your stance, then a 2-vector can NEVER be added to a
3-vector. Types are incompatible. You can never add a 3 volts to 5m/s
and you can never add different sized vectors or matrices.
Now in many programming languages, there is an automatic promotion to
the "bigger"(*) type. If I add 3 ta float, the (integer!) three gets
promoted to float and the operation proceeds with a float+float ->
float calculation.
When a user writes a program that adds a 2-vector to a 3-vector,
openscad should assume that "somehow" this is sensible for whatever
the 2-vector and 3-vector represent.
I'd say that it makes sense to "promote" the 2-vector to a 3-vector
and return a 3-vector result. If the user wants a 2-vector as a
result... fine with me. You can downgrade the result if you want.
IMHO the two options are to upgrade the 2-vector to 3-vector, or to
simply refuse to do the operation. Just make sure the dimensions are
right.
Roger.
(*) I wrote a little C program to demonstrate that bigger isn't always
better:
float c;
c = (1 << 24) - 10;
for (int i =0;i<20;i++) {
printf ("c = %.1f\n", c);
c = c + 1;
}
On Sat, Sep 2, 2023 at 10:47 AM nop head nop.head@gmail.com wrote:
While that is true for random missing variables the XY plane is embedded
in the XYZ space at Z = 0, so when the vectors are geometry I think it is
perfectly reasonable to notionally add a zero. In practice the loop would
probably just copy the remaining elements instead of terminating early.
On Sat, 2 Sept 2023 at 15:39, Steve Lelievre <
steve.lelievre.canada@gmail.com> wrote:
On 2023-09-02 5:25 a.m., Adrian Mariano wrote:
Why is addition of incompatible operands commutative? Since it's an
undefined, invalid operation, anything is possible.
I'm with you on that.
Anyway, my take on this whole discussion is that adding vector elements
ought to behave in the same way as adding the corresponding ordinary
variables. So for example, with 'stop at first warning' turned off, the
code
a = 1;
c = a + b;
echo(c);
produces
WARNING: Ignoring unknown variable 'b' in file , line 2
WARNING: undefined operation (number + undefined) in file OpenSCAD, line 2
ECHO: undef
This behaviour implies that adding vectors of unequal lengths should
result in undef for the trailing elements of the resulting vector. And,
checking just now, I see that the documentation indicates undef as the
outcome of adding elements of different types.
If OpenSCAD is going to assume a value for a missing operand, that value
really ought to be undef. In which case, it would calculate the
resulting element as number + undef, which is undef.
So to me, the current behaviour can almost be considered a bug -
truncation with no warning, ouch!
But using 0 for a missing operand isn't the best solution.
My 2 cents,
Steve
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 differently shaped lists/vectors/arrays/matrixes is
nonsensical and is an error in all of the best software (Mathematica,
MATLAB, numpy, Sage, Wolfram Alpha, etc).
OpenSCAD should deprecate this by producing a warning, while continuing
to truncate. It already produces a warning & undef when multiplying (*)
wrongly shaped lists/vectors/arrays/matrixes.
On 9/2/23 10:58, Rogier Wolff wrote:
> On Sat, Sep 02, 2023 at 11:50:49AM -0400, Adrian Mariano wrote:
>> A 2-vector, meaning two numbers [a,b] can be a whole host of things. It is
>> not necessarily "The XY plane embedded in 3-space at Z=0". That's only one
>> possible meaning for a 2-vector. It could be a plane embedded somewhere
>> else, a plane embedded with some kind of rotation or other transformation.
>> A plane embedded into a curved surface in R^3, for example, points on the
>> sphere (with one point missing via stereographic projection). It could be
>> the two coefficients that define a line. It could be a point in the plane
>> defined by polar coordinates. It could be the thickness and diameter of a
>> part in my assembly. The minimum and maximum value of the y coordinate of
>> a data set. It could be anything.
>>
>> When you say you KNOW how a 2-vector should behave in a 3d context what
>> you're really saying is that you have made an ASSUMPTION about the meaning
>> of the 2-vector and an ASSUMPTION about how to embed it into 3 space. It's
>> not a truth or a fact. It's a choice. And there are other choices, which
>> result in different outcomes.
> If that is your stance, then a 2-vector can NEVER be added to a
> 3-vector. Types are incompatible. You can never add a 3 volts to 5m/s
> and you can never add different sized vectors or matrices.
>
> Now in many programming languages, there is an automatic promotion to
> the "bigger"(*) type. If I add 3 ta float, the (integer!) three gets
> promoted to float and the operation proceeds with a float+float ->
> float calculation.
>
> When a user writes a program that adds a 2-vector to a 3-vector,
> openscad should assume that "somehow" this is sensible for whatever
> the 2-vector and 3-vector represent.
>
> I'd say that it makes sense to "promote" the 2-vector to a 3-vector
> and return a 3-vector result. If the user wants a 2-vector as a
> result... fine with me. You can downgrade the result if you want.
>
> IMHO the two options are to upgrade the 2-vector to 3-vector, or to
> simply refuse to do the operation. Just make sure the dimensions are
> right.
>
> Roger.
>
>
> (*) I wrote a little C program to demonstrate that bigger isn't always
> better:
>
> float c;
> c = (1 << 24) - 10;
> for (int i =0;i<20;i++) {
> printf ("c = %.1f\n", c);
> c = c + 1;
> }
>
>
>
>>
>>
>> On Sat, Sep 2, 2023 at 10:47 AM nop head <nop.head@gmail.com> wrote:
>>
>>> While that is true for random missing variables the XY plane is embedded
>>> in the XYZ space at Z = 0, so when the vectors are geometry I think it is
>>> perfectly reasonable to notionally add a zero. In practice the loop would
>>> probably just copy the remaining elements instead of terminating early.
>>>
>>> On Sat, 2 Sept 2023 at 15:39, Steve Lelievre <
>>> steve.lelievre.canada@gmail.com> wrote:
>>>
>>>> On 2023-09-02 5:25 a.m., Adrian Mariano wrote:
>>>>> Why is addition of incompatible operands commutative? Since it's an
>>>>> undefined, invalid operation, anything is possible.
>>>> I'm with you on that.
>>>>
>>>> Anyway, my take on this whole discussion is that adding vector elements
>>>> ought to behave in the same way as adding the corresponding ordinary
>>>> variables. So for example, with 'stop at first warning' turned off, the
>>>> code
>>>>
>>>> a = 1;
>>>> c = a + b;
>>>> echo(c);
>>>>
>>>> produces
>>>>
>>>> WARNING: Ignoring unknown variable 'b' in file , line 2
>>>> WARNING: undefined operation (number + undefined) in file OpenSCAD, line 2
>>>> ECHO: undef
>>>>
>>>> This behaviour implies that adding vectors of unequal lengths should
>>>> result in undef for the trailing elements of the resulting vector. And,
>>>> checking just now, I see that the documentation indicates undef as the
>>>> outcome of adding elements of different types.
>>>>
>>>> If OpenSCAD is going to assume a value for a missing operand, that value
>>>> really ought to be undef. In which case, it would calculate the
>>>> resulting element as number + undef, which is undef.
>>>>
>>>> So to me, the current behaviour can almost be considered a bug -
>>>> truncation with no warning, ouch!
>>>>
>>>> But using 0 for a missing operand isn't the best solution.
>>>>
>>>>
>>>> My 2 cents,
>>>>
>>>> Steve
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>
