anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

> Ivan Godard <ivan@millcomputing.com> writes:
>
>> On 3/20/2023 7:20 AM, Anton Ertl wrote:
>>
>>> Ivan Godard <ivan@millcomputing.com> writes:
>>>
>>>> (-1)/2 is not a shift except in ones-comp and sign-mag.
>>>
>>> Sure is:
>>>
>>> -1 2 / .
>>> -1 1 arshift .
>>>
>>> Running Gforth 0.7.9_20230317, both output "-1".
>>>
>>> Do you mean to tell me that the Mill has all kinds of options for
>>> dealing with overflow, but does not support floored or Euclidean (same
>>> results for positive divisors) division?
>>
>> Looks like you assume round toward -inf. Why?
>
> Because it has much nicer behaviour when the dividend crosses 0 than
> round-towards-0 has:
>
> round-towards-0 (aka truncated):
>
> https://en.wikipedia.org/wiki/File:Divmod_truncated.svg
>
> round towards -inf (floored):
>
> https://en.wikipedia.org/wiki/File:Divmod_floored.svg

Nicer behavior is in the eye of the beholder.

The graph for round towards -inf may look more pleasing to
the eye.

But round towards zero is mathematically nicer:

(-x)/y == - (x/y)

To me the mathematical picture is the more important one.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
[floored division]
>> Because it has much nicer behaviour when the dividend crosses 0 than
>> round-towards-0 has:
>>
>> round-towards-0 (aka truncated):
>>
>> https://en.wikipedia.org/wiki/File:Divmod_truncated.svg
>>
>> round towards -inf (floored):
>>
>> https://en.wikipedia.org/wiki/File:Divmod_floored.svg
>
>Nicer behavior is in the eye of the beholder.
>
>The graph for round towards -inf may look more pleasing to
>the eye.
>
>But round towards zero is mathematically nicer:
>
> (-x)/y == - (x/y)

But round towards -inf is mathematically nicer:

(x+y)/y = (x/y)+1

And in practice, that's more frequently useful.

>To me the mathematical picture is the more important one.

People who prefer floored or Euklidean division also give mathematical
arguments.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Friday, July 21, 2023 at 8:39:44 AM UTC+3, Anton Ertl wrote:
> Tim Rentsch <tr.1...@z991.linuxsc.com> writes:
> >an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> [floored division]
> >> Because it has much nicer behaviour when the dividend crosses 0 than
> >> round-towards-0 has:
> >>
> >> round-towards-0 (aka truncated):
> >>
> >> https://en.wikipedia.org/wiki/File:Divmod_truncated.svg
> >>
> >> round towards -inf (floored):
> >>
> >> https://en.wikipedia.org/wiki/File:Divmod_floored.svg
> >
> >Nicer behavior is in the eye of the beholder.
> >
> >The graph for round towards -inf may look more pleasing to
> >the eye.
> >
> >But round towards zero is mathematically nicer:
> >
> > (-x)/y == - (x/y)
> But round towards -inf is mathematically nicer:
>
> (x+y)/y = (x/y)+1
>
> And in practice, that's more frequently useful.

Yes. For me the most important advantage is ease of
implementing a ratio rounded to nearest.
Assuming positive y and flooring division it's as simple as
rnd_rat = (2*x + y)/(2*y)
I know of no similarly simple way with truncating division.

However, it seems that in majority of programming/HDL
languages truncating division won.

> >To me the mathematical picture is the more important one.
> People who prefer floored or Euklidean division also give mathematical
> arguments.
>
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

Michael S <already5chosen@yahoo.com> writes:
>However, it seems that in majority of programming/HDL
>languages truncating division won.

I don't have an easy way to count the entries in the table at
<https://en.wikipedia.org/wiki/Modulo#In_programming_languages>, but
it seems to me that a lot of languages offer several options:
Truncated (symmetric) and one of floored or Euclidean (which produce
the same results for positive divisors); some only offer truncated,
but some also offer only floored (APL, COBOL, J, LibreOffice, Lua 5,
Mathcad, Mathematica, Excel, MiniTab, MUMPS, PL/1, R, Raku, Scratch,
Snap!, Spin, Solidity, Tcl, Turing) or only Euclidean (ABAP, Algol 68,
PureScript, Stata, Z3).

[Tim Rentsch:]
>> >To me the mathematical picture is the more important one.

