Grasshopper

algorithmic modeling for Rhino

Matrix addition/subtraction component in math tab returns error

"1. Only similar types of data can be added together" allthough both are matrices and both have the same dimensions?! (for example two unit matrices from the order of 3x3 dimension - double checked them with the component of "view matrix")) does anybody know why?

Views: 204

Attachments:

Reply to This

Replies to This Discussion

Addition doesn't handle matrices at all, I'll see what it would take to implement it. Although I seem to remember that addition of matrices in general is somewhat undefined.

It would be quite a problem adding it to the existing algorithm, because the existing algorithm is designed in a really stupid way. But it would probably be a good idea for me to come up with a different approach because that will be needed anyway for GH2.

Hi David, thanks for the swift reply. As I recall from my Linear Algebra studies addition or subtraction of matrices from identical dimensions is fully defined and straight forward: every item (matrix part) is added/subtracted from its counterpart item - the result is a matrix from the same order with differnt item values. unless item a from Matrix A with index m,n is 0 and item b from Matrix B with index m,n is 0 = item c from Matrix C with index m,n is also 0.

I think the level of accessabilty and involvment of mcneel with its software users and testers is unprecednted and woderful - keep up with great job you do :-)

My new approach seems to be working, so before too long I hope to have matrices work for addition, mass-addition, subtraction, multiplication and maybe even division.

Thats great to hear! looking forward to see this. Have a nice weekend

Do you want to implement those as per-matrix-element operator ? This can become confusing, especially with multiplication... also, matrix division doesn't exist which makes it even worse.

Yes I meant as matrix operator: actualy addition and subtraction are both together depnding on the elements signs (part or all of the elements are added and part or all of the elements are subtracted. dimension of matrices must be identical) and division is the same as multiplication (dimension must be in the order of A(mxn)*\/B(nxk) where n is the common dimension): to divide one element by another you just multiply it by 1/value (part or all of the elements can multiply while part or all of the elements divide):

so for example matrix addition of matrices A(2x2): {2,-1}{1,2} and B(2,2): {3,-5}{4,-2} will result in matrix C(2x2):{5,-6}{5,0}. subtraction of those matrices will result in D(2x2): {-1,4}{-3,4}

Division of matrices A(2x2): {2,0.5}{2,4} and B(2x1) :{2}{2} will result in matrix C(2x1): {1+0.25}{1+2}={1.25,3}. Multiplication of those matrices will result in D(2x1):{4+1}{4+8}={5,12}.

Yes, I've implemented it as entry-wise sum. There's other kinds of matrix addition, but they seem too exotic to make the default behaviour.

also, matrix division doesn't exist which makes it even worse.

There's various operations that are already different between addition and multiplication. Sometimes an operation makes sense on some data types, sometimes it doesn't. I'm aiming to support all those that do. On the other hand, if scalar division (A/B) equals (A * B^-1), then why wouldn't matrix division be A*B^-1, i.e. matrix multiplication with the inverse of the second operand?

While I agree with you guys over multiplication, addition and subtraction, I think division as you're proposing is a bit convoluted. I don't think that in general replacing one operator "/" with "* ^-1" is a good coding practice. Not sure if "a good coding practice" is a valid argument... 

EDIT: 

Two cases possible: 

1. Majority of people assume "/" is "* ^-1"... everything is fine and everybody is happy about it.

2. Majority of people assume "/" means matrix division is possible, who knows what does it result with... 

I think it would be silly to talk of a 'majority of people' considering there will probably be about seven (eleven at the utmost) people who will ever want to do arithmetic on matrices :)

But you're right of course, some of these operations are not at all standard and not at all predictable or memorable. When this new approach is transferred to GH2, I think I'd very much like to add some system of warnings which tells you when a particular arithmetic operation is pretty darn exotic, say matrix/matrix, or colour*vector, or point-boolean.

I want to provide as rich a feature set as possible, but we must be careful to help users avoid pitfalls that make the program behave in frustratingly obscure ways.

Good news is that this seems to be a very similar problem to automatic data conversion issues, which I have already written. In GH2 data conversion is not a binary success/failure operation any more, conversions fall on a sliding scale from 'direct', via 'straightforward', to 'reasonable', stopping briefly at 'exotic' eventually to end up in 'farfetched'. Furthermore the user will be able to specify what level triggers warnings, so that expert users can use weird conversions without getting confronted with visual clutter whilst teachers can insist on a low threshold.

I'm excited about GH2. You guys are close to releasing right? ;)

RSS

Translate

Search Grasshopper

Photos

  • Add Photos
  • View All

© 2017   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service