multmatrix expands the input matrix to 4x4?

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

multmatrix expands the input matrix to 4x4?

adrianv
What is the actual behavior of multmatrix()?  

It appears that I can supply M, a list of lists such that the rows, M[i],
can be a list of any length, even zero.  If len(M[i])<4 then M[i] is
expanded to have length 4.  If len(M[i])>4 then the extra values are
ignored.  Furthermore, len(M) can be anything.  Unspecified values are
filled in to create an identity matrix, and extra ones are ignored.  So for
example, multmatrix([[3]]) will scale in the x direction by 3.  

Is this a correct interpretation?    Assuming I can rely on this behavior, I
can simplify code by not explicitly transforming 3x3 matrices into 4x4 ones.  




--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3
Reply | Threaded
Open this post in threaded view
|

Re: multmatrix expands the input matrix to 4x4?

tp3
On 02.07.19 18:52, adrianv wrote:
> Assuming I can rely on this behavior,

No, you can't. Well nobody can force you to stop poking
holes in places that are not clearly defined, there's
definitely lots of those. But you have to keep the pieces
when it breaks ;-).

ciao,
  Torsten.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: multmatrix expands the input matrix to 4x4?

adrianv
What can I rely on?  From what I can tell, the manual isn't necessarily
definitive, being rather a collection of the community's description of the
behavior of the code as opposed to being a specification.   Is this behavior
accidental?  Subject to change?  Likely to change?    Is it on a list as a
bug to fix somewhere?  

Why do you call it "poking holes"?  It's what OpenSCAD does.  It's not
"wrong", but it is undocumented.  I see it as uncovering shortcomings in the
manual, not problems with OpenSCAD.  I was prompted to investigate this
because somebody posted a while back that you could pass a 3x4 matrix to
multmatrix, so there is undoubtedly code relying on *that* behavior, at
least, already out there.  



--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3
Reply | Threaded
Open this post in threaded view
|

Re: multmatrix expands the input matrix to 4x4?

tp3
On 02.07.19 20:09, adrianv wrote:
> Why do you call it "poking holes"?  It's what OpenSCAD does.

Yes, and that's what I meant. Things are not clearly specified
so there are lots of undefined places. The first tiny steps for
reducing that are the latest improvements implementing warnings
for a number of those cases.

So I guess there's 2 options:

1) Define all the holes as feature and basically make it impossible
to change the OpenSCAD language.

2) Slowly move to a clearer specification by improving both code
and documentation.

I hope we will end up with the 2nd option, and I hope people will
help going into that direction.

ciao,
  Torsten.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: multmatrix expands the input matrix to 4x4?

adrianv
tp3 wrote
> On 02.07.19 20:09, adrianv wrote:
>> Why do you call it "poking holes"?  It's what OpenSCAD does.
>
> Yes, and that's what I meant. Things are not clearly specified
> so there are lots of undefined places. The first tiny steps for
> reducing that are the latest improvements implementing warnings
> for a number of those cases.

So what should the behavior be for multmatrix()?  It should be an error to
pass a matrix not exactly 4x4?  One could argue that being able to pass 3x3
is not unreasonable.   I tend to think that excess data should be an error,
e..g passing a 5x5 shouldn't be accepted, but it's not obvious that the
current behavior is otherwise bad.  Is there harm in alllowing a matrix
subset?  (If I were to pick a place where I thought we would get significant
benefit from the efforts of an OpenSCAD programming, I certainly wouldn't
point to this issue.)  

What's the bottom line for the "approved" ways to use multmatrix()?


> So I guess there's 2 options:
>
> 1) Define all the holes as feature and basically make it impossible
> to change the OpenSCAD language.
>
> 2) Slowly move to a clearer specification by improving both code
> and documentation.
>
> I hope we will end up with the 2nd option, and I hope people will
> help going into that direction.