It's interesting that the more mathematically-oriented languages like
APL, J, Mathcad, Mathematica, R, and Z3 don't even provide truncated
remainder, so I guess that the "mathematical picture" argues against
truncated (round-towards-0) division.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Friday, July 21, 2023 at 4:09:35 PM UTC+3, Anton Ertl wrote:
> Michael S <already...@yahoo.com> writes:
> >However, it seems that in majority of programming/HDL
> >languages truncating division won.
> I don't have an easy way to count the entries in the table at
> <https://en.wikipedia.org/wiki/Modulo#In_programming_languages>, but
> it seems to me that a lot of languages offer several options:
> Truncated (symmetric) and one of floored or Euclidean (which produce
> the same results for positive divisors); some only offer truncated,
> but some also offer only floored (APL, COBOL, J, LibreOffice, Lua 5,
> Mathcad, Mathematica, Excel, MiniTab, MUMPS, PL/1, R, Raku, Scratch,
> Snap!, Spin, Solidity, Tcl, Turing) or only Euclidean (ABAP, Algol 68,
> PureScript, Stata, Z3).
>
> [Tim Rentsch:]
> >> >To me the mathematical picture is the more important one.
> It's interesting that the more mathematically-oriented languages like
> APL, J, Mathcad, Mathematica, R, and Z3 don't even provide truncated
> remainder, so I guess that the "mathematical picture" argues against
> truncated (round-towards-0) division.
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

I never used any of those languages . There is non-zero chance that I'd
learn R eventually. For the rest of them, I don't see a reason.
The only "mathematically-oriented" language that I use regularly (daily) is
Matlab/Octave. It seems that Matlab does not have integer division operation
at all. In Octave it can be achieved although I'd guess that majority of users
are not aware of that. It is truncating which is not surprising given Fortran
heritage of Matlab and Fortran/C heritage of Octave.

Michael S <already5chosen@yahoo.com> writes:
>On Friday, July 21, 2023 at 4:09:35=E2=80=AFPM UTC+3, Anton Ertl wrote:
>> <https://en.wikipedia.org/wiki/Modulo#In_programming_languages>, but=20
....
>The only "mathematically-oriented" language that I use regularly (daily) is=
>=20
>Matlab/Octave. It seems that Matlab does not have integer division operatio=
>n
>at all.

According to the page above, MATLAB has mod (floored) and rem
(truncated). Octave is not listed.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Friday, July 21, 2023 at 5:31:11 PM UTC+3, Anton Ertl wrote:
> Michael S <already...@yahoo.com> writes:
> >On Friday, July 21, 2023 at 4:09:35=E2=80=AFPM UTC+3, Anton Ertl wrote:
> >> <https://en.wikipedia.org/wiki/Modulo#In_programming_languages>, but=20
> ...
> >The only "mathematically-oriented" language that I use regularly (daily) is=
> >=20
> >Matlab/Octave. It seems that Matlab does not have integer division operatio=
> >n
> >at all.
>
> According to the page above, MATLAB has mod (floored) and rem
> (truncated). Octave is not listed.
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

Matlab (and Octave) rem() and mod() are floating point operations rather
than integer.

Michael S <already5chosen@yahoo.com> writes:
>On Friday, July 21, 2023 at 5:31:11=E2=80=AFPM UTC+3, Anton Ertl wrote:
>> Michael S <already...@yahoo.com> writes:=20
>> >On Friday, July 21, 2023 at 4:09:35=3DE2=3D80=3DAFPM UTC+3, Anton Ertl w=
>rote:=20
>> >> <https://en.wikipedia.org/wiki/Modulo#In_programming_languages>
....
>> According to the page above, MATLAB has mod (floored) and rem=20
>> (truncated). Octave is not listed.
....
>Matlab (and Octave) rem() and mod() are floating point operations rather
>than integer.=20

The page above is not limited to integer operations. And neither is
the issue at hand: is the quotient rounded towards 0 or towards -inf.

However, the page above lists the MATLAB mod and rem as integer, not
floating-point operations. As a MATLAB user you may want to correct
this (and maybe add Octave).

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

According to Michael S <already5chosen@yahoo.com>:
>However, it seems that in majority of programming/HDL
>languages truncating division won.

I suspect that's an ancient artifact of Fortran originally being
implemented on a machine that did (mostly) sign-magnitude arithmetic.

I also suspect too many programming language designers don't know
enough about numerical analysis to make an informed choice between the
two.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

John Levine <johnl@taugh.com> writes:
>According to Michael S <already5chosen@yahoo.com>:
>>However, it seems that in majority of programming/HDL
>>languages truncating division won.
>
>I suspect that's an ancient artifact of Fortran originally being
>implemented on a machine that did (mostly) sign-magnitude arithmetic.

I suspect so, too. So there's an interesting sequence of events:

