Re: Ruby doesn't implement x++ for Fixnum's because ???

On Oct 30, 11:05=A0am, Robert Klemme <[e-mail]> wrote:
> 2009/10/30 RichardOnRails <[e-mail]>:
>
> > I'll correct my errors and probably have a new theory subsequently.
>
> IMHO the story goes like this: absence of postfix ++ and -- is a
> consequence of the fact that numeric types are immutable in Ruby which
> makes an assignment necessary for these operators. =A0Although that
> would be doable, it would not immediately be obvious when looking at
> "foo++". =A0On the other side, "foo +=3D 1" makes the assignment obvious
> while still being pretty concise (you do not have to write "foo =3D foo
> + 1").
>
> Which brings us to the question: what is the advantage of immutable
> numbers? =A0First, it avoids errors that could be caused by aliasing
> (two objects refer the same object, one of them changes it, it changes
> for the other one as well without being expected). =A0Then, it is quite
> natural if you consider mathematical numbers: they cannot change.
>
> Additionally, the expression "1" can always refer to the same object
> (in reality it's a bit different but from a Ruby programmer's
> perspective the difference is not noticeable) which in fact makes
> using numeric constants very efficient (as opposed to the expression
> "'foo'" which constructs a new String instance on every invocation,
> albeit with a shared char array underneath which eases the pain a
> bit).
>
> This in turn makes integer math pretty efficient because if numbers
> were mutable Ruby would have to create a new object for every result
> of an operator evaluation. =A0I am not saying that Ruby is ideal for
> number crunching but it could be significantly slower if certain
> design decisions would have been made differently.
>
> Kind regards
>
> robert
>
> --
> remember.guy do |as, often| as.you_can - without endhttp://blog.rubybestp=
ractices.com/

Hi Robert,

Thank you for your thoughtful and extensive responses.  I apologized
earlier for my sloppy analysis.  I hope the following offers higher
quality.

(a) You say, in part:
=93... immutable numbers?  First, it avoids errors that could be caused
by aliasing (two objects refer the same object, one of them changes
it, it changes for the other one as well without being expected=94
(b) Dave Black, in his truly excellent =93The Well-Grounded Rubyist=94
says, in part:
=93Any object that=92s represented as an immediate value is always exactly
the same object=94 and
=93The reason [there=92s no x=3D1; x++] is that , due to the immediate
presence of 1 in x, means you=92d be changing 1 into 2,
and that makes no sense=94

1. I=92d rather discuss this matter in concrete terms rather than
abstractions.  Please look at the following method (to generate
results) and two statements:

def show(v)
  "Got #{v}, class =3D #{v.class}, object_id =3D #{v.object_id}
(v.object_id-1)/2 =3D #{(v.object_id-1)/2 }"
end

a =3D 1; show (a)  =3D>  Got 1;  class =3D Fixnum;   object_id =3D 3;  v >>=
 1
=3D 1
b =3D 1; show (b)  =3D>  Got 1;  class =3D Fixnum;   object_id =3D 3;  v >>=
 1
=3D 1
a =3D=3D b =3D> true

Both =93a=94 and =93b=94 have their respective values held as immediate val=
ues
(embedded in their object_id=92s), but they are NOT the same thing
because they=92re ultimately held in their respective entries in the
symbol table.  So, object_id=92s for Fixnum=92s are synthetic.  To think
that  those object_id=92s point to a location in a memory area that
stores the 32-bit 000...001 (in a 32-bit machine/OS) is to  contradict
the meaning of immediacy and defeat the very efficiency that immediate
values offer.

2. Now please consider the following supplement to the statements
above:

a +=3D 1; show (a)  =3D>  Got 2;  class =3D Fixnum;   object_id =3D 5;  v >=
> 1
=3D 2
show (a)  =3D>  Got 2;  class =3D Fixnum;   object_id =3D 5;  v >> 1 =3D 2
show (b)  =3D>  Got 1;  class =3D Fixnum;   object_id =3D 3;  v >> 1 =3D 1

The assignment of =93a +=3D 1=94 to =93a=94 changed a=92s object_id to embe=
d a new
value: 2.  Despite that change of 1 to 2 in a=92s object,  =93b=94 remains
set to 1.  =93b=94 did not suffer the calamity of a universal change of
all Fixnum 1=92s to 2=92s.

3. Conclusion:

a +=3D 1 is equivalent to a++=92s natural meaning.  In fact, we further
supplement the above statements with:

class Fixnum
  def pp # We can=92t define ++ because of a compiler restriction.
    self + 1
  end
end

a=3D1; show(a.pp)  =3D>  Got 2;  class =3D Fixnum;   object_id =3D 5;  v >>=
 1
=3D 2
show(b)  =3D>  Got 1;  class =3D Fixnum;   object_id =3D 3;  v >> 1 =3D 1

Furthermore, pp works fine on the boundary condition for Fixnum=92s on a
common 32-bit cpu/OS, i.e. 2**30-1:

a =3D 2**30-1; show (a) =3D> Got 1073741823;  class =3D Fixnum;   object_id
=3D 2147483647;  v >> 1 =3D 1073741823
a =3D 2**30; show (a) =3D> Got 1073741824;  class =3D Bignum;   object_id =
=3D
22737670;  v >> 1 =3D 11368835

So x++ works fine in the form of pp for positive Fixnum=92s.  I assume
it=92ll work fine for non-positives, also..  A compiler change to allow
=93def ++=94 is necessary to finally add ++ to Fixnum.

Again,  thanks for your responses to my question.

Best wishes,
Richard