Re: I'm exploiting Ruby references

> Smalltalk supports this with the `become` method.


Wow!  become is a great thing.  Why don't we have a built-in become in Ruby?
Or a general replace on every object?  The latter would be a bit more
general,
because swapping to objects (that's what become does if I'm right) could be
done with three replaces.

Here's one ruby
> implementation I found on github: https://github.com/cout/become


Unfortunately it does not work for me.

irb(main):023:0> x.become y
irb: symbol lookup error: /...../become.so: undefined symbol: STR2CSTR
$ _

> eq['x'][0] = eq['y']
> >
> >
> > The equation system changes to this:
> > {
> >  "k"=>12,
> >  "y"=>["k", :+, 1],
> >  "a"=>"y",
> >  "x"=>[["k", :+, 1], :*, ["a", :+, "k", :+, 1]]
> > }
>
> If you're doing this sort of symbolic equation manipulation I'd
> actually advise you to express an equation as a tree,


It is actually a tree represented by arrays and subtrees by
array elements in the array.


> and implement
> some explicit tree rewriting code for variable substitution and
> simplifications. It's a bit of extra work up-front, but you'll have
> complete control of the way things are done.
>

The thing is that I have to solve a huge equation system with more
than 60 000 equations, and I'm trying to keep the memory footprint
of the whole thing as low as possible.  The lexer already produces
arrays in a similar format shown in my examples, and references
make substitution "parallel" on different equations. (It's not really
parallel, but thanks to references I can make substitutions in one
equation, and it also happens in many other.  I don't want to build
custom classes around it, that would just slow down things, and
generate unnecessary metadata.


> values
> (numbers or variables) are always arrays, and that an operator
> combines two arrays to give a third array. Your use of ruby references
> will then work happily enough -


Yes, that is my "rescue" idea too.  It is just not very nice to have
things in equations like [13], or what's worse [[[[13]]]], which just
means 13.  My simplifier (which is at the moment recursive) has to
dig through these extra layers.

one of your current problems is that
> fixnums are immediate values, so there is no way for two variables to
> point to the same fixnum.
>

Oh, yes, you are right, but that's just because my example was wrong.
I can deal with that.  (I can represent numbers as strings, or create a
wrapper class around numbers to solve this.)  My main problem was
to figure out how to replace an object with more than one references
to it and access the new object via all the original references, even if
the new object has a different type.  (The Fixnum 13 was an unlucky
chice. :-)