Hello!

I was surprised to find out that the expression (-1 mod 3) yields -1 in Free Pascal. On the other hand, Pascal ISO 7185:1990, section 6.7.2.2) explicitly defines the `mod' operation "such that 0 <= i mod j < j". What do i miss here?

Thank you in advance,
Dmitry

In our previous episode, Dmitry Lizorkin said:

I was surprised to find out that the expression (-1 mod 3) yields -1 in Free Pascal. On the other hand, Pascal ISO 7185:1990, section 6.7.2.2) explicitly defines the `mod' operation "such that 0 <= i mod j < j". What do i miss here?

FPC is Delphi compatible and Delphi returns -1.

That FPC never claims to be iso compliant. -1 mod 3 evalutes to -1 for most modern programming languages.

That FPC never claims to be iso compliant. -1 mod 3 evalutes to -1 for most modern programming languages.

Thank you for the clarification. A pity that FPC has no iso conformance mode.

Dmitry

Well, it doesn't seem a big pity else somebody would have made one ;)

Or maybe a new switch: COMPUTATIONALLYWRONG_MATHEMATICALLYCORRECT ON/OFF? Although an assumed standard, lot´s of modern calculations depend on a mod being able to assume a negative value.

Regards,

Thaddy

No virus found in this outgoing message.
Checked by AVG - http://www.avg.com
Version: 8.0.175 / Virus Database: 270.8.4/1751 - Release Date: 27-10-2008 22:44

Op Tue, 28 Oct 2008, schreef Thaddy:

Or maybe a new switch: COMPUTATIONALLYWRONG_MATHEMATICALLYCORRECT ON/OFF? Although an assumed standard, lot´s of modern calculations depend on a mod being able to assume a negative value.

There is no need for such a switch. No programs needs it, because if you need to positive value you need just one if statement.

The only possible issue can be compatibility with programs in ISO dialect. But FPC developers have signalled a lack of attractive code bases in ISO dialect, which means we will not spend our valuable time on such a mode, it serves little purpose. People interrested in such a mode can contribute patches.

Daniël

Or the beautiful iso-compliant Abs? <smile>

I agree, no real life need.

No virus found in this outgoing message.
Checked by AVG - http://www.avg.com
Version: 8.0.175 / Virus Database: 270.8.4/1751 - Release Date: 27-10-2008 22:44

Thaddy wrote

Or maybe a new switch: COMPUTATIONALLYWRONG_MATHEMATICALLYCORRECT ON/OFF? Although an assumed standard, lot´s of modern calculations depend on a mod being able to assume a negative value.

Conceptually it's just the difference between "modulo" (mod) and "remainder" (rem). Some computer languages have distinct operators for those:

-- 8< --
Signed integer division and remainder are defined by the relation:

(5)
A = (A/B)*B + (A rem B)

(6)
where (A rem B) has the sign of A and an absolute value less than the absolute value of B. Signed integer division satisfies the identity:

(7)
(-A)/B = -(A/B) = A/(-B)

(8)
The signed integer modulus operator is defined such that the result of A mod B has the sign of B and an absolute value less than the absolute value of B; in addition, for some signed integer value N, this result satisfies the relation:

(9)
A = B*N + (A mod B)
-- 8< --

So the "mod" in Delphi/FPC is just called wrong. ;)

Vinzent.

And impractical.. <smile> As implicitly stated before, I am a bit ambiguous on this issue.

No virus found in this outgoing message.
Checked by AVG - http://www.avg.com
Version: 8.0.175 / Virus Database: 270.8.4/1751 - Release Date: 27-10-2008 22:44

http://en.wikipedia.org/wiki/Modulo_operation
-Michael

Hello!

> There is no need for such a switch. No programs needs it, because if > you need to positive value you need just one if statement. Or the beautiful iso-compliant Abs? <smile>

That's not that simple. In particular, ISO-compliant result for (-1) mod 3 is 2, not abs(-1). As the result, one cannot express the requested behaviour within a single expression and has to use either several statements or implement a user-defined function equivalent to ISO-compliant "mod".

So the "mod" in Delphi/FPC is just called wrong. ;) From this perspective, you could as well remove "mod" from the language at