I don't have a feeling like OpenSCAD is really moving anywhere, like I
should have an expectation that it will improve.  The fact that 4 years
passed between releases suggests a pretty conservative approach, without
much change.   It seems like  suggestions of changes are met with the
response that those who could execute such changes lack the time or
inclination to do so (and that it's unreasonable to request changes because
it's a volunteer effort.)  So it's really not apparent how someone (who is
not prepared to write code for OpenSCAD itself) could help improve matters
in the core language.  

Here's another observation: if behavior is not documented then perhaps it
decreases the likelihood of code relying on that behavior, but also it's
difficult for people to observe that the behavior is bad, since it's secret.  
It seems unlikely to get "fixed".   Perhaps behavior deemed bad should be
documented as "quirks" or something like that, with the indication that
quirk behavior may change in the future, and code should avoid relying on
it.   Or does someone already have a list of these sorts of concerns?




--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: multmatrix expands the input matrix to 4x4?

boxcarmib


> On Jul 2, 2019, at 8:19 PM, adrianv <[hidden email]> wrote:
>



> I don't have a feeling like OpenSCAD is really moving anywhere, like I
> should have an expectation that it will improve.  The fact that 4 years
> passed between releases suggests a pretty conservative approach, without
> much change.   It seems like  suggestions of changes are met with the
> response that those who could execute such changes lack the time or
> inclination to do so (and that it's unreasonable to request changes because
> it's a volunteer effort.)  So it's really not apparent how someone (who is
> not prepared to write code for OpenSCAD itself) could help improve matters
> in the core language.  

I neither have the time nor intellect to write code for OpenSCAD, but I sure appreciate the effort
that has gone into it.

I have a friend who does a lot of volunteer shareware software development. His programs get downloaded about 20K
a month, but in the 12 years he’s been doing it, he’s gotten about $200 in total whereas on the other hand the request
for new features or complaints about how his programs don’t do one thing or another are endless. I know for a fact he’s pretty
pleased when he gets that very infrequent email of thanks and/or praise.
So for part I try to let the developers know how much I appreciate the time and effort they put into this project.

I know OpenSCAD isn’t perfect, and I’m pretty sure the developers are even more aware of its imperfections than I am, but
for a variety of reasons OpenSCAD is my development environment of choice and I’d hate to see it wither and die.

Secondly… there’s cash. :) To show my support I make a (currently very modest) monthly donation to OpenSCAD which
I hope to increase as my own resources permit. I’ve spent far more on a 3D printer than I’ve spent using the program that
I consider indispensable to creating object to print on it… I don’t think that’s quite right.

Thirdly, there’s bounties and I know if I’m really serious about an extension or feature, I could offer a reward. I note that some
feature requests with a bounty will sometimes even see others joining in to up the ante and make it even more
worthwhile for someone with the knowledge and expertise to actually do the work. Granted most of the bounties offered
seem to be in the < $50 range… but I wonder how excited one of the developers might be If one were to offer something like
$200, $500 or $1000 for something to be implemented.
Something at that level might be out of my range, but I’ve been toying with the idea of offering a bounty that would serve
as a serious thank you for the time and effort it would take for a feature I’d very much like to see.

>
> Here's another observation: if behavior is not documented then perhaps it
> decreases the likelihood of code relying on that behavior, but also it's
> difficult for people to observe that the behavior is bad, since it's secret.  
> It seems unlikely to get "fixed".   Perhaps behavior deemed bad should be
> documented as "quirks" or something like that, with the indication that
> quirk behavior may change in the future, and code should avoid relying on
> it.   Or does someone already have a list of these sorts of concerns?
>
>
>
>
> --
> Sent from: http://forum.openscad.org/
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: multmatrix expands the input matrix to 4x4?

adrianv
boxcarmib wrote
> I have a friend who does a lot of volunteer shareware software
> development. His programs get downloaded about 20K
> a month, but in the 12 years he’s been doing it, he’s gotten about $200 in
> total whereas on the other hand the request
> for new features or complaints about how his programs don’t do one thing
> or another are endless. I know for a fact he’s pretty
> pleased when he gets that very infrequent email of thanks and/or praise.
> So for part I try to let the developers know how much I appreciate the
> time and effort they put into this project.

The project I wrote and and have supported for the last 23 years is on most
or all linux computers and also (in a very early version) on all mac
computers.  It's kind of hard to tell how many users there are.  I've gotten
exactly $0 from my efforts.   On doesn't undertake volunteer work with the
expectation of getting money out of it.  


> Secondly… there’s cash. :) To show my support I make a (currently very
> modest) monthly donation to OpenSCAD which
> I hope to increase as my own resources permit. I’ve spent far more on a 3D
> printer than I’ve spent using the program that
> I consider indispensable to creating object to print on it… I don’t think
> that’s quite right.
>
> Thirdly, there’s bounties and I know if I’m really serious about an
> extension or feature, I could offer a reward. I note that some
> feature requests with a bounty will sometimes even see others joining in
> to up the ante and make it even more
> worthwhile for someone with the knowledge and expertise to actually do the
> work. Granted most of the bounties offered
> seem to be in the < $50 range… but I wonder how excited one of the
> developers might be If one were to offer something like
> $200, $500 or $1000 for something to be implemented.
> Something at that level might be out of my range, but I’ve been toying
> with the idea of offering a bounty that would serve
> as a serious thank you for the time and effort it would take for a feature
> I’d very much like to see.

