Re: [Chicken-users] [Chicken-announce] [ANN] Numbers 3.0 released

[Peter Bex]

On Sat, Oct 04, 2014 at 04:25:16PM -0400, John Cowan wrote:
> I think this is the basic objection to putting unbounded bignums into
> core.  I mentioned before the idea of dividing bignums into smaller
> ("bignum") and larger ("biggernum") versions, though "med(i)num" and
> "bignum" are probably better names.  The idea is that a medinum is of
> fixed size and can handle an s64 (or perhaps an s64 or u64) on both 32-bit
> and 64-bit Chickens; it would be in your terms a basic numeric type.
> The true bignums or biggernums would be used for values beyond this, and
> would be an extended Scheme-only type.  Granted, this means yet another
> case in every type dispatch in the egg, but if medinums were represented
> internally in current bignum format modulo the header tag, there wouldn't
> be much extra work in processing them, only in generating them.

I don't see how that helps.  What would (+ the-biggest-medinum 1) do?
If it returns a flonum, we're back to where we are right now.  If it
overflows or clamps, that worse than what we have now.  If it results in
a bignum, you end up exactly in the situation I described, where any
operation can return numbers unbounded in size.  Unless I'm wrong, those
are the only three options available.

Moving the "true bignums" to Scheme doesn't solve this essential problem,
because this makes all such operations non-inlineable.

> > This is due to the fact that in order to correctly compare flonums,
> > they need to be converted to a bignum and then compared.
> 
> This is also a requirement for transitivity.  See the additional note
> in R7RS, which does not add an additional constraint on top of R5RS,
> but only explains what is already there.

It sucks.

> Note typo: "diadic" should be "dyadic".

Thanks!  I've fixed it in trunk.

Cheers,
Peter
-- 
http://www.more-magic.net