------_extPart_001_01C6447F.25A1A520
Content-Type: text/plain;
	charsetso-8859-1"
Content-Transfer-Encoding: quoted-printable

>This is sort of wrong. Remember that in ruby, like java, most things
>are just pointers to objects. The only difference is Fixnums, Symbols,
>and the boolean primitives. When you assign a Fixnum, the value is
>encoded directly into the pointer. This saves everyone from having to
>have thousands of instances of the object which represents the number
>1.
>
>You want a reference object because when you assign a Fixnum as the
>element in the matrix, it gets stored directly in 2 pointers and
>therefore are unrelated.

I know that some things are stored directly in Ruby's VALUE object, but that is not the problem. The problem is that I cannot update a numeric object "in-place": a+=1 gets translated into a=a+1 and a+1 returns a NEW object and thus after executing a+=1, "a "is NOT the same object as before (it's object_id changed, it's a new object and I have todo synchronization to update the new state of "a" to all its equivalents all over the code). This is the case for Fixnum, but ALSO for Bignum and Float, which are NOT stored in VALUE directly. So the problem has nothing todo with immediates.

An Array, for instance, has some in-place update methods, like <<: a=[];p a.object_id;a<<1;p a.object_id will return two times the same object_id (the content of the object itself changed, but its reference stayed unaltered); this is nice since I don't have todo any synchronization operations if I had for example stored Arrays as the elements in my sparse matrix (instead of numbers), and updated these elements using only methods like <<, push, pop, ... (not += since that also returns a NEW object)

>To get around this, as you stated, you could make, say a Call class
>and store the call duration in an instance, and store the object the 2
>places in the Hash's (really just storing 2 references to the same
>object). Then when you update, say, information from the row, the
>information at the column is also updated. Thats how ruby works.
>
>Your statement about Ruby not being able to handle many different
>references to the same object is blatantly incorrect. What made you
>say it?

I must have failed to make myself clear. I do NOT mean two variables cannot refer to the same object. What I meant is exactly what I described above. If I have two variables (a and b) that initially refer to the same numerical object (be it Fixnum, Float or Bignum), Ruby provides me with NO methods to modify let's say "a", so that the modification will ALSO be reflected in "b" WITHOUT me having to synchronize "b" with "a" again. Ruby looses the initial fact that "a" and "b" referred to the same object because all numeric methods return new object and no method will allow me to modify a number "in-place". (correct me if I'm wrong)

>All in all, if you believe that you MUST use Fixnums only for memory
>reasons, then, as Caleb stated, maybe you should just wrap your C
>extension. All high level languages are going to give you the same
>trouble (actually others probably even more trouble) when it comes to
>how much memory is used to store an object.

I don't want to use Fixnums for memory reasons, in fact I have to use Floats. But I DO think it is too much overhead to have a class around each number (like the Call class you describe above), just to have an object representing a number AND allowing me to modify it in-place without creating a new object (unlike all standard numbers in Ruby do). This quickly becomes too much memory and speed overhead. In fact, I think the very reason Fixnums exist have a similar reason: Fixnums are VERY common and in general there exist a lot of them. Allocating and freeing separate memory spaces for them and dereferencing the pointers is overhead Matz tried to minimize, I don't see any other reason why there are two classes for representing integers. I will have a lot of elements in my matrix, each byte gained will differ a lot.

I know that high level languages are not very ideal to do these kind of things, I will also run into troubles with the garbage collector that suffers from have a lot of non-disposable objects it has to check, this is also why I created the C implementation, and I of course have wrapped it and made it usable in Ruby. I agree with the fact that once you passed a certain number of elements of the same type that that have to be stored, it is better to switch to a typed and compiled language, as untyped interpreted languages will have too much overhead.

But still, it would be nice to have a pure Ruby implementation (perhaps not as powerful, but still), for the sake of portability (no need to have a compiler and the Ruby sources), and the handy flexibility you have when objects are implemented in pure Ruby. Next to this, I encountered similar situation previously where I could have used Reference objects very well, and it absence forced me to write less elegant code to achieve e.g., parameter passing by reference etc. The more real-world tasks Ruby can handle out-of-the-box, the better. I refuse to view Ruby as a nice language todo rapid prototyping and having to switch to C or whatever to deal with big things. But some improvements seem necessary.

>I personally think you are just guessing that it will take up too much
>room in ruby and that if you try and write it and test it, you'll be
>pleasantly surprised.
>
> - Evan

I am not guessing anything, and once again, I am not trying to breakdown Ruby, I would like to use it for this too as I like Ruby a lot. I pushed Ruby to its limits and have run both into memory troubles and garbage collector issues when storing them. I know Ruby will never give the same performance as raw C since I even wrote a dedicated memory manager for working with these large matrices (even linux its memory manager has its memory and performance overhead when allocating millions of memory chunks). You can do the math and try to design an object the can store 100 million rows and columns, 800 million elements and allow fast access either from rows or columns. 16Gig of ram is easily consumed... 

But I think, with some modifications, Ruby can perform a lot better for this problem, become more valuable, more mature and solve an issue apparently other people also ran into. And what is probably more important, it will allow people to write more elegant code in a more natural way. If it is possible to solve this in a clean manner, I don't see what can be against it.

Greetings,
Geert.

------_extPart_001_01C6447F.25A1A520--