At least the language go has it right:
https://go.dev/ref/spec#Operators
No ambiguous condition or used defined stuff.
go even specifies what
0x8000_0000_0000_0000 / -1
should yield.
albert@cherry.(none) (albert) writes:
At least the language go has it right:
https://go.dev/ref/spec#Operators
No ambiguous condition or used defined stuff.
go even specifies what
0x8000_0000_0000_0000 / -1
should yield.
It specifies that
|if the dividend x is the most negative value for the int type of x,
|the quotient q = x / -1 is equal to x (and r = 0)
That's interesting, because it means that go has to do extra work on
at least IA-32/AMD64 and Power CPUs to produce this result. If you do
the extra work, why not produce a "run-time panic" like for division
by zero?
gforth (the debugging engine) produces an exception in that case,
while gforth-fast does what the hardware does:
Recent gforth everywhere:
$8000000000000000 -1 / .
*the terminal*:1:22: error: Result out of range
$8000000000000000 -1 >>>/<<< .
gforth-fast:
AMD64:
$8000000000000000 -1 / .
*the terminal*:1:22: error: Division by zero
$8000000000000000 -1 >>>/<<< .
Aarch64:
$8000000000000000 -1 / cr hex.
$8000000000000000 ok
RISC-V:
$8000000000000000 -1 / cr hex.
$8000000000000000 ok
Power:
$8000000000000000 -1 / cr hex.
$0 ok
Note that the exception you see on AMD64 is a different one in
gforth-fast, because that exception is caused by a hardware exception
(which generates the same exception for divide-by-zero and division >overflow).
- anton
In article <2022Aug19.135211@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
albert@cherry.(none) (albert) writes:
At least the language go has it right:
https://go.dev/ref/spec#Operators
No ambiguous condition or used defined stuff.
go even specifies what
0x8000_0000_0000_0000 / -1
should yield.
It specifies that
|if the dividend x is the most negative value for the int type of x,
|the quotient q = x / -1 is equal to x (and r = 0)
That's interesting, because it means that go has to do extra work on
at least IA-32/AMD64 and Power CPUs to produce this result. If you do
the extra work, why not produce a "run-time panic" like for division
by zero?
The people at google defined a language. I can't imagine that
the backward design of I86 of AMD machines should have influence on that.
Then you're back at "user defined features" for a slim speed advantage.
I made the remark to draw attention to how meticulously go is defined.
Maybe we should add a line on the Forth standard:
MIN-INT -1 /
leads to an ambiguous condition.
Note that the exception you see on AMD64 is a different one in
gforth-fast, because that exception is caused by a hardware exception >>(which generates the same exception for divide-by-zero and division >>overflow).
This is probably the situation, the designers of go wanted to
prevent.
albert@cherry.(none) (albert) writes:
At least the language go has it right:
https://go.dev/ref/spec#Operators
No ambiguous condition or used defined stuff.
go even specifies what
0x8000_0000_0000_0000 / -1
should yield.
It specifies that
|if the dividend x is the most negative value for the int type of x,
|the quotient q = x / -1 is equal to x (and r = 0)
That's interesting, because it means that go has to do extra work on
at least IA-32/AMD64 and Power CPUs to produce this result. If you do
the extra work, why not produce a "run-time panic" like for division
by zero?
-32768 -1 /mod ok 0 -32768 <
OTOH I never (knowingly) planned for that. It's the consequence of my >wanting to avoid hardware overflow and IDIV.
Perhaps GO had similar
notions and - like me - prepared to pay the price.
dxforth <dxforth@gmail.com> writes:
-32768 -1 /mod ok 0 -32768 <
OTOH I never (knowingly) planned for that. It's the consequence of my
wanting to avoid hardware overflow and IDIV.
So you do not use IDIV? What do you use?
Perhaps GO had similar
notions and - like me - prepared to pay the price.
Go is specified to panic on division-by-0, so the notion seems not
very similar.
Anton Erl corrected my post of how modern language use the
correct (from a math viewpoint) division.
Apparently not true for Python.
albert@cherry.(none) (albert) writes:
Anton Erl corrected my post of how modern language use the
correct (from a math viewpoint) division.
Apparently not true for Python.
What do you mean about Python? Python uses arbitrary-precision
integers and floored division. In Python 3, the integer division
operation is // rather than / which might cause some confusion.
What I meant was that the equivalence classes modulo need to be
presented by a positive number.
13%-3 needs to be 1, which is correct in golang but not in Python.
At least not in version 2.7.
Has that changed in version 3?
albert@cherry.(none) (albert) writes:
What I meant was that the equivalence classes modulo need to be
presented by a positive number.
13%-3 needs to be 1, which is correct in golang but not in Python.
At least not in version 2.7.
Has that changed in version 3?
Python 3.9.2:
>>> divmod(13,-3)
(-5, -2)
What do you want 13 // -3 to be? -5 is what you get from floored
division, in which case the remainder has to be -2.
albert@cherry.(none) (albert) writes:
What I meant was that the equivalence classes modulo need to be
presented by a positive number.
13%-3 needs to be 1, which is correct in golang but not in Python.
At least not in version 2.7.
Has that changed in version 3?
Python 3.9.2:
(-5, -2)divmod(13,-3)
What do you want 13 // -3 to be? -5 is what you get from floored
division, in which case the remainder has to be -2.
Most users want to divide positive by positive and the result is the
same in most languages. Less common (and the less users care) is
when either input is negative.
dxforth <dxforth@gmail.com> writes:
Most users want to divide positive by positive and the result is the
same in most languages. Less common (and the less users care) is
when either input is negative.
Negative divisor is particularly rare. Didn't Forth, Inc. use to have signed-by-unsigned division words?
dxforth <dxforth@gmail.com> writes:
Most users want to divide positive by positive and the result is the
same in most languages. Less common (and the less users care) is
when either input is negative.
Negative divisor is particularly rare. Didn't Forth, Inc. use to have
signed-by-unsigned division words?
All polyForth MOD words were unsigned. You may be thinking of this
algorithm for floored which appeared in cmForth:
: F/MOD ( n +n|u -- urem nquot )
>r s>d dup 0< if r@ + then r> um/mod ;
albert@cherry.(none) (albert) writes:
What I meant was that the equivalence classes modulo need to be
presented by a positive number.
13%-3 needs to be 1, which is correct in golang but not in Python.
At least not in version 2.7.
Has that changed in version 3?
Python 3.9.2:
(-5, -2)divmod(13,-3)
What do you want 13 // -3 to be? -5 is what you get from floored
division, in which case the remainder has to be -2.
Mathematically I'd like all mod result positive and smaller than
the absolute value of the divider.
albert@cherry.(none) (albert) writes:
Mathematically I'd like all mod result positive and smaller than
the absolute value of the divider.
I guess that has some attractions but mathematically, what does modulo
by a negative number even mean? When the modulus is a positive number,
you are mapping the integers to a quotient ring, ok fine. But doing
that with a negative number makes less sense, unless I'm missing
something.
In article <tdtju1$125o$1@gioia.aioe.org>, dxforth <dxforth@gmail.com> wrote:
On 22/08/2022 00:07, Anton Ertl wrote:
dxforth <dxforth@gmail.com> writes:
Most users want to divide positive by positive and the result is the
same in most languages. Less common (and the less users care) is
when either input is negative.
Negative divisor is particularly rare. Didn't Forth, Inc. use to have
signed-by-unsigned division words?
All polyForth MOD words were unsigned. You may be thinking of this
algorithm for floored which appeared in cmForth:
: F/MOD ( n +n|u -- urem nquot )
>r s>d dup 0< if r@ + then r> um/mod ;
The stack diagram is misleading.
It is ( n u -- urem nquot )
Klarokay that is has to work with positive integers, being a subset
with the same value and the same bitpatterm. as an unsigned integer.
In article <87edxaxptc.fsf@nightsong.com>,
Paul Rubin <no.email@nospam.invalid> wrote:
albert@cherry.(none) (albert) writes:
What I meant was that the equivalence classes modulo need to be
presented by a positive number.
13%-3 needs to be 1, which is correct in golang but not in Python.
At least not in version 2.7.
Has that changed in version 3?
Python 3.9.2:
>>> divmod(13,-3)
(-5, -2)
What do you want 13 // -3 to be? -5 is what you get from floored
division, in which case the remainder has to be -2.
Mathematically I'd like all mod result positive and smaller than
the absolute value of the divider.
Apparently that is no option.
floored and symmetric are the only games in town.
Rarely
does one see languages offering Euclidean division 'out of the box'
as (presumably) the cost/benefit isn't there.
albert@cherry.(none) (albert) writes:
Mathematically I'd like all mod result positive and smaller than
the absolute value of the divider.
I guess that has some attractions but mathematically, what does modulo
by a negative number even mean? When the modulus is a positive number,
you are mapping the integers to a quotient ring, ok fine. But doing
that with a negative number makes less sense, unless I'm missing
something.
dxforth <dxforth@gmail.com> writes:
Rarely
does one see languages offering Euclidean division 'out of the box'
as (presumably) the cost/benefit isn't there.
The number of occurences in the table in <https://en.wikipedia.org/wiki/Modulo_operation#In_programming_languages>
is:
97 Truncated (symmetric)
58 Floored
12 Euclidean
A number of languages have several. The Forth standard specified that
/, mod etc. have to be either floored or symmetric, so if someone
thinks that Euclidean is worth the extra effort, they should add that
with separate names, e.g. /e, mode, em/mod (note that development
Gforth has /f /s modf mods etc.).
On 22/08/2022 17:04, Anton Ertl wrote:
dxforth <dxforth@gmail.com> writes:
Rarely
does one see languages offering Euclidean division 'out of the box'
as (presumably) the cost/benefit isn't there.
The number of occurences in the table in
<https://en.wikipedia.org/wiki/Modulo_operation#In_programming_languages>
is:
97 Truncated (symmetric)
58 Floored
12 Euclidean
A number of languages have several. The Forth standard specified that
/, mod etc. have to be either floored or symmetric, so if someone
thinks that Euclidean is worth the extra effort, they should add that
with separate names, e.g. /e, mode, em/mod (note that development
Gforth has /f /s modf mods etc.).
It suffices the majority of languages to have one. Why not Forth?
On 22/08/2022 13:57, dxforth wrote:
On 22/08/2022 17:04, Anton Ertl wrote:
dxforth <dxforth@gmail.com> writes:
Rarely
does one see languages offering Euclidean division 'out of the box'
as (presumably) the cost/benefit isn't there.
The number of occurences in the table in
<https://en.wikipedia.org/wiki/Modulo_operation#In_programming_languages> >>> is:
97 Truncated (symmetric)
58 Floored
12 Euclidean
A number of languages have several. The Forth standard specified that
/, mod etc. have to be either floored or symmetric, so if someone
thinks that Euclidean is worth the extra effort, they should add that
with separate names, e.g. /e, mode, em/mod (note that development
Gforth has /f /s modf mods etc.).
It suffices the majority of languages to have one. Why not Forth?
I've appreciated this discussion, and ended up reviewing how 8th does mod and /mod. It turns out there were discrepancies which I've fixed for the next release.
In particular: there was a long time ago a discussion in 8th requesting that 'mod' always give a positive value (because it's often used to calculate an array offset or the like). Since it makes as much sense mathematically, I did that. But...
... I didn't make sure that the result of /mod obeyed the modulo relation, e.g. that "n m mod" producing "r q" on the stack such that
n = (q*m) + r
I fixed that; and then realized that the results of /mod were different (though all mathematically correct) across the different numeric types in 8th. So I've now fixed that.
And to think I studied a lot of math back in the day...
On 23/08/2022 16:06, Ron AARON wrote:
On 22/08/2022 13:57, dxforth wrote:
On 22/08/2022 17:04, Anton Ertl wrote:
dxforth <dxforth@gmail.com> writes:
Rarely
does one see languages offering Euclidean division 'out of the box'
as (presumably) the cost/benefit isn't there.
The number of occurences in the table in
<https://en.wikipedia.org/wiki/Modulo_operation#In_programming_languages> >>>>
is:
97 Truncated (symmetric)
58 Floored
12 Euclidean
A number of languages have several. The Forth standard specified that >>>> /, mod etc. have to be either floored or symmetric, so if someone
thinks that Euclidean is worth the extra effort, they should add that
with separate names, e.g. /e, mode, em/mod (note that development
Gforth has /f /s modf mods etc.).
It suffices the majority of languages to have one. Why not Forth?
I've appreciated this discussion, and ended up reviewing how 8th does
mod and /mod. It turns out there were discrepancies which I've fixed
for the next release.
In particular: there was a long time ago a discussion in 8th
requesting that 'mod' always give a positive value (because it's often
used to calculate an array offset or the like). Since it makes as much
sense mathematically, I did that. But...
Not to dampen the enthusiasm of your users, here's an expert's somewhat
more nuanced opinion:
"As a mathematician I was asked about the arithmetic words. I did write
some comments at the request of a Team member to assist his presentation
-- and I also told the Team that, from a mathematicians view, it is more
important that arithmetic operations act in a specific and uniform way
across all systems than in the precise nature of action." - John Wavrik
... I didn't make sure that the result of /mod obeyed the modulo
relation, e.g. that "n m mod" producing "r q" on the stack such that
n = (q*m) + r
I fixed that; and then realized that the results of /mod were
different (though all mathematically correct) across the different
numeric types in 8th. So I've now fixed that.
And to think I studied a lot of math back in the day...
It appears 8th could do with a 'Hayes tester' :)
On 24/08/2022 8:40, dxforth wrote:
On 23/08/2022 16:06, Ron AARON wrote:
On 22/08/2022 13:57, dxforth wrote:
On 22/08/2022 17:04, Anton Ertl wrote:
dxforth <dxforth@gmail.com> writes:
Rarely
does one see languages offering Euclidean division 'out of the box' >>>>>> as (presumably) the cost/benefit isn't there.
The number of occurences in the table in
<https://en.wikipedia.org/wiki/Modulo_operation#In_programming_languages> >>>>> is:
97 Truncated (symmetric)
58 Floored
12 Euclidean
A number of languages have several. The Forth standard specified that >>>>> /, mod etc. have to be either floored or symmetric, so if someone
thinks that Euclidean is worth the extra effort, they should add that >>>>> with separate names, e.g. /e, mode, em/mod (note that development
Gforth has /f /s modf mods etc.).
It suffices the majority of languages to have one. Why not Forth?
I've appreciated this discussion, and ended up reviewing how 8th does mod and /mod. It turns out there were discrepancies which I've fixed for the next release.
In particular: there was a long time ago a discussion in 8th requesting that 'mod' always give a positive value (because it's often used to calculate an array offset or the like). Since it makes as much sense mathematically, I did that. But...
Not to dampen the enthusiasm of your users, here's an expert's somewhat
more nuanced opinion:
"As a mathematician I was asked about the arithmetic words. I did write >> some comments at the request of a Team member to assist his presentation
-- and I also told the Team that, from a mathematicians view, it is more
important that arithmetic operations act in a specific and uniform way >> across all systems than in the precise nature of action." - John Wavrik
Well, yes. But mathematicians are a tiny, tiny, portion of (my) users. As long as the behavior is consistent and provably correct, everyone (should be) happy.
On 24/08/2022 15:44, Ron AARON wrote:
On 24/08/2022 8:40, dxforth wrote:
On 23/08/2022 16:06, Ron AARON wrote:
On 22/08/2022 13:57, dxforth wrote:
On 22/08/2022 17:04, Anton Ertl wrote:
dxforth <dxforth@gmail.com> writes:
Rarely
does one see languages offering Euclidean division 'out of the box' >>>>>>> as (presumably) the cost/benefit isn't there.
The number of occurences in the table in
<https://en.wikipedia.org/wiki/Modulo_operation#In_programming_languages>
is:
97 Truncated (symmetric)
58 Floored
12 Euclidean
A number of languages have several. The Forth standard specified >>>>>> that
/, mod etc. have to be either floored or symmetric, so if someone
thinks that Euclidean is worth the extra effort, they should add that >>>>>> with separate names, e.g. /e, mode, em/mod (note that development
Gforth has /f /s modf mods etc.).
It suffices the majority of languages to have one. Why not Forth?
I've appreciated this discussion, and ended up reviewing how 8th
does mod and /mod. It turns out there were discrepancies which I've
fixed for the next release.
In particular: there was a long time ago a discussion in 8th
requesting that 'mod' always give a positive value (because it's
often used to calculate an array offset or the like). Since it makes
as much sense mathematically, I did that. But...
Not to dampen the enthusiasm of your users, here's an expert's somewhat
more nuanced opinion:
"As a mathematician I was asked about the arithmetic words. I did
write
some comments at the request of a Team member to assist his
presentation
-- and I also told the Team that, from a mathematicians view, it
is more
important that arithmetic operations act in a specific and uniform
way
across all systems than in the precise nature of action." - John
Wavrik
Well, yes. But mathematicians are a tiny, tiny, portion of (my) users.
As long as the behavior is consistent and provably correct, everyone
(should be) happy.
Not everyone was happy with Forth-83 (or ANS). 8th users must be of a different
breed :)
the expression x(modulo 3) is in fact the infinite set
{ ... x-2*3 x-1*3 x x+1*3 x+2*3 ... }
albert@cherry.(none) (albert) writes:
the expression x(modulo 3) is in fact the infinite set
{ ... x-2*3 x-1*3 x x+1*3 x+2*3 ... }
That is an interesting way to define the mod function, but it means that
x mod 0 is the singleton {x}. What should happen on X 0 MOD ?
In article <87pmglz9r9.fsf@nightsong.com>,...
Paul Rubin <no.email@nospam.invalid> wrote:
albert@cherry.(none) (albert) writes:
the expression x(modulo 3) is in fact the infinite set
{ ... x-2*3 x-1*3 x x+1*3 x+2*3 ... }
I showed the definition to stress that modulo sets are not functions.
It is good that the expression x%y is used, in c family.
That is an operator that yield a result that is of the same type
of x and y, meaning the least representant r such that
r is equivalent to x with respect to the modulus y,
and that 0<=r<=y .
I don't like the use mod in pascal/modula and Forth, because
it is used as an infix operator.
Problems like "what is 2^100 (modulo 5) " actually ask for the
remainder if 2^100 is divided by 5, not for the infinite set.
So the mathematicians are themselves sloppy.
albert@cherry.(none) (albert) writes:
In article <87pmglz9r9.fsf@nightsong.com>,...
Paul Rubin <no.email@nospam.invalid> wrote:
albert@cherry.(none) (albert) writes:
the expression x(modulo 3) is in fact the infinite set
{ ... x-2*3 x-1*3 x x+1*3 x+2*3 ... }
I showed the definition to stress that modulo sets are not functions.
The notation I learned in school is neither a function nor a set, it's
an equivalence relation:
a ≡ b (mod N)
spoken "a is congruent to b modulo N". In terms of sets, there are N
sets modulo N, and if a and b are from the same set, they are
congruent modulo N. These N sets can be represented by, e.g., the
numbers 0..N-1, or the numbers -N+1..0, or any other numbers. For
checking congruence, it does not matter, as long as you use only one
number to represent the set. For other uses, it makes a difference.
BTW, if you define that modulo is an operation that has a set as a
result, it is a function, just as if you define it with a number as
result.
- anton--
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html >comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2022: https://euro.theforth.net
The notation I learned in school is neither a function nor a set, it's
an equivalence relation:
a ≡ b (mod N)
spoken "a is congruent to b modulo N". In terms of sets, there are N
sets modulo N, and if a and b are from the same set, they are
congruent modulo N. These N sets can be represented by, e.g., the
numbers 0..N-1, or the numbers -N+1..0, or any other numbers. For
checking congruence, it does not matter, as long as you use only one
number to represent the set. For other uses, it makes a difference.
Likewise, you can represent the set of natural or integer numbers that
are congruent modulo N by one number, which happens to be the
remainder of integer division.
With that desired property, symmetric MOD is not ok (it produces two different results that represent the same set for a given N), while
floored and "Euclidean" are ok.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 37:45:17 |
| Calls: | 6,708 |
| Calls today: | 1 |
| Files: | 12,241 |
| Messages: | 5,353,507 |