Hello !
I found out that the result of 6 MOD -90 in my little Pascal Program on Windows is -84 and on Solaris is 6 (in my opinion the right one). Whats up there ? BTW : My Calculator HP48 says that -84 was right ??? A matter of definition ?
Hope you can help me.
Tim
Tim Kaulmann wrote:
Hello !
I found out that the result of 6 MOD -90 in my little Pascal Program on Windows is -84 and on Solaris is 6 (in my opinion the right one). Whats up there ? BTW : My Calculator HP48 says that -84 was right ??? A matter of definition ?
I've just discussed this issue with my friends in the Institute and it seems interesting...
In usual mathematical practice a mod b is a non-negative r less than b such that b|(a-r). Most compilers seem to have their own understanding of mod, a kind of extension to mod definition. It is sure we should have a = (a div b)*b + (a mod b).
BTW according to BP 7.0 6 mod -90 is 6.
Regards
On 5 Apr 2000, at 16:50, Mariusz Zynel wrote:
Most compilers seem to have their own understanding of mod, a kind of extension to mod definition.
The Extended Pascal standard (ISO 10206) says:
"A term of the form i mod j shall be an error if j is zero or negative; otherwise, the value of i mod j shall be that value of (i-(k*j)) for integral k such that 0 <= i mod j < j."
So, at least for EP, the original expression (6 mod -90) should give an error.
It is sure we should have a = (a div b)*b + (a mod b).
Not so sure, at least for EP! The standard also has this note:
"Only for i >= 0 and j > 0 does the relation (i div j) * j + i mod j = i hold."
BTW according to BP 7.0 6 mod -90 is 6.
Then at least for BP and EP, we need different "mod" semantics.
-- Dave
Tim Kaulmann wrote:
I found out that the result of 6 MOD -90 in my little Pascal Program on Windows is -84 and on Solaris is 6 (in my opinion the right one).
Both with GPC?
Whats up there ?
Maybe a bug.
What does GCC do on the same platforms?
("mod" is "%" in C.)
Peter
On 5 Apr 2000, at 18:30, Peter Gerwinski wrote:
What does GCC do on the same platforms?
("mod" is "%" in C.)
Unfortunately, that won't help define what Pascal should do (I think that is what you are implying here -- apologies if it is not). The semantics of mod varies among languages, so deciding what C does isn't applicable.
For example, 6 mod -90 is an error in Standard and Extended Pascal. 6 mod -90 is legal in Ada and is -84. I don't have the Fortran or C standards available, so I don't know what they say.
According to the GPC documentation, it supports:
--standard-pascal-level-0 --standard-pascal --extended-pascal --object-pascal --borland-pascal --pascal-sc
My last note specified how mod must work for EP (and SP, as it turns out). So someone needs to check the OP, BP, and PSC standards, if such exist, to see how mod should be implemented for each of those dialects. If there are no such standards, then determining by testing how OP, BP, and PSC actually work would be appropriate.
Actually, I suppose if no dialect is specified, GPC could adopt the C semantics for mod if desired....
-- Dave
J. David Bryan wrote:
On 5 Apr 2000, at 18:30, Peter Gerwinski wrote:
What does GCC do on the same platforms?
("mod" is "%" in C.)
Unfortunately, that won't help define what Pascal should do (I think that is what you are implying here -- apologies if it is not). The semantics of mod varies among languages, so deciding what C does isn't applicable.
What I'd like to have checked is whether GNU C's "mod" operation produces different results on different platforms. If so, we have detected a bug in the backend, otherwise in the frontend.
Of course, this must be fixed and changed to something Pascalish.
Peter
On 6 Apr 2000, at 7:53, Peter Gerwinski wrote:
What I'd like to have checked is whether GNU C's "mod" operation produces different results on different platforms. If so, we have detected a bug in the backend, otherwise in the frontend.
OK, I see now. GCC 2.95.2 produces "6". That's for i386-pc-mingw32msvc, i386-pc-mingw32crt, and i586-pc-cygwin32. All running under Windows NT.
Is that what you're looking for, or do you need something else?
-- Dave
J. David Bryan wrote:
OK, I see now. GCC 2.95.2 produces "6". That's for i386-pc-mingw32msvc, i386-pc-mingw32crt, and i586-pc-cygwin32. All running under Windows NT.
Is that what you're looking for, or do you need something else?
Not really - this is not a surprise. The result for different processors would be more interesting.
Peter
6-Apr-00 07:53 you wrote:
J. David Bryan wrote:
On 5 Apr 2000, at 18:30, Peter Gerwinski wrote:
What does GCC do on the same platforms?
("mod" is "%" in C.)
Unfortunately, that won't help define what Pascal should do (I think that is what you are implying here -- apologies if it is not). The semantics of mod varies among languages, so deciding what C does isn't applicable.
What I'd like to have checked is whether GNU C's "mod" operation produces different results on different platforms.
It DOES.
If so, we have detected a bug in the backend, otherwise in the frontend.
It's NOT bug. It's feature. Different processors have different ideas about what (6 mod -90) means. Beaing "high-level assebler" C does NOT define what "%" will do if negative numbers involved so most efficient implementation can be used. In case of iX86 processor will return (6/-90)==0, (6%-90)==6, (100/-90)==-1, (100%-90)==10, etc (basically: do division with absolute values, then add sign to make equation x==(x div y)*y+(x mod y) correct).
Of course, this must be fixed and changed to something Pascalish.
The question is "what is something pascalish" ? BP, Delphi and so on are all usuing the same low-lovel idiv as GCC, for example ... And produce the same result, of course... Unlike gpc BTW (gcc 2.95.2 will return the same "not very mathematically correct" values as BP/Delphi and iX86's idiv while gpc 19991030 based on gcc 2.95.2 will return "more mathematically correct" thing by adding few checks after idiv... hmm...).
Khimenko Victor wrote:
Of course, this must be fixed and changed to something Pascalish.
The question is "what is something pascalish" ? BP, Delphi and so on are all usuing the same low-lovel idiv as GCC, for example ... And produce the same result, of course... Unlike gpc BTW (gcc 2.95.2 will return the same "not very mathematically correct" values as BP/Delphi and iX86's idiv while gpc 19991030 based on gcc 2.95.2 will return "more mathematically correct" thing by adding few checks after idiv... hmm...).
So GPC should support two variants: EP (runtime error for "mod -42") and BP (positive result).
I vote for the EP variant being the default behaviour with the BP variant being enabled in --borland-pascal and --delphi mode - plus an option to set it explicitly.
And it must be the same behaviour for all platforms. Leaving it undefined invites for very unpleasant errors in future user programs.
Peter
I fully agree with you that GPC should give an error if there is calculated something that is not defined the same in different pascal dialects. At least it should give a warning message as "MOD with negative operands can lead to different results on different platforms and pascal dialects".
I searched for hours and went mad when I saw that my program "worked" on many platforms but mine :-)
BTW : It was just a little "nonsense" program that I had to write for the practice lessons at university.
Thanks to you all. Tim
----- Original Message ----- From: Peter Gerwinski peter@gerwinski.de To: gpc@gnu.de Sent: Thursday, April 06, 2000 2:19 PM Subject: Re: 6 MOD -90 Problem on Windows
So GPC should support two variants: EP (runtime error for "mod -42") and BP (positive result).
I vote for the EP variant being the default behaviour with the BP variant being enabled in --borland-pascal and --delphi mode
- plus an option to set it explicitly.
And it must be the same behaviour for all platforms. Leaving it undefined invites for very unpleasant errors in future user programs.
Peter-- http://home.pages.de/~Peter.Gerwinski/ - G-N-U GmbH: http://www.g-n-u.de Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 GnuPG key fingerprint: 9E7C 0FC4 8A62 5536 1730 A932 9834 65DB 2143 9422 keys: ftp://ftp.gerwinski.de/pub/keys/ - AntiSpam: http://spam.abuse.net
-
J. David Bryan -
Khimenko Victor -
Mariusz Zynel -
Peter Gerwinski -
Tim Kaulmann