[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: John Cowan
Subject: Re: [Chicken-hackers] [PATCH] More efficient numbers integration through "scratchspace"
Date: Mon, 20 Apr 2015 07:59:56 -0400
User-agent: Mutt/1.5.20 (2009-06-14)

Peter Bex scripsit:

> Except for the fact that this causes the needed stack space is bigger,
> resulting in more minor GCs even for code that doesn't need these numeric
> types.

How can that be?  If the code doesn't use them, they aren't on the stack,
so they can't cause more minor GCs.

> I don't understand how this would work and why it will be needed.  If you
> need flonum behaviour, you can simply convert to inexact before making
> your calculations.

Yes, indeed.  But if your existing code expects (/ 884279719003555
281474976710656) to return 3.141592653589793 and then to continue to
do flonum arithmetic after that, it will not be happy allocating two
bignums and a ratnum instead.  (Silly example, but there are non-silly
ones out there.)  Existing Chicken code has been able to count on this.

> The compiler cannot make the decision to use inexact numbers for you:
> that depends on the application and the domain-specific nature of the
> calculations you're performing, I would say.

Which is exactly why a switch is needed to restore the old behavior
for backward compatibility.  This does not mean shutting off bignums
and ratnums, just not creating them as a result of fixnum operations.
Arguably the most important of the two is not creating ratnums

John Cowan        address@hidden
He played King Lear as though someone had played the ace.
        --Eugene Field

reply via email to

[Prev in Thread] Current Thread [Next in Thread]