Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > Matrix

Reply
Thread Tools

Matrix

 
 
Michael Ulm
Guest
Posts: n/a
 
      09-12-2006
Paul Lutus wrote:

> Michael Ulm wrote:
>
> / ...
>
>
>>>I think the writers of the Matrix class realized this, and didn't bother
>>>to include an assignment operator on the ground that it wouldn't have any
>>>general utility.
>>>

>>
>>Then they would have been wrong. The lack of the []= operator has been a
>>major PITA for me, as I often need matrix functions (FWIW I'm a
>>mathematician, working on applications of artificial inteligence).
>>The implementations of many higher level matrix operations needs the
>>assignment operator. Try implementing a SVD algorithm without it.

>
>
> In Ruby, it's trivial to add it.
>


Granted, it is easy to add it. But the implementation is not the
problem; it's the small and subtle nuisances that are introduced when
you add a method to a standard class. You'd have to make sure to get
the syntax just right, you must ensure that every module that needs
is will get access to it without violating the DRY principle etc.

Maybe you are better organized and all these subtleties just come
natural to you. For me it's a pain.

Regards,

Michael

--
Michael Ulm
R&D Team
ISIS Information Systems Austria
tel: +43 2236 27551-219, fax: +43 2236 21081
e-mail: http://www.velocityreviews.com/forums/(E-Mail Removed)
Visit our Website: www.isis-papyrus.com

---------------------------------------------------------------
This e-mail is only intended for the recipient and not legally
binding. Unauthorised use, publication, reproduction or
disclosure of the content of this e-mail is not permitted.
This email has been checked for known viruses, but ISIS accepts
no responsibility for malicious or inappropriate content.
---------------------------------------------------------------

 
Reply With Quote
 
 
 
 
Michael Ulm
Guest
Posts: n/a
 
      09-12-2006
Dave Burt wrote:

> Michael Ulm wrote:
>
>>
>>I think he's trying to say, that there is no rational reason for
>>leaving out the []= operator, and I agree.

>
>
>
> The benefit is that you can assume no other code is modifying your matrix.
>
> n = Matrix.I(2)
> some_function(n)
> p n # same as before
>
> It's a good feature.


You are right, this is a somewhat useful feature (I've been bitten often
enough by mutated Arrays). However, this only works as long as some_function
is not a third party application (or calls a third party library).

So it's a balance of conveniences. For me, the usefulness of []= far
outweighs any advantages of the present implementation.

>
> []= would be useful, too, but I think to keep the immutability a better
> addition that provides the same functionality could be provided; a
> modified_at(x,y,value) method or something, but naming it is hard.
>


Then the whole Matrix would have to be copied to change one value --
goodbye performance.

Regards,

Michael

--
Michael Ulm
R&D Team
ISIS Information Systems Austria
tel: +43 2236 27551-219, fax: +43 2236 21081
e-mail: (E-Mail Removed)
Visit our Website: www.isis-papyrus.com

---------------------------------------------------------------
This e-mail is only intended for the recipient and not legally
binding. Unauthorised use, publication, reproduction or
disclosure of the content of this e-mail is not permitted.
This email has been checked for known viruses, but ISIS accepts
no responsibility for malicious or inappropriate content.
---------------------------------------------------------------

 
Reply With Quote
 
 
 
 
Dave Burt
Guest
Posts: n/a
 
      09-12-2006
William Crawford wrote:
> Dave Burt wrote:
>> If you want a matrix-like data structure (rather than a mathematical
>> matrix), why not use an array of arrays?

>
> Because then I'd have to write all the matrix functions to go along with
> them.


Or NMatrix then:

http://narray.rubyforge.org/

Cheers,
Dave
 
Reply With Quote
 
Verno Miller
Guest
Posts: n/a
 
      09-12-2006
Michael Ulm wrote:
> Dave Burt wrote:
>
>> n = Matrix.I(2)
>> some_function(n)
>> p n # same as before
>>
>> It's a good feature.

>
> You are right, this is a somewhat useful feature (I've been bitten often
> enough by mutated Arrays). However, this only works as long as
> some_function
> is not a third party application (or calls a third party library).
>
> So it's a balance of conveniences. For me, the usefulness of []= far
> outweighs any advantages of the present implementation.
>
>>
>> []= would be useful, too, but I think to keep the immutability a better
>> addition that provides the same functionality could be provided; a
>> modified_at(x,y,value) method or something, but naming it is hard.
>>

>
> Then the whole Matrix would have to be copied to change one value --
> goodbye performance.



