On Sunday, 26 June 2016 at 00:54:04 UTC, Guillaume Boucher wrote:
If division truncates towards negative infinity, the remainder
will always be nonegative (in case of a positive divisor).
Or even better, use euclidean division, then the reminder always
remains non-negative:
https://en.wikipe
On Sunday, 26 June 2016 at 05:28:53 UTC, Shachar Shemesh wrote:
So, we can do it your way. This would mean:
1. Losing performance for every division and modulus that
*might* be negative
I don't think the performance issue is relevant. It was relevant
when it was left implementation defined in
On Sunday, 26 June 2016 at 05:44:53 UTC, deadalnix wrote:
Except for mathematica, these are all irrelevant. The claim is
that programming languages and CPU define % in some way, not
that mathematician do it the same way.
Well, the CPU does not define it. It is just that C botchered it
by leav
On Sunday, 26 June 2016 at 04:25:07 UTC, "Smoke" Adams wrote:
Languages:
C#: https://msdn.microsoft.com/en-us/library/0w4e0fzs.aspx
Java:
https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.17.3
C11:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/C99RationaleV5.10.pdf (See 6.5
What deadalnix (how did you choose a nickname that is more difficult to
write than your given name anyway?) said was that the definition of %
only makes sense if, for every n and every m:
(n/m)+(n%m)=n
What this means is that, if n/m is rounded up for negative numbers, n%m
must be negative.
On Sunday, 26 June 2016 at 03:54:28 UTC, deadalnix wrote:
On Sunday, 26 June 2016 at 02:05:53 UTC, "Smoke" Adams wrote:
On Sunday, 26 June 2016 at 00:31:29 UTC, deadalnix wrote:
On Saturday, 25 June 2016 at 23:01:00 UTC, "Smoke" Adams
wrote:
This proves nothing.
This isn't a proof, this is
On Sunday, 26 June 2016 at 02:05:53 UTC, "Smoke" Adams wrote:
On Sunday, 26 June 2016 at 00:31:29 UTC, deadalnix wrote:
On Saturday, 25 June 2016 at 23:01:00 UTC, "Smoke" Adams wrote:
This proves nothing.
This isn't a proof, this is a definition. This is the
definition that is used by all p
On Sunday, 26 June 2016 at 00:31:29 UTC, deadalnix wrote:
On Saturday, 25 June 2016 at 23:01:00 UTC, "Smoke" Adams wrote:
This proves nothing.
This isn't a proof, this is a definition. This is the
definition that is used by all programming languages out there
and all CPUs. It isn't going to
On 26.06.2016 02:54, Guillaume Boucher wrote:
On Friday, 24 June 2016 at 20:43:38 UTC, deadalnix wrote:
Most reasonable is
numerator = quotient * divisor + remainder
Which means it can be negative.
Depends on the definition.
If division truncates towards negative infinity, the remainder wil
On Friday, 24 June 2016 at 20:43:38 UTC, deadalnix wrote:
Most reasonable is
numerator = quotient * divisor + remainder
Which means it can be negative.
Depends on the definition.
If division truncates towards negative infinity, the remainder
will always be nonegative (in case of a positive
On Saturday, 25 June 2016 at 23:01:00 UTC, "Smoke" Adams wrote:
This proves nothing.
This isn't a proof, this is a definition. This is the definition
that is used by all programming languages out there and all CPUs.
It isn't going to change because someone on the internet think he
has a bet
On Friday, 24 June 2016 at 20:43:38 UTC, deadalnix wrote:
On Friday, 24 June 2016 at 20:33:45 UTC, Andrei Alexandrescu
wrote:
In a checked environment, division may "overflow", e.g. -6 /
2u must be typed as uint but is not representable properly one.
How about remainder? I suppose one can make
On 24.06.2016 22:33, Andrei Alexandrescu wrote:
In a checked environment, division may "overflow", e.g. -6 / 2u must be
typed as uint but is not representable properly one.
How about remainder? I suppose one can make the argument that remainder
should never overflow (save for rhs == 0),
Well,
On Friday, 24 June 2016 at 20:43:38 UTC, deadalnix wrote:
Most reasonable is
numerator = quotient * divisor + remainder
Which means it can be negative.
Example:
void main()
{
int x1 = 2;
int x2 = -2;
uint x3 = 2;
assert(-7 % x1 == -1);
assert
On Friday, 24 June 2016 at 20:33:45 UTC, Andrei Alexandrescu
wrote:
In a checked environment, division may "overflow", e.g. -6 / 2u
must be typed as uint but is not representable properly one.
How about remainder? I suppose one can make the argument that
remainder should never overflow (save f
In a checked environment, division may "overflow", e.g. -6 / 2u must be
typed as uint but is not representable properly one.
How about remainder? I suppose one can make the argument that remainder
should never overflow (save for rhs == 0), because it could be defined
with either a positive or
16 matches
Mail list logo
