Re: [Chicken-hackers] [PATCH] More efficient numbers integration through "scratchspace"

[Peter Bex]

On Tue, Apr 21, 2015 at 09:47:50AM -0400, address@hidden wrote:
> Peter Bex scripsit:
> 
> > That's right.  That's why I described it as "an extension of the nursery":
> > it isn't actually stored on the stack,
> 
> So it could be allocated in the heap or simply as a global array.
> Since there is only one at a time, and its size is fixed, a global array
> would make sense to me, even though it allocates a little extra space
> that isn't used in programs that don't have bignums.

Can you please stop theorising and suggesting "improvements" to code
you obviously haven't studied and don't understand?  This is very
irritating.

More to the point: the scratch space size isn't truly fixed: it may
grow to arbitrary sizes, while the internal number calculation routines
do their thing.  The gcd, karatsuba and burnikel-ziegler algorithms will
allocate quite a lot of garbage while they run.  Besides, the size is
only checked at the start of a CPS function.  If it calls a lot of
inline allocating functions, it may not check the size for a long time.

> > You're right about the wrapper objects: Currently, only bignum data
> > string objects are allocated in scratchspace.
> 
> Ah.  Your original posting confused me on this point.  So a procedure
> returning a rectnum in the form <digits1>/<digits2>+<digits3>/<digits4>i
> will allocate four bignum digit string objects in the scratch space, two
> ratnums on the stack, and one rectnum on the stack (assuming the
> digit strings are big enough and relatively prime).

Yeah, that's correct.

Cheers,
Peter

signature.asc
Description: Digital signature