Re: Numerics redesign proposal

Hi,

I have written some preliminary benchmarking with division operations
with generic functions defined with <real> instead of <machine-number>
with domain sealed over <machine-number> instead of <complex> and I
didn't appreciate any difference in performance when using C backend.
I don't know how the compiler optimizes sealed domains, maybe someone
that knows the compiler better can explain if this makes sense. I will
share this benchmarks asap so that it can be confirmed.

Cheers

2013/5/17 Carl Gay <[email protected]>:
> 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
>
_______________________________________________
hackers mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/hackers