From: Geert Fannes Date: 2006-03-11T05:14:08+09:00 Subject: Re: how to introduce reference objects into ruby ------_=_NextPart_001_01C6447F.25A1A520 Content-Type: text/plain; charset="iso-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+=3D1 gets translated into a=3Da+1 and a+1 returns a = NEW object and thus after executing a+=3D1, "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=3D[];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 +=3D 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...=20 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. ------_=_NextPart_001_01C6447F.25A1A520--