Numerics redesign proposal

Hi,

I would like to propose some changes in current dylan numbers implementation.
Let's me describe current situation first. Currently, dylan implements the
number type hierarchy shown in this image[1], with some additions.

First, there is an <abstract-integer> that inherits from <rational> intended for
extending integer numbers, from which both <integer> and <big-integer> (an
extension) are inherited. Currently the only supported extended integer is
<double-integer>, which inherits from <big-integer>.

Second, there is a <machine-number> that inherits from <real> and which
represents numbers that fit into a primitive number type. Both <integer> and
<float> classes inherit from <machine-number>.

If we look at how arithmetic operations are implemented, we can see that there
are basically three group of operations:

1) Operations with open generic functions specialized for <object>, both unary
and binary: zero?, positive?, negative?, integral?, +, *, -, /, negative, ^,
abs, lcm and gcd. These are implemented using an open generic functions
specialized for <object> and sealed over <complex> domain (with the exception
of lcm and gcd which are not sealed over any domain).

2) Operations defined as functions with parametrs of type <real>, both unary
and binary: floor, ceiling, round, truncate, floor/, ceiling/, round/,
truncate/, modulo and remainder. These are implemented using open generic
functions specialized for <machine-number> and sealed over <complex> domain.

3) Operations defined as functions with parameters of type <integer>, both
unary and binary: logior, logxor, logand, lognot and ash. These are
implemented as functions with <machine-number> parameters, with the exception
of <ash>, implemented as a function with <integer> parameters.

This implementation presents a pair of problems:
1) It does not conform with the requirements of the Dylan Reference Manual in
the 2nd and 3rd groups, because DRM states that they must be functions on
<real> and <integer> respectively.
2) It makes it hard to extend the numeric system.

This second problem is the most important I think. As I said there is a
library of big-integers which implements a <double-integer> number class. To
do so, there is a generic-arithmetic library that redefines all the open
generic functions in arithmetic operations with the proper types and
redefines the methods for types already supported.

This basically makes both arithmetic libraries incompatible, and using
arithmetic operations for <double-integer> requires using prefixes por
functions or similar techniques, basically losing transparency and generality.

I think this all could be simplified while retaining some of the benefits of
the approach, so what I would propose is the following:

1) Modify the open generic functions in division operations (group 2 above),
to use <real> instead of <machine-number>
2) Modify the functions in logical operations (group 3 above) and make them
generic functions of <integers>
3) Seal domains over <machine-number> instead of <complex>. This grants the
compiler that these operations won't be specialized for the types already
supported, and allows optimizations, while still allowing to be extended.
4) Remove generic-arithmetic library
5) Reimplement big-integers library as an extension of dylan
numbers/arithmetic instead of as a replacement.

This way the same functions work for everyone and there's no need of different
arithmetic libraries. This should make easier to extend number classes with
specialized types like bignums, ratios, etc. that could be available as
dylan-extensions or an external library.

Please let me know if I am missing anything or there is something broken with
this proposal.

Cheers.

[1] http://opendylan.org/books/drm/images/drm_Figure_11-3_Number_Classes
_______________________________________________
hackers mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/hackers