From: Geert Fannes <Geert.Fannes@...>
Date: 2006-03-14T04:26:18+09:00
Subject: Re: how to introduce reference objects into ruby

------_=_NextPart_001_01C646D3.F69A47F8
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

>I think you are saying that the rows of your matrix contain the value,=20
>and the columns contain references (either pointers or indices) to the=20
>row values.  Is that correct (modulo having rows/columns reversed)?
>
>I'm still unclear why this solution wouldn't work in Ruby.

I could indeed store all the elements in a Hash of Hashes (the columns). =
I can then store the rows as a Hash of Arrays and lookup each row =
element in the columns:

def getRow(i)
  row=3D@rows[i].collect{|j|@columns[j][i]}
end

On the aesthetic side, this is an assymetric solution, but that is also =
the case in my C implementation.

On the practical side, this needs much more Hash lookups than if we had =
the needed values also in the Hash of Hashes for the rows.

To implement something that has the same complexity as the C =
implementation, I would need to store the columns as a Hash of Hashes =
with instead of a Float value, an index into a large Array that would =
contain ALL the matrix elements. The rows can then similarily be stored =
as a Hash of Hashes of indices into the very same Array. Now everything =
is symmetric and adequately fast, but I still believe things would be =
more elegant with a Reference object. Especially when you start deleting =
elements: deleting them from the Hash of Hashes is no problem, but =
removing them from the Array is less efficient. The C counterpart that =
handles deleting and adding from and to this Array is the kernel its =
memory manager, which is more suitable for this than Ruby's Array =
object, but has also it's overhead. For this reason, I have two =
implementations in C. One that uses regular pointers and AVL balanced =
trees (similar to the Hash object) suffers from linux it's memory =
manager. The other implementation uses that approach with a common array =
as explained above, but has therefore the same problems with deletion of =
elements.

Greetings,
Geert.

------_=_NextPart_001_01C646D3.F69A47F8--