Re: Integers and Mathematical Correctness

[Adam Beneschan <adambeneschan@gmail.com>]

On Saturday, September 27, 2014 9:32:52 AM UTC-7, Niklas Holsti wrote:
> On 14-09-27 12:01 , AdaMagica wrote:
> 
> > Adam,
> > Na, you forget
> > A: Rational := 1/3+1/4;
> > This will be 0 for your function.
> 
> That seems not to be the case. With the definition
> 
>    type Rational is record
>       Numerator, Denominator : Integer;
>    end record;
> 
> and the obvious definitions of "+", "/", and Image for Rational, the
> program fragment
> 
>    R : Rational := 1/4 + 3/2;
> begin
>    Put_Line (Image (R));
> 
> results in the output
> 
>  7 / 2

Well, it should be 7/4 as Jeff pointed out, but yes, that's what I'd expect as long as there are no versions of "+" that take one Integer and one Rational parameter and return Rational.  If there is a visible "+" like that, the program would be rejected as ambiguous.  But 0 (or 0/1 or any Rational number representing 0) is not a possible result.

Christoph did point out that having those versions of "+" is important.  Defining another integer type to use as parameters to those functions is one way of eliminating ambiguity--I assume that this type would use "is abstract" to nullify all of the standard operator declarations that this type definition would create.  

    function "+" (Left, Right : Whole_Number) return Whole_Number is abstract;
    etc.

But it's not the only way; you can manage without defining a new integer type.  If 

    R : Rational := 1/4 + 3/2

is ambiguous, you can disambiguate like this:

    R : Rational := Rational'(1/4) + Rational'(3/2);

which forces the compiler to use the versions of "/" that have a Rational result, and ignore the declarations in Standard that return Integer.  I think there's a tradeoff.  Having to add this in some places could be inconvenient.  But the solution of defining another integer type is probably going to require some type conversions to and from that integer type (since you would not be able to use other arithmetic operations on that type), which could also be inconvenient.  I don't know which is the better solution.

Finally, I want to reiterate the point I made earlier: when it comes to overload resolution, the *location* where the operators are declared (in a USE'd package, in Standard, in the local scope or an enclosing scope or a parent package) is not relevant.  It's relevant when you have two or more declarations that have the same name, AND the same parameters AND the same result type.  When that happens, the location is used to determine which declaration takes precedence over all other declarations THAT HAVE THE SAME PARAMETER AND RESULT TYPES.  Once that's done, there is at most one of each operator with the same parameter/result types, but there can still be more than one that have different parameter and/or result types.  Deciding which of those is used is called overload resolution or name resolution, and the locations where the operators are declared has no effect on overload resolution.

                                -- Adam