How about using an alternative to subclassing (similar to the
"Alternative to inheriting from Array",
http://www.bigbold.com/snippets/posts/show/2573 )?


--
Posted via http://www.ruby-forum.com/.

 
Reply With Quote
 
Just Another Victim of the Ambient Morality
Guest
Posts: n/a
 
      09-12-2006

"Michael Ulm" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Just Another Victim of the Ambient Morality wrote:
>
>> "MonkeeSage" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed) ups.com...
>>
>>>Dave Burt wrote:
>>>
>>>>If you want a matrix-like data structure (rather than a mathematical
>>>>matrix), why not use an array of arrays?
>>>
>>>A mathematical matrix is just a dimensional arrangement of data into
>>>"rows" and "columns", thus allowing for certain algorithmic
>>>relationships to be defined and applied (e.g., canonical
>>>decompositions). Every matrix (i.e., the actual matrix considered as a
>>>complex value) is immutable and has a unique identity, just like every
>>>number -- that's true -- but they can also be permuted or otherwise
>>>transformed into different matrices. Why should one have to do that
>>>constructively (i.e., construct a new matrix "from scratch"), rather
>>>than destructively (i.e., change the existing matrix "in place"). Think
>>>of it like this: n = 1; n = n + 1 -- even though the number 1 is
>>>immutable and has a unique identity, the reference to it is not, and
>>>can thus be destructively altered by assignment with the result that it
>>>refers to new identity. It would be a pain to have to do o = n + 1, p =
>>>n + 2 (i.e., creating new references every time the data changes), just
>>>because 1 is immutable. Why should a matrix be any different? Mabye I'm
>>>missing something...

>>
>>
>> As far as I can tell, matrices are no different. Your example shows
>> that 1 is immutable but references to it can be re-assigned, so you can
>> do:
>>
>> n = 3
>> n = n + 1
>>
>>
>> Matrices are no different and, so, you can do:
>>
>>
>> n = Matrix.scalar(2, 3)
>> n = n + Matrix.I(2)
>>
>>
>> In both cases, the "number" types are immutable but the references
>> to them are not, as you say. They both work exactly the same way. What
>> are you trying to say?

>
> I think he's trying to say, that there is no rational reason for
> leaving out the []= operator, and I agree.


Well, yeah, I got that. It's just that he spent this whole paragraph
on a rationale that wasn't true so I was wondering what he was really
trying to get at for his rationale...



 
Reply With Quote
 
Just Another Victim of the Ambient Morality
Guest
Posts: n/a
 
      09-12-2006

"Michael Ulm" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Dave Burt wrote:
>
>> Michael Ulm wrote:
>>
>>>I think he's trying to say, that there is no rational reason for
>>>leaving out the []= operator, and I agree.

>>
>> The benefit is that you can assume no other code is modifying your
>> matrix.
>>
>> n = Matrix.I(2)
>> some_function(n)
>> p n # same as before
>>
>> It's a good feature.

>
> You are right, this is a somewhat useful feature (I've been bitten often
> enough by mutated Arrays). However, this only works as long as
> some_function
> is not a third party application (or calls a third party library).


Why do you think this? A method doesn't have to be third party to
modify the passed in object...


>> []= would be useful, too, but I think to keep the immutability a better
>> addition that provides the same functionality could be provided; a
>> modified_at(x,y,value) method or something, but naming it is hard.

>
> Then the whole Matrix would have to be copied to change one value --
> goodbye performance.


This is (apparently) true for all "number" types, including complex
numbers and matrices. Performance is not a priority. I suspect that
performance was never a priority in Ruby, either. The fact it is trivial
to add your own in-place modifier probably contributed to its obsence...



 
Reply With Quote
 
MonkeeSage
Guest
Posts: n/a
 
      09-12-2006
Just Another Victim of the Ambient Morality wrote:
> Well, yeah, I got that. It's just that he spent this whole paragraph
> on a rationale that wasn't true so I was wondering what he was really
> trying to get at for his rationale...


My rationale? Erm, the rationale stated by _others_ was that a matrix
(as a value) is immutable, therefore the implementation of a matrix (as
a data structure) should be immutable. But that makes no sense.

r ----------
| n0 n1 n2
| n3 n4 n5
| n6 n7 n8

What makes n0-n... special and different from just plain old n = 1?
Yes, r is a unit, but that just means that when n... is changed then r
is now a new value unit; you don't need to do that by constructing a
whole new matrix, you can do the same thing by changing members of r in
place. The _value_ of r at any given time is immutable, the data
structure that represents r need not be.

Given r:

r = [
[0, 1, 2],
[3, 4, 5],
[6, 7, 8]
]

Which is better?

def new_matrix(k, x, y, value)
out = []
k.each_with_index { |m, row|
out << []
m.each_with_index { |n, col|
if row == x and col == y
out[-1] << value
else
out[-1] << n
end
}
}
out
end
r = new_matrix(r, 2, 2, r[0][0])
r # => [[0, 1, 2], [3, 4, 5], [6, 7, 0]]

Or:

r[2][2] = r[0][0]
r # => [[0, 1, 2], [3, 4, 5], [6, 7, 0]]

Duh! The answer is obvious.

I do like Dave's idea about having a named method to do the in place
modification, though; that would make sure You Really Mean It and
eliminate the typo where you meant == but actually wrote =.

Ps. Paul gave another rationale: usefulness. That makes sense (though
its truth was contested). Dave also gave another rationale:
predictability. That makes sense too. But the immutability of the value
of a matrix as a rationale for disallowing destructive assignment to
members doesn't make sense.

 
Reply With Quote
 
