Re: Numerics redesign proposal

Do you have any idea how this might affect performance?

Making it easier to use <double-integer>s would be very nice indeed.


On Thu, May 16, 2013 at 3:28 PM, Alfredo Beaumont <
[email protected]> wrote:

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

_______________________________________________
hackers mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/hackers