I have no idea how this sort of cash award affects developers.  I mean, if
the developers have day jobs then offering $50 for a feature that takes ten
hours of work is sort of insulting, since it means $5/hour.   There are
studies done about how offering money for things can shift perception and
behavior as it moves the behavior from a friend interaction to an economic
one.  (Do you offer your friend money to help move a piece of furniture?)  
Of course, if a developer does not have a paying job perhaps getting $50 is
a big draw.   And I wouldn't suggest that people don't offer money if they
choose.  But ultimately, working on a project like mine, or like OpenSCAD is
volunteer work, and one must choose to do it for the interest, enjoyment,
and/or feeling of making a contribution to the community.

In the case of OpenSCAD, there's no roadmap that I've seen describing which
features the developers are interested in actually implementing.  In my
experience, if I have an idea of how the program might be improved and I
suggest it first it's met with a kind of hostile reaction about how I
shouldn't expect anything, and secondly, it's already been suggested many
times by others.  I found what seemed to me to be a major bug and discovered
it was already reported and had been open for years.  So all of this makes
it seem like change is unlikely.   This is an observation, not a criticism
of the developers.  And it doesn't make a whole lot of sense to wait around
for the 2023 release.  

That's why the question is: what does OpenSCAD do now, so I can use it best?  
How does multmatrix() work?  How are we supposed to use it?  I didn't start
this discussion to be a debate about OpenSCAD development, but rather to
figure out how I can and should use multmatrix().   And also possibly I
thought I might improve the manual to better describe how multmatrix()
works, since that's something I *can* do to help others.  But it looks like
maybe this effort is also not appreciated, or is controversial---the
response that seems to arise for all efforts to help the OpenSCAD project.
So I guess I won't bother.  It's pretty hard to make a contribution.  







--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: multmatrix expands the input matrix to 4x4?

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

On Wed, 3 Jul 2019 at 13:15, adrianv <[hidden email]> wrote:
boxcarmib wrote
> I have a friend who does a lot of volunteer shareware software
> development. His programs get downloaded about 20K
> a month, but in the 12 years he’s been doing it, he’s gotten about $200 in
> total whereas on the other hand the request
> for new features or complaints about how his programs don’t do one thing
> or another are endless. I know for a fact he’s pretty
> pleased when he gets that very infrequent email of thanks and/or praise.
> So for part I try to let the developers know how much I appreciate the
> time and effort they put into this project.

The project I wrote and and have supported for the last 23 years is on most
or all linux computers and also (in a very early version) on all mac
computers.  It's kind of hard to tell how many users there are.  I've gotten
exactly $0 from my efforts.   On doesn't undertake volunteer work with the
expectation of getting money out of it. 


> Secondly… there’s cash. :) To show my support I make a (currently very
> modest) monthly donation to OpenSCAD which
> I hope to increase as my own resources permit. I’ve spent far more on a 3D
> printer than I’ve spent using the program that
> I consider indispensable to creating object to print on it… I don’t think
> that’s quite right.
>
> Thirdly, there’s bounties and I know if I’m really serious about an
> extension or feature, I could offer a reward. I note that some
> feature requests with a bounty will sometimes even see others joining in
> to up the ante and make it even more
> worthwhile for someone with the knowledge and expertise to actually do the
> work. Granted most of the bounties offered
> seem to be in the < $50 range… but I wonder how excited one of the
> developers might be If one were to offer something like
> $200, $500 or $1000 for something to be implemented.
> Something at that level might be out of my range, but I’ve been toying
> with the idea of offering a bounty that would serve
> as a serious thank you for the time and effort it would take for a feature
> I’d very much like to see.

I have no idea how this sort of cash award affects developers.  I mean, if
the developers have day jobs then offering $50 for a feature that takes ten
hours of work is sort of insulting, since it means $5/hour.   There are
studies done about how offering money for things can shift perception and
behavior as it moves the behavior from a friend interaction to an economic
one.  (Do you offer your friend money to help move a piece of furniture?) 
Of course, if a developer does not have a paying job perhaps getting $50 is
a big draw.   And I wouldn't suggest that people don't offer money if they
choose.  But ultimately, working on a project like mine, or like OpenSCAD is
volunteer work, and one must choose to do it for the interest, enjoyment,
and/or feeling of making a contribution to the community.

