Prev: Error when running gcc from GPS
Next: LIACC moved to LIAAD
From: Georg Bauhaus on 27 Apr 2010 11:30
On 27.04.10 16:00, AdaMagica wrote:
> But Standard.Integer is an integer ;-)
>
> Very_Big : constant := Integer'Last + Integer'Last; --
> "+" of Integer
> Even_Bigger: constant := Long_Integer'Last + Long_Integer'Last; --
> "+" of Long_Integer
> Illegal : constant := Long_Integer'Last + Integer'Last; --
> "+" mixing

Are these really of type Standard.Integer? I think (after rummaging
through the RM) they are not.
These are named numbers, and their declaration has no effect.
They are of type universal_integer (unconstrained?) which has no name.
And they cannot overflow then.

The builtin "+" can deliver the sum of any static constants
within capacity constraints of the compiler.

package Big is

Z : constant := 2 ** 1_000_000_000;

Y : constant := 2 ** 10_000;

A : constant := 9 ** (9 ** 9);

B : constant := Long_Long_Integer'Succ (2**63 - 1);

Bigger : constant Boolean := B > Long_Long_Integer'Last;

end Big;

Compiling: big.ads (source file time stamp: 2010-04-27 14:53:49)

5. Z : constant := 2 ** 1_000_000_000;
|
>>> static value too large, capacity exceeded

7. A : constant := 9 ** (9 ** 9);
|
>>> static value too large, capacity exceeded


Unavailable:
for D'Size use ...;
pragma Inspection_Point (...);

Big.Bigger is True.

My conclusions would be that:

Standard.Integer is a constrained subtype. Its objects are
not like (what is commonly known as) integers, a set that can
be extended at will.
They cannot overflow in Ada mode. There is no wrap-around.

Named numbers of no-name type universal_integer
cannot overflow, their value is determined by the compiler,
they are not objects, and they can hit compiler capacity limits.

So neither Standard.Integer nor universal_integer is an integer.

Nor is C's int. Still assuming C's int is like integers,
encouraged by how "int" and "integer" are used interchangeably
in talks and writings, leads to to overflow (this is my
hypothesis).

From: Dmitry A. Kazakov on 27 Apr 2010 12:13
On Tue, 27 Apr 2010 17:30:44 +0200, Georg Bauhaus wrote:

> My conclusions would be that:
>
> Standard.Integer is a constrained subtype. Its objects are
> not like (what is commonly known as) integers, a set that can
> be extended at will.

The set of integers is not extensible "at will." You probably meant that
for any integer there exists at least one [actually an infinitely countable
set] of greater or lesser integers. Nevertheless the set of integers (Z) is
fixed.

Standard.Integer is not an integer, it is a type, used to model integers or
other entities. It is not Z independently on how adequately it models the
latter.

> They cannot overflow in Ada mode. There is no wrap-around.

> Named numbers of no-name type universal_integer
> cannot overflow, their value is determined by the compiler,

Their behavior, you mean. The value is determined by the expression and the
language rules.

> they are not objects, and they can hit compiler capacity limits.

Whether they are [run-time] objects is up to compiler. The compiler in Ada
has certain freedom to "objectize" and "deobjectize" things.

> So neither Standard.Integer nor universal_integer is an integer.

See above. They are not per definition. The question how adequately they
can model Z, is answered as: neither does it 100%. The domain of either
type is finite. Both domains include non-integer ideal elements called
"exception propagation" or "compile error." Concerning the latter, for any
legal Ada program there can exist a compiler capable to compile it without
error [if you have enough material and time].

> Nor is C's int. Still assuming C's int is like integers,
> encouraged by how "int" and "integer" are used interchangeably
> in talks and writings, leads to to overflow (this is my
> hypothesis).

You need overflow in order to define the behavior of the operations closed
only in Z. E.g. "+".

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: Georg Bauhaus on 27 Apr 2010 13:09
On 27.04.10 18:13, Dmitry A. Kazakov wrote:
> On Tue, 27 Apr 2010 17:30:44 +0200, Georg Bauhaus wrote:
>
>> My conclusions would be that:
>>
>> Standard.Integer is a constrained subtype. Its objects are
>> not like (what is commonly known as) integers, a set that can
>> be extended at will.
>
> The set of integers is not extensible "at will." You probably meant that
> for any integer there exists at least one [actually an infinitely countable
> set] of greater or lesser integers. Nevertheless the set of integers (Z) is
> fixed.

Thanks for adding clarity. It is much needed.

> The value is determined by the expression and the
> language rules.

(OK, nitpicking, there is no value denoted by a named number
if determination does not actually happen. Words mean
nothing unless they are given meaning. ;-) ;-)

>> they are not objects, and they can hit compiler capacity limits.
>
> Whether they are [run-time] objects is up to compiler. The compiler in Ada
> has certain freedom to "objectize" and "deobjectize" things.

Thanks, I didn't know this.


> You need overflow in order to define the behavior of the operations closed
> only in Z. E.g. "+".

True if it is not possible to define "+" in terms of saturation
or wrap-around, I think. Correct?

However, programmers do not define "+" in their C programs.
They use "+"!
Then overflow occurs, and not to prove the soundness of the
language definition, but as a mishap.
From: Dmitry A. Kazakov on 27 Apr 2010 13:56
On Tue, 27 Apr 2010 19:09:43 +0200, Georg Bauhaus wrote:

> On 27.04.10 18:13, Dmitry A. Kazakov wrote:
>
>> The value is determined by the expression and the
>> language rules.
>
> (OK, nitpicking, there is no value denoted by a named number
> if determination does not actually happen. Words mean
> nothing unless they are given meaning. ;-) ;-)

Yes, but the meaning is given by the language rules, not by the running
instance of the compiler. Therefore:

X : constant := 2**(2**(2**(2**1_000_000_000)));

is well-defined even if there likely will never exist a compiler-machine
combination capable to swallow it.

>> You need overflow in order to define the behavior of the operations closed
>> only in Z. E.g. "+".
>
> True if it is not possible to define "+" in terms of saturation
> or wrap-around, I think. Correct?

"+" can be defined in any way. The question is the semantics of. If the
semantics of "+" is to model Z, then it cannot return a value from Z which
is mathematically wrong. The problem is not in a singular value. It is with
the programs that will use this value in other computations. In the end it
will break everything about Z. You won't be certain about any evaluated
value. Ideals like exceptions, NaN etc, limit the damage.

> However, programmers do not define "+" in their C programs.
> They use "+"!
> Then overflow occurs, and not to prove the soundness of the
> language definition, but as a mishap.

Yes. If the programmer is lucky then the behavior maps the implied
semantics. This is what we call "safe choice." Unfortunately C's choices
are often unsafe in the sense that the layman programmer's expectations are
far not what C actually does.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
 | 
Pages: 1
Prev: Error when running gcc from GPS
Next: LIACC moved to LIAAD