multmatrix expands the input matrix to 4x4?
I think the argument for tightening size requirements would be that
mathematically the size needs to be 4x4 and if it isn't it could be
intentional, or it could be programmer error, and by issuing a warning, you
may help the programmer avoid bugs.
The argument for the current behavior is that the programmer has the
convenience of specifying only what is needed, which may simplify the code
and make it more readable and maintainable.
nophead wrote
I think it should warn if you don't pass a vector of vectors, but other
than that, what is the point in tightening up the size requirements?
On Wed, 3 Jul 2019 at 22:24, adrianv <
avm4@
> wrote:
This sounds like pretty intentional behavior. Is there a prevailing (or
at
least common) belief that it's wrong and needs to change?
nophead wrote
The code
<
creates
a 4x4 identity matrix and then for each element it looks to see if the
corresponding element exists in the passed matrix and if it does it
overwrites that entry.
So basically it tries as hard as it can to convert any shape matrix to
fit.
Any element it can't find is left as the value from the identity. If
the
argument isn't even a matrix it silently uses the identity.
Discuss@.openscad
Discuss@.openscad
--
Sent from: http://forum.openscad.org/
Passing 3x3 makes sense if you only want to rotate, so some people might do
that. Similarly 2x2 for rotate around z. And the first three elements on
the last row are ignored anyway, so passing 3x4 also makes sense.
On Wed, 3 Jul 2019 at 22:47, adrianv avm4@cornell.edu wrote:
I think the argument for tightening size requirements would be that
mathematically the size needs to be 4x4 and if it isn't it could be
intentional, or it could be programmer error, and by issuing a warning, you
may help the programmer avoid bugs.
The argument for the current behavior is that the programmer has the
convenience of specifying only what is needed, which may simplify the code
and make it more readable and maintainable.
nophead wrote
I think it should warn if you don't pass a vector of vectors, but other
than that, what is the point in tightening up the size requirements?
On Wed, 3 Jul 2019 at 22:24, adrianv <
avm4@
> wrote:
This sounds like pretty intentional behavior. Is there a prevailing (or
at
least common) belief that it's wrong and needs to change?
nophead wrote
The code
<
;
creates
a 4x4 identity matrix and then for each element it looks to see if the
corresponding element exists in the passed matrix and if it does it
overwrites that entry.
So basically it tries as hard as it can to convert any shape matrix to
fit.
Any element it can't find is left as the value from the identity. If
the
argument isn't even a matrix it silently uses the identity.
Discuss@.openscad
Discuss@.openscad
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
You can defend use cases for a variety of options. If you want to rotate
around the x axis, for example, you could pass
[[],[0,cos(theta), sin(theta)], [0,-sin(theta),cos(theta)]]
It's not a huge advantage over passing [[1,0,0],...], though.
nophead wrote
Passing 3x3 makes sense if you only want to rotate, so some people might
do
that. Similarly 2x2 for rotate around z. And the first three elements on
the last row are ignored anyway, so passing 3x4 also makes sense.
On Wed, 3 Jul 2019 at 22:47, adrianv <
avm4@
> wrote:
I think the argument for tightening size requirements would be that
mathematically the size needs to be 4x4 and if it isn't it could be
intentional, or it could be programmer error, and by issuing a warning,
you
may help the programmer avoid bugs.
The argument for the current behavior is that the programmer has the
convenience of specifying only what is needed, which may simplify the
code
and make it more readable and maintainable.
nophead wrote
I think it should warn if you don't pass a vector of vectors, but other
than that, what is the point in tightening up the size requirements?
On Wed, 3 Jul 2019 at 22:24, adrianv <
avm4@
> wrote:
This sounds like pretty intentional behavior. Is there a prevailing
(or
at
least common) belief that it's wrong and needs to change?
nophead wrote
The code
<
;
creates
a 4x4 identity matrix and then for each element it looks to see if
the
corresponding element exists in the passed matrix and if it does it
overwrites that entry.
So basically it tries as hard as it can to convert any shape matrix
to
fit.
Any element it can't find is left as the value from the identity. If
the
argument isn't even a matrix it silently uses the identity.
Discuss@.openscad
Discuss@.openscad
Discuss@.openscad
Discuss@.openscad
--
Sent from: http://forum.openscad.org/
Almost 3 years ago I started a thread, appropriately called " Clarifying
behaviors http://forum.openscad.org/Clarifying-behaviors-td18492.html ",
with the following motivation:
I see three possible behaviors in the evaluation of an expression by
OpenSCAD: it does what is expected, it does something surprising but
reasonable and it does something unreasonable. The last one is clearly a
bug. The first one is the normal case. My interest now is on the second
case: a reasonable surprising behavior. It is surprising when it comprises
less common conditions that are not documented. Being undocumented make
them not eligible to be a feature and that is the issue.
I have submitted 3 "surprising" behaviors to be clarified in that thread.
Two of them were fully discussed and clarifying additions to the wiki were
made. The third issue were not discussed and were forgotten: exactly the
subject adrianv brought to light with this thread.
To approach what would be a reasonable behavior for multmatrix(), I have
made a comparison with what do other operators when their arguments have
incomplete lists. And I have found very disturbing results.
rotate([45]) cube(); // equivalent to rotate([45,0,0])
rotate([45,30]) cube(); // equivalent to rotate([45,30,0])
scale([2]) cube(); // WARNING: Unable to convert scale([2]) parameter to a
number, a vec3 or vec2 of numbers or a number
scale([2,3]) cube(); // equivalent to scale([2,3,1])
translate([2]) cube(); // WARNING: Unable to convert translate([2])
parameter to a vec3 or vec2 of numbers
translate([2,3]) cube(); // equivalent to translate([2,3,0])
As scale() and translate() are used for both 2D and 3D objects, they accept
2D or 3D vectors and nothing else as parameter. But rotate(), which is also
used for 2D objects, behaves in a form similar to multmatrix(), fulfilling
the missing parameter components with 0. However, rotate is not as
complacent as multmatrix when the parameter has dimension greater than 3:
rotate([0,30,0,20]) cube(); // WARNING: Problem converting rotate(a=[0, 30,
0, 20]) parameter
I don't think that multitude of behaviors may be accepted as reasonable.
Some coherence is demanded here. Either all those operators require proper
dimensions for their parameters or they should have a consistent behavior
for incomplete parameters.
In special, I don't like the ad hoc preview display of 2D objects (not
abided by render) when some operator bring them out of the XY plane like in
rotate([0,30,0]) square();
But this is another discussion.
Finally, I should mention a donbright comment
http://forum.openscad.org/Clarifying-behaviors-tp18492p18507.html in my
previous referred thread:
In my experience the "de facto" language spec is in the several hundred
regression tests.
So, clarifications in the wiki may help the users but it is the inclusion of
new tests in the regression test list that will ensure a given behavior will
be considered valid and be preserved in future versions.
--
Sent from: http://forum.openscad.org/
Rotate isn't the same as scale and translate. When operating on 2D objects
you only rotate around Z and that is catered for with rotate(45) which is
the same as rotate(45, [0, 0, 1]).
So there isn't as good a case for rotate taking a 2 vector. I think it
should be a 3 vector if it is passed a vector but then if you do that you
would say multmatrix should only take perhaps three or four 4 vectors.
I agree it is inconsistent but I don't see it as a big problem as it isn't
totally surprising and I don't find it hiding bugs. If you find something
is not rotating around say Z you look to see what you passed in the third
element and if you have only passed two you would see that.
On Thu, 4 Jul 2019 at 01:30, Ronaldo rcmpersiano@gmail.com wrote:
Almost 3 years ago I started a thread, appropriately called " Clarifying
behaviors http://forum.openscad.org/Clarifying-behaviors-td18492.html
",
with the following motivation:
I see three possible behaviors in the evaluation of an expression by
OpenSCAD: it does what is expected, it does something surprising but
reasonable and it does something unreasonable. The last one is clearly a
bug. The first one is the normal case. My interest now is on the second
case: a reasonable surprising behavior. It is surprising when it
comprises
less common conditions that are not documented. Being undocumented make
them not eligible to be a feature and that is the issue.
I have submitted 3 "surprising" behaviors to be clarified in that thread.
Two of them were fully discussed and clarifying additions to the wiki were
made. The third issue were not discussed and were forgotten: exactly the
subject adrianv brought to light with this thread.
To approach what would be a reasonable behavior for multmatrix(), I have
made a comparison with what do other operators when their arguments have
incomplete lists. And I have found very disturbing results.
rotate([45]) cube(); // equivalent to rotate([45,0,0])
rotate([45,30]) cube(); // equivalent to rotate([45,30,0])
scale([2]) cube(); // WARNING: Unable to convert scale([2]) parameter to a
number, a vec3 or vec2 of numbers or a number
scale([2,3]) cube(); // equivalent to scale([2,3,1])
translate([2]) cube(); // WARNING: Unable to convert translate([2])
parameter to a vec3 or vec2 of numbers
translate([2,3]) cube(); // equivalent to translate([2,3,0])
As scale() and translate() are used for both 2D and 3D objects, they accept
2D or 3D vectors and nothing else as parameter. But rotate(), which is also
used for 2D objects, behaves in a form similar to multmatrix(), fulfilling
the missing parameter components with 0. However, rotate is not as
complacent as multmatrix when the parameter has dimension greater than 3:
rotate([0,30,0,20]) cube(); // WARNING: Problem converting rotate(a=[0, 30,
0, 20]) parameter
I don't think that multitude of behaviors may be accepted as reasonable.
Some coherence is demanded here. Either all those operators require proper
dimensions for their parameters or they should have a consistent behavior
for incomplete parameters.
In special, I don't like the ad hoc preview display of 2D objects (not
abided by render) when some operator bring them out of the XY plane like
in
rotate([0,30,0]) square();
But this is another discussion.
Finally, I should mention a donbright comment
http://forum.openscad.org/Clarifying-behaviors-tp18492p18507.html in
my
previous referred thread:
In my experience the "de facto" language spec is in the several hundred
regression tests.
So, clarifications in the wiki may help the users but it is the inclusion
of
new tests in the regression test list that will ensure a given behavior
will
be considered valid and be preserved in future versions.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org