In the case of OpenSCAD, there's no roadmap that I've seen describing which
features the developers are interested in actually implementing.  In my
experience, if I have an idea of how the program might be improved and I
suggest it first it's met with a kind of hostile reaction about how I
shouldn't expect anything, and secondly, it's already been suggested many
times by others.  I found what seemed to me to be a major bug and discovered
it was already reported and had been open for years.  So all of this makes
it seem like change is unlikely.   This is an observation, not a criticism
of the developers.  And it doesn't make a whole lot of sense to wait around
for the 2023 release. 

That's why the question is: what does OpenSCAD do now, so I can use it best? 
How does multmatrix() work?  How are we supposed to use it?  I didn't start
this discussion to be a debate about OpenSCAD development, but rather to
figure out how I can and should use multmatrix().   And also possibly I
thought I might improve the manual to better describe how multmatrix()
works, since that's something I *can* do to help others.  But it looks like
maybe this effort is also not appreciated, or is controversial---the
response that seems to arise for all efforts to help the OpenSCAD project.
So I guess I won't bother.  It's pretty hard to make a contribution. 







--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: multmatrix expands the input matrix to 4x4?

adrianv
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
> &lt;https://github.com/openscad/openscad/blob/69bf5a55475102be43c2ddc698198e85821332b3/src/transform.cc#L204&gt;
> 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.





--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: multmatrix expands the input matrix to 4x4?

nophead
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 <[hidden email]> 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
> &lt;https://github.com/openscad/openscad/blob/69bf5a55475102be43c2ddc698198e85821332b3/src/transform.cc#L204&gt;
> 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.





--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: multmatrix expands the input matrix to 4x4?

adrianv
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 &lt;

> avm4@

> &gt; 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
>> > &lt;
>> https://github.com/openscad/openscad/blob/69bf5a55475102be43c2ddc698198e85821332b3/src/transform.cc#L204&gt
>> ;
>> > 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.
>>
>>
>>
>>
>>
>> --
>> Sent from: http://forum.openscad.org/
>>
>> _______________________________________________
>> OpenSCAD mailing list
>>

> Discuss@.openscad

>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>
> _______________________________________________
> OpenSCAD mailing list

> Discuss@.openscad

> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org





--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: multmatrix expands the input matrix to 4x4?

nophead
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 <[hidden email]> 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 &lt;

> avm4@

> &gt; 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
>> > &lt;
>> https://github.com/openscad/openscad/blob/69bf5a55475102be43c2ddc698198e85821332b3/src/transform.cc#L204&gt
>> ;
>> > 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.
>>
>>
>>
>>
>>
>> --
>> Sent from: http://forum.openscad.org/
>>
>> _______________________________________________
>> OpenSCAD mailing list
>>

> Discuss@.openscad

>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>
> _______________________________________________
> OpenSCAD mailing list

> Discuss@.openscad

> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org





--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: multmatrix expands the input matrix to 4x4?

adrianv
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 &lt;

> avm4@

> &gt; 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 &lt;
>>
>> > avm4@
>>
>> > &gt; 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
>> >> > &lt;
>> >>
>> https://github.com/openscad/openscad/blob/69bf5a55475102be43c2ddc698198e85821332b3/src/transform.cc#L204&gt
>> >> ;
>> >> > 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.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Sent from: http://forum.openscad.org/
>> >>
>> >> _______________________________________________
>> >> OpenSCAD mailing list
>> >>
>>
>> > Discuss@.openscad
>>
>> >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>> >>
>> >
>> > _______________________________________________
>> > OpenSCAD mailing list
>>
>> > Discuss@.openscad
>>
>> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>>
>>
>>
>>
>> --
>> Sent from: http://forum.openscad.org/
>>
>> _______________________________________________
>> OpenSCAD mailing list
>>

> Discuss@.openscad

>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>
> _______________________________________________
> OpenSCAD mailing list

> Discuss@.openscad

> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org





--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: multmatrix expands the input matrix to 4x4?

Ronaldo
In reply to this post by adrianv
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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: multmatrix expands the input matrix to 4x4?

nophead
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 <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org