all. With this design decision taken, every user could at least have the ability to re-implement the "mod" functionality using "div" and either ISO-compliant or Delphi-specific manner. This is anyway better than spending 0.5+ hours searching for a bug in a written program and discovering that it is the standard mathametical operation that behaves unexpectedly.

I agree, no real life need.

Except probably for my 150 students to whom i can no longer recommend FPC as a reference implementation.

Dmitry

> I agree, no real life need. Except probably for my 150 students to whom i can no longer recommend FPC as a reference implementation.

Hopefully they won't be schocked when being hit by another real world programming language implementing mod like it is implemented in computer science.

Dmitry Lizorkin wrote

Except probably for my 150 students to whom i can no longer recommend FPC as a reference implementation.

FPC indeed is not a reference implementation of ISO Pascal.

Jonas

Op Wed, 5 Nov 2008, schreef Dmitry Lizorkin:

Except probably for my 150 students to whom i can no longer recommend FPC as a reference implementation.

That's okay. You should never have recommended FPC as a reference implementation, because we are not. We started to implement the Borland dialect, now implement the Mac dialect, so you can nowadays consider FPC a compiler that implements the family of UCSD derived dialects. The UCSD dialect predates, and is not compatible with, the ISO dialect.

Daniël

Unless they make use of Ada.

mm

Which just has both, that's all. ;)

As an alternative one could read some other language reference manuals and notice that - surprisingly - at least two of the more common "real world languages" don't even have a "modulo" operation:

ISO/IEC9899:1999:

-- 8< --
6.5.5 Multiplicative operators

[...]

5 The result of the / operator is the quotient from the division of the first operand by the second; the result of the % operator is the remainder. [...]
-- 8< --

Java:

http://mindprod.com/jgloss/modulus.html
http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.17.3

So, IMO somebody at Borland got it wrong, just because someone at Intel did it that way - and this has definitely and absolutely nothing to do with a "computer science implementation".

SCNR,

Vinzent.

Hello,

[...]

Java:

[...]

Just because it's called "remainder" in other languages (and if you had actually read the specs ;), the result in these languages is still the same as for the FPC "mod" operator.

E.g. both read, having the exact same wording in both specs, "...produces a result value such that (a/b)*b+(a%b) is equal to a."

I.e. for a=-1 and b=3 the result is -1 following from a%b = a - (a/b)*b for both C99 and Java.

SCNR, really, =)
Thomas

Yes, that's precisely what I said: They do NOT incorrectly call it "mod(ulo|us)" (aside the fact, that they use unreadable special chars for the operator), they call it "remainder".

It appears, you didn't read my mail, not that I didn't read the specs, like you seem to suggest. :P

E.g. both read, having the exact same wording in both specs, "...produces a result value such that (a/b)*b+(a%b) is equal to a." I.e. for a=-1 and b=3 the result is -1 following from a%b = a - (a/b)*b for both C99 and Java.

Yes, absolutely. That's what they define it does, and that's exactly what someone should expect from a "rem" operation. Those languages simply don't have a "mod" operator (I hate to repeat myself, but it seems necessary).

But: If "mod" is a defined operator, it usually behaves differently:

-- 8< --
$ cat modulo.adb
with Ada.Text_IO; use Ada.Text_IO;
procedure modulo is
begin
    Put_Line (Integer'Image ((-1) mod 3));
    Put_Line (Integer'Image ((-1) rem 3));
end modulo;

~
$ gnatmake.exe modulo.adb
gcc -c modulo.adb
gnatbind -x modulo.ali
gnatlink modulo.ali

~
$ ./modulo.exe
2
-1
-- 8< --

And the fact still remains, that Delphi (and thus FPC) call the "remainder" operation a "modulus" operation. That's - well, counterintuitive.

Vinzent.

Which could solve the problem assuming A/B has only one solution. But this is untrue. With real operands, i.e., not integer ones, there is one solution (when B 0, of course). But with integer operands, if A is not a multiple of B, there are two possible quotients. And none is particular, both agree with the math definition :

A = B*q + r with |r| < |B|

For instance, for 13/7, the 2 possible quotients are 1 and 2 because

13 = 7 * 1 + 6
13 = 7 * 2 - 1

Now, that FPC returns -1 for -1 mod 3 is not very important. If one needs a Ada-like behaviour, the code is easy to write.

mm
----
http://www.ellipsa.net/