4

Does ISO-Prolog have any prescriptions / recommendations regarding the representation of negative integers and operations on them? 2's complement, maybe?

Asking as a programmer/user: Are there any assumptions I can safely make when performing bit-level operations on negative integers?

false
  • 10,264
  • 13
  • 101
  • 209
repeat
  • 18,496
  • 4
  • 54
  • 166

2 Answers2

4

ISO/IEC 13211-1 has several requirements for integers, but a concrete representation is not required. If the integer representation is bounded, one of the following conditions holds

7.1.2 Integer

...

minint = -(*minint)
minint = -(maxint+1)

Further, the evaluable functors listed in 9.4 Bitwise functors, that is (>>)/2, (<<)/2, (/\)/2, (\/)/2, (\)/1, and xor/2 are implementation defined for negative values. E.g.,

8.4.1 (>>)/2 – bitwise right shift

9.4.1.1 Description

...
The value shall be implementation defined depending on
whether the shift is logical (fill with zeros) or arithmetic
(fill with a copy of the sign bit).

The value shall be implementation defined if VS is negative,
or VS is larger than the bit size of an integer.

Note that implementation defined means that a conforming processor has to document this in the accompanying documentation. So before using a conforming processor, you have to read the manual.

De facto, there is no current Prolog processor (I am aware of) that does not provide arithmetic right shift and does not use 2's complement.

false
  • 10,264
  • 13
  • 101
  • 209
0

Strictly speaking these are two different questions:

  1. Actual physical representation: this isn't visible at the Prolog level, and therefore the standard quite rightly has nothing to say about it. Note that many Prolog systems have two or more internal representations (e.g. two's complement fixed size and sign+magnitude bignums) but present a single integer type to the programmer.

  2. Results of bitwise operations: while the standard defines these operations, it leaves much of their behaviour implementation defined. This is a consequence of (a) not having a way to specify the width of a bit pattern, and (b) not committing to a specific mapping between negative numbers and bit patterns.

This not only means that all bitwise operations on negative numbers are officially not portable, but also has the curious effect that the result of bitwise negation is totally implementation-defined (even for positive arguments): Y is \1 could legally give -2, 268435454, 2147483646, 9223372036854775806, etc. All you know is that negating twice returns the original number.

In practice, fortunately, there seems to be a consensus towards "The bitwise arithmetic operations behave as if operating on an unlimited length two's complement representation".

jschimpf
  • 4,904
  • 11
  • 24
  • "... are officially not portable" - this is a very polemic way of interpreting the situation. For, just for integers, there are many more implementation defined features. Take, whether or not integers are bounded. Before making statements about the portability between two Prolog systems, you *always* have to check the manual for implementation defined features that might affect portability. – false May 15 '15 at 18:55
  • 1
    "officially not portable" is meant in contrast to the "in practice portable" in the following paragraph. Not sure what you perceive as polemic there, none was intended. – jschimpf May 15 '15 at 20:09