* Early architectures used sign-magnitude, where truncated/symmetric
division is easiest to implement, and therefore they implemented
symmetric division.

* Fortran wanted to be close to the machine, and therefore also
implemented truncated division.

* So when architectures switched to two's complement, where floored is
not harder to implement than truncated, those who implemented signed
division implemented truncated division for Fortran compatibility.

It's interesting that COBOL and APL, both from the time before the
switch to 2s-complement, implement floored division according to
<https://en.wikipedia.org/wiki/Modulo#In_programming_languages>

>I also suspect too many programming language designers don't know
>enough about numerical analysis to make an informed choice between the
>two.

Forth is an interesting case:

In the Forth-79 standard the division words /, MOD and /MOD are
defined as "round towards 0" (i.e., truncated).

Forth-83 defined division to be floored.

Finally, since Forth-94, it's up to the implementation whether /, MOD,
and /MOD are floored or symmetric (truncated); basically this means
that in portable programs you better use these words only with
positive operands (and that's probably what the majority of uses were
earlier). If you want to write reliable code where the operands can
have different signs, Forth-94 provides FM/MOD (floored) and SM/REM
(symmetric/truncated).

There is also UM/MOD (unsigned) and some implementations have IIRC a
signed/unsigned division, but I don't remember whether they implement
it symmetric or floored.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
>>I suspect that's an ancient artifact of Fortran originally being
>>implemented on a machine that did (mostly) sign-magnitude arithmetic.
>
>I suspect so, too. So there's an interesting sequence of events: ...
>It's interesting that COBOL and APL, both from the time before the
>switch to 2s-complement, implement floored division according to
><https://en.wikipedia.org/wiki/Modulo#In_programming_languages>

For APL it's not surprising. Ken Iverson was a mathematician before he
switched to computing in 1951 working with Howard Aiken and Wassily
Leontief. (If I'd had a chance to work them them, I'd have switched too.)

APL was originally just a paper algorithm language, and wasn't
implemented until several years after Iverson's book came out. So it's
not surprising that it's defined in a way that makes sense mathematically.

The 1960 COBOL report says that "The least significant digit of the
result field will be increased by 1 whenever the most significant
digit of the excess is greater than or equal to 5." unless you say
UNROUNDED in which case it's truncated. Bitsavers is a bit spase on
COBOL but a 1976 IBM DOS COBOL manual says the same thing, with no
mention of a MOD function. Dunno where it came from.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>
> [floored division]
>
>>> Because it has much nicer behaviour when the dividend crosses 0
>>> than round-towards-0 has:
>>>
>>> round-towards-0 (aka truncated):
>>>
>>> https://en.wikipedia.org/wiki/File:Divmod_truncated.svg
>>>
>>> round towards -inf (floored):
>>>
>>> https://en.wikipedia.org/wiki/File:Divmod_floored.svg
>>
>> Nicer behavior is in the eye of the beholder.
>>
>> The graph for round towards -inf may look more pleasing to
>> the eye.
>>
>> But round towards zero is mathematically nicer:
>>
>> (-x)/y == - (x/y)
>
> But round towards -inf is mathematically nicer:
>
> (x+y)/y = (x/y)+1

Doesn't look nicer to me.

> And in practice, that's more frequently useful.

I dispute that assertion.

>> To me the mathematical picture is the more important one.
>
> People who prefer floored or Euklidean division also give
> mathematical arguments.

No doubt there exist environments where either is more
convenient. In my experience in the programming
domain, rounding towards zero is more consistent
with the law of least astonishment.

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

> [Tim Rentsch:]
>
>>>> To me the mathematical picture is the more important one.
>
> It's interesting that the more mathematically-oriented languages
> like APL, J, Mathcad, Mathematica, R, and Z3 don't even provide
> truncated remainder, so I guess that the "mathematical picture"
> argues against truncated (round-towards-0) division.

It's interesting that in C90 which way division worked was
allowed to be implementation defined, but in C99 and later
division is required to be truncating division.

(For integers, of course. Floating point is another story
altogether.)

On Friday, July 21, 2023 at 4:39:36 PM UTC+3, Michael S wrote:
> On Friday, July 21, 2023 at 4:09:35 PM UTC+3, Anton Ertl wrote:
> > Michael S <already...@yahoo.com> writes:
> > >However, it seems that in majority of programming/HDL
> > >languages truncating division won.
> > I don't have an easy way to count the entries in the table at
> > <https://en.wikipedia.org/wiki/Modulo#In_programming_languages>, but
> > it seems to me that a lot of languages offer several options:
> > Truncated (symmetric) and one of floored or Euclidean (which produce
> > the same results for positive divisors); some only offer truncated,
> > but some also offer only floored (APL, COBOL, J, LibreOffice, Lua 5,
> > Mathcad, Mathematica, Excel, MiniTab, MUMPS, PL/1, R, Raku, Scratch,
> > Snap!, Spin, Solidity, Tcl, Turing) or only Euclidean (ABAP, Algol 68,
> > PureScript, Stata, Z3).
> >
> > [Tim Rentsch:]
> > >> >To me the mathematical picture is the more important one.
> > It's interesting that the more mathematically-oriented languages like
> > APL, J, Mathcad, Mathematica, R, and Z3 don't even provide truncated
> > remainder, so I guess that the "mathematical picture" argues against
> > truncated (round-towards-0) division.
> > - anton
> > --
> > 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> > Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>
> I never used any of those languages . There is non-zero chance that I'd
> learn R eventually. For the rest of them, I don't see a reason.
> The only "mathematically-oriented" language that I use regularly (daily) is
> Matlab/Octave. It seems that Matlab does not have integer division operation
> at all. In Octave it can be achieved although I'd guess that majority of users
> are not aware of that. It is truncating which is not surprising given Fortran
> heritage of Matlab and Fortran/C heritage of Octave.

Above I was wrong.
After closer examination I understood that there is no difference between Matlab
and Octave scripts - integer division is absent in both of them.
What I originally confused for integer division in Octave was in fact a floating point
(binary64) division followed by rounding of result to nearest integer with ties broken
away from zero.

On Sunday, July 23, 2023 at 3:30:17 PM UTC+3, Michael S wrote:
> On Friday, July 21, 2023 at 4:39:36 PM UTC+3, Michael S wrote:
> > On Friday, July 21, 2023 at 4:09:35 PM UTC+3, Anton Ertl wrote:
> > > Michael S <already...@yahoo.com> writes:
> > > >However, it seems that in majority of programming/HDL
> > > >languages truncating division won.
> > > I don't have an easy way to count the entries in the table at
> > > <https://en.wikipedia.org/wiki/Modulo#In_programming_languages>, but
> > > it seems to me that a lot of languages offer several options:
> > > Truncated (symmetric) and one of floored or Euclidean (which produce
> > > the same results for positive divisors); some only offer truncated,
> > > but some also offer only floored (APL, COBOL, J, LibreOffice, Lua 5,
> > > Mathcad, Mathematica, Excel, MiniTab, MUMPS, PL/1, R, Raku, Scratch,
> > > Snap!, Spin, Solidity, Tcl, Turing) or only Euclidean (ABAP, Algol 68,
> > > PureScript, Stata, Z3).
> > >
> > > [Tim Rentsch:]
> > > >> >To me the mathematical picture is the more important one.
> > > It's interesting that the more mathematically-oriented languages like
> > > APL, J, Mathcad, Mathematica, R, and Z3 don't even provide truncated
> > > remainder, so I guess that the "mathematical picture" argues against
> > > truncated (round-towards-0) division.
> > > - anton
> > > --
> > > 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> > > Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>
> > I never used any of those languages . There is non-zero chance that I'd
> > learn R eventually. For the rest of them, I don't see a reason.
> > The only "mathematically-oriented" language that I use regularly (daily) is
> > Matlab/Octave. It seems that Matlab does not have integer division operation
> > at all. In Octave it can be achieved although I'd guess that majority of users
> > are not aware of that. It is truncating which is not surprising given Fortran
> > heritage of Matlab and Fortran/C heritage of Octave.
> Above I was wrong.
> After closer examination I understood that there is no difference between Matlab
> and Octave scripts - integer division is absent in both of them.
> What I originally confused for integer division in Octave was in fact a floating point
> (binary64) division followed by rounding of result to nearest integer with ties broken
> away from zero.

More experiments proved that what I said above is also incorrect.
64-bit integer numbers are not converted to IEEE binary64 floats before division.
They somehow preserve all bits of precision. So, it seems that both Matlab and Octave
do have integer division after all or at least something that is very similar to integer division.
And result of division is rounded to nearest with ties broken away from zero.

Michael S <already5chosen@yahoo.com> schrieb:

> 64-bit integer numbers are not converted to IEEE binary64 floats before division.
> They somehow preserve all bits of precision. So, it seems that both Matlab and Octave
> do have integer division after all or at least something that is very similar to integer division.
> And result of division is rounded to nearest with ties broken away from zero.

A weird mixture between floating point and integer arithmetic...

What would be the right term for that, maybe "floppy point arithmetic"?