Just Another Victim of the Ambient Morality
Guest
Posts: n/a
 
      09-12-2006

"MonkeeSage" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...
> Just Another Victim of the Ambient Morality wrote:
>> Well, yeah, I got that. It's just that he spent this whole
>> paragraph
>> on a rationale that wasn't true so I was wondering what he was really
>> trying to get at for his rationale...

>
> My rationale? Erm, the rationale stated by _others_ was that a matrix
> (as a value) is immutable, therefore the implementation of a matrix (as
> a data structure) should be immutable. But that makes no sense.


I think the rationale might be that the implementation of all "number"
types are immutable and matrices are a "number" type and should, therefore,
be immutable as well...


> r ----------
> | n0 n1 n2
> | n3 n4 n5
> | n6 n7 n8
>
> What makes n0-n... special and different from just plain old n = 1?
> Yes, r is a unit, but that just means that when n... is changed then r
> is now a new value unit; you don't need to do that by constructing a
> whole new matrix, you can do the same thing by changing members of r in
> place. The _value_ of r at any given time is immutable, the data
> structure that represents r need not be.


Okay, I think I'm beginning to see the distinction you're trying to
make between something "as a value" and "as a data structure." If I
understand you correctly, describing something as being "immutable" "as a
value" is meaningless. The term "immutable" only has meaning when you
apply it to an object (what you call a data structure).


> Given r:
>
> r = [
> [0, 1, 2],
> [3, 4, 5],
> [6, 7, 8]
> ]
>
> Which is better?
>
> def new_matrix(k, x, y, value)
> out = []
> k.each_with_index { |m, row|
> out << []
> m.each_with_index { |n, col|
> if row == x and col == y
> out[-1] << value
> else
> out[-1] << n
> end
> }
> }
> out
> end
> r = new_matrix(r, 2, 2, r[0][0])
> r # => [[0, 1, 2], [3, 4, 5], [6, 7, 0]]
>
> Or:
>
> r[2][2] = r[0][0]
> r # => [[0, 1, 2], [3, 4, 5], [6, 7, 0]]
>
> Duh! The answer is obvious.


So obvious that no one denies its utility. No one...


> Ps. Paul gave another rationale: usefulness. That makes sense (though
> its truth was contested). Dave also gave another rationale:
> predictability. That makes sense too. But the immutability of the value
> of a matrix as a rationale for disallowing destructive assignment to
> members doesn't make sense.


Again, you're using this weird distinction of value that doesn't seem
useful here. It's not just the value of 2 that's immutable, the object
itself is immutable. Matrices are the same...



 
Reply With Quote
 
MonkeeSage
Guest
Posts: n/a
 
      09-13-2006
Just Another Victim of the Ambient Morality wrote:
> Okay, I think I'm beginning to see the distinction you're trying to
> make between something "as a value" and "as a data structure." If I
> understand you correctly, describing something as being "immutable" "as a
> value" is meaningless. The term "immutable" only has meaning when you
> apply it to an object (what you call a data structure).


Ok, I was being ambiguous. I'm dumb though, so don't blame me. I was
using "immutable" in the sense of mathematical identity (like numbers
and constants are immutable, but variables aren't) -- r1 can never _be_
r2, just like 1 can never be 2. By "as a value" I was meaning any
particular matrix considered in this mathematical sense of identity.
And by "as a data structure" I was meaning the implementation of a
matrix "container" in ruby (apart from any specific matrices). So the
"value" of the "data structure" r is mathematically "immutable"; but
the "data structure" itself need not be immutable (in the programming
language sense of object mutability). Anyhow, as I said, I'm dense;
sorry for not being more clear. I shouldn't have eaten all that glue as
a child.

Regards,
Jordan

 
Reply With Quote
 
Rick DeNatale
Guest
Posts: n/a
 
      09-13-2006
On 9/12/06, MonkeeSage <(E-Mail Removed)> wrote:
> Rick DeNatale wrote:
> > Yes, you're missing the distinction between a variable which
> > references a sequence of objects over time, and the objects it
> > references.
> >
> > a = 1
> > a = 2
> >
> > Does NOT change 1 to 2.

>
> Hmm, I guess I wasn't clear, because that was my point (and another
> person also didn't understand me). My point was that n can be
> destructively altered by assignment, but its value (1) cannot be.


There is a very important distinction between variables and values,
that trips up a lot of programmers, and particularly programmers
coming to a uniformly object based language like Ruby.

I started a detailed reply here but it morphed into a blog article:
http://talklikeaduck.denhaven2.com/a...es-and-objects

I hope it helps someone.

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Matrix operations on character matrix element? Robert Kern Python 0 04-02-2009 12:27 AM
Re: Matrix operations on character matrix element? Terry Reedy Python 0 04-02-2009 12:12 AM
Matrix*Vector and Vector*Matrix Holgerson C++ 3 10-26-2007 07:38 AM
Matrix composed by two matrix lvcargnini VHDL 3 07-05-2006 07:21 AM
Re: Matrix DTS and Matrix 2 DTS? PeterTHX DVD Video 0 08-03-2003 05:46 AM



Advertisments