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

[John Cowan]

Peter Bex scripsit:

> I just released version 3.0 of the "numbers" egg.

Hurrah!

> Beware of breakage, as is only to be expected with such a huge change.
> There is one backwards incompatible change that I know of: bitwise
> operations do not accept inexact integral numbers anymore.

That frankly sounds like a feature that never had much point.  RnRS requires
some integer-specific procedures to accept inexact integers, so we are
stuck with those, but in the general case it's hard to be sure that
the result of inexact computation will be an integer in any case, so
people probably won't normally apply such functions to inexact values.

The exception is when the integer range of flonums exceeds that of
fixnums, which is still relevant for Cygwin, but I at least almost always
use the numbers egg anyhow.

>From your NOTES file:

> Unfortunately, that's where the good part ends.  Any operation that
> results in a fresh number is no longer inlineable, because in case
> of bignums they will need to allocate an unknown quantity of memory,
> which may require a GC.  The upshot is that every "allocating inline"
> procedure will now need to be called in primitive CPS context.  This is
> fundamental limitation that we can't do much about.

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.

> 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.

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

-- 
John Cowan          http://www.ccil.org/~cowan        address@hidden
I amar prestar aen, han mathon ne nen,    http://www.ccil.org/~cowan
han mathon ne chae, a han noston ne 'wilith.  --Galadriel, LOTR:FOTR