On Wed, 21 Mar 2001, Jean-Sebastien ROY wrote:
> > in a context where you cannot reasonably use NArray (in
> > which case it'd be interesting to know why).
> If I were to use arrays to store these data, I would loose the advantage 
> of the nice & flexible object model, and would rather use Fortran to get 
> a major speed increase (like we do in our non-experimental softwares).

You could try designing an hybrid model... For example, if some resource
is available as a bunch of functionally identical units arranged in
parallel, instead of having one object per such unit, you could have one
object per vector of them... In some cases, this may actually give better
structure to the system, because redundant parts in the object graph
become abstracted out. And that would allow you to use NArray in a
productive way.

But I don't know that application domain so that suggestion may be
completely inappropriate too.

> While speed is not why I use ruby, it is still nice to have it perform 
> well. (besides, loosing 1 bit in the Fixnums may not be significant ?)

Losing 1 bit in the Fixnums is not significant, because the worst it can
do is cause more overflows into the Bignum domain. Removing bits from the
float format results in loss of precision. Because of this, designing a
completely separate Float30 type is required. We'd have to leave the
current Float there for backward compatibility.

Now i'm not sure who wants to add that feature... It shouldn't be so
difficult to add, but I think the big hurdle is binary compatibility,
because of macros in ruby.h.

> If not for speed, I cannot think of a reason (but there may be one) to 
> store the integers in the references.

It's for both space and speed and because they are 10 times more used than
Floats in the real world. (Then there are the alternate universes of
gaming and scientific computation...)

Could you do it using fixed-point computation? (ok, just kidding)

matju