possible improvements

[Richard B. Kreckel]

Hi there,

On Thu, 1 Aug 2002, Chris Dams wrote:
[...]
> > I really don't see any good way out of this, given that any expression may
> > be a highly non-treeish directed acyclic graph in GiNaC.
> 
> Of course, for any implementation of this it would not be very difficult
> to think of an example where it would not help at all, but I suppose
> situations where it is usefull are much more abundant. Think of having a
> huge polynomial in ten different symbols. The only thing that would be
> kept in memory are the ten different symbols and all the rest would
> basically be a great number of pointers to them that can be stored in a
> file. This is indeed highly non-treeish, since there are not many leaves
> (only ten). However this makes it especially suited for a largeadd. The
> point is that situations like this one seem to occur rather often.

For expanded polynomials, what you say appears to make perfect sense.  It
would, however, have to be tested in realistic computations.

> > How should such a class largeadd interfere with the normal add class?
> 
> I suppose it would be a child of the ordinary add having its own versions
> of the methods an add has, so that it can be used where an add is
> expected without problems.

Hmm, and operator+(const ex&, const ex&) and friends would have to create
what?  An add or a largeadd?  To me, it still appears more to be a
replacement for add, instead of an addition to the current scheme.

> > We do care that it works on platforms with 64 Bit ABI thus ensuring that
> > it still runs fine when you have pervert amounts of RAM, and I
> > repeatedly checked that it scales well there.
> 
> I don't think I really understand this. Is not the only thing that with a
> 64 Bit ABI that pointers are twice as long? Why would that matter? Of
> course nobody would forbid you to replace the largeadds in your program by
> ordinary ones after having bought more memory (or a different computer, or
> whatever). Also the user would probably be able to control the amount of
> terms in a largeadd that are loaded into memory during operations on them.

I was just referring to the 4GB limit in address space on all 32Bit
machines.  That is a hard limit and it is approaching quickly.  Indeed,
some have already crossed it...

Regards
    -richy.
-- 
Richard B. Kreckel
<Richard.Kreckel at Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>