Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #46323
| Subject | Re: The problem with implementation defined behaviour. |
|---|---|
| Newsgroups | comp.lang.forth |
| References | <56fa93aa$0$5868$e4fe514c@news.xs4all.nl> <2016Mar29.182032@mips.complang.tuwien.ac.at> <n9-dnSdCKI4ASWfLnZ2dnUU7-InNnZ2d@supernews.com> |
| From | trevor <tgritchie@blueyonder.co.uk> |
| Message-ID | <ApPKy.234724$hz.43873@fx42.am4> (permalink) |
| Organization | virginmedia.com |
| Date | 2016-03-30 13:13 +0100 |
On 29/03/16 20:16, Elizabeth D. Rather wrote: > On 3/29/16 6:20 AM, Anton Ertl wrote: >> Albert van der Horst <albert@spenarnc.xs4all.nl> writes: >>> I have this package that calculates modulo a VARIABLE _m. >>> : +m + _m @ MOD ; >>> *m -m /m >>> etc. >>> >>> The result of those operations result on a number 0<=n<=_m. >> >> [long discussion of protecting against negative _m] >> >> I don't know what you are getting at, but the implementation-defined >> behaviour that I thought of first when seeing this code is that >> >> -2 3 mod >> >> produces -2 on some Forth systems and 1 on others. A way to fix that >> is to use FM/MOD, which produces positive numbers for a positive >> dividend. >> >> But if, as you write, performance is important, and if _M does not >> change often, I would go for implementing floored MOD through division >> by multiplication with the inverse, which is quite a bit faster. And >> then your SET-M helps by allowing this implementation without changing >> the interface. >> >>> The bottomline: >>> The behaviour of the mod package for negative _m is >>> undefined. I find this acceptable. >> >> And the GCC and LLVM people find undefined behaviour in C acceptable, >> if that's what inspired this posting. Does not mean that it's ok for >> the rest of us. > > FORTH, Inc. argued for many years that the MOD operators should be > unsigned; they were unsigned in our systems from the 1970's till > SwiftForth (which conformed to Forth94). None of our users ever found a > problem with this usage. A signed MOD makes no real-world sense. No one > has ever presented a mathematical argument for having a signed MOD that > I know of. > > Cheers, > Elizabeth > I would agree if you mean that the modulus should not be signed. My Penguin Dictionary of Mathematics states: "two *integers* a and b are congruent to one another modulo n if they differ by a multiple of a chosen *natural* number n" By this definition it certainly makes no sense for n to be negative. Trevor
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
The problem with implementation defined behaviour. Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-29 14:39 +0000
Re: The problem with implementation defined behaviour. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-29 16:20 +0000
Re: The problem with implementation defined behaviour. "Elizabeth D. Rather" <erather@forth.com> - 2016-03-29 09:16 -1000
Re: The problem with implementation defined behaviour. Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-30 00:06 +0000
Re: The problem with implementation defined behaviour. mhx@iae.nl - 2016-03-29 22:09 -0700
Re: The problem with implementation defined behaviour. "Elizabeth D. Rather" <erather@forth.com> - 2016-03-29 21:37 -1000
Re: The problem with implementation defined behaviour. Paul Rubin <no.email@nospam.invalid> - 2016-03-30 00:48 -0700
Re: The problem with implementation defined behaviour. Paul Rubin <no.email@nospam.invalid> - 2016-03-30 00:48 -0700
Re: The problem with implementation defined behaviour. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-30 07:59 +0000
Re: The problem with implementation defined behaviour. mhx@iae.nl - 2016-03-30 10:16 -0700
Re: The problem with implementation defined behaviour. Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-30 23:43 +0000
Re: The problem with implementation defined behaviour. mhx@iae.nl - 2016-03-31 06:01 -0700
Re: The problem with implementation defined behaviour. Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-01 21:36 +0000
Re: The problem with implementation defined behaviour. mhx@iae.nl - 2016-04-01 14:57 -0700
Re: The problem with implementation defined behaviour. Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-01 21:59 +0000
Re: The problem with implementation defined behaviour. mhx@iae.nl - 2016-04-02 00:51 -0700
Re: The problem with implementation defined behaviour. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-01 08:25 +0000
Re: The problem with implementation defined behaviour. Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-01 21:32 +0000
division performance (was: The problem with implementation defined ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-05 11:12 +0000
Re: division performance (was: The problem with implementation defined ...) Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-05 20:45 +0000
Re: division performance (was: The problem with implementation defined ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-06 10:03 +0000
Re: division performance (was: The problem with implementation defined ...) Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-08 22:53 +0000
Re: division performance (was: The problem with implementation defined ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-09 10:14 +0000
Re: division performance (was: The problem with implementation defined ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-09 13:43 +0000
Re: The problem with implementation defined behaviour. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-31 10:55 +0000
Re: The problem with implementation defined behaviour. mhx@iae.nl - 2016-03-31 06:38 -0700
Re: The problem with implementation defined behaviour. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-31 16:21 +0000
Re: The problem with implementation defined behaviour. Paul Rubin <no.email@nospam.invalid> - 2016-03-31 11:49 -0700
Re: The problem with implementation defined behaviour. "Elizabeth D. Rather" <erather@forth.com> - 2016-03-31 10:11 -1000
Re: The problem with implementation defined behaviour. mhx@iae.nl - 2016-04-01 03:53 -0700
Re: The problem with implementation defined behaviour. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-01 11:44 +0000
Re: The problem with implementation defined behaviour. Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-01 21:53 +0000
Re: The problem with implementation defined behaviour. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-04-02 11:46 -0500
Re: The problem with implementation defined behaviour. Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-02 21:43 +0000
Re: The problem with implementation defined behaviour. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-04-03 03:17 -0500
Re: The problem with implementation defined behaviour. hughaguilar96@gmail.com - 2016-04-01 23:54 -0700
Re: The problem with implementation defined behaviour. Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-30 12:58 +0000
Re: The problem with implementation defined behaviour. Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-30 22:22 +0000
Re: The problem with implementation defined behaviour. Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-30 12:55 +0000
Re: The problem with implementation defined behaviour. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-30 07:44 +0000
Re: The problem with implementation defined behaviour. Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-30 13:08 +0000
Re: The problem with implementation defined behaviour. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-30 13:43 +0000
Re: The problem with implementation defined behaviour. Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-30 22:06 +0000
Re: The problem with implementation defined behaviour. trevor <tgritchie@blueyonder.co.uk> - 2016-03-30 13:13 +0100
Re: The problem with implementation defined behaviour. Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-30 13:56 +0000
Re: The problem with implementation defined behaviour. Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-30 12:49 +0000
csiph-web