On Thursday, 19 July 2018 at 10:14:34 UTC, Dominikus Dittes
Scherkl wrote:
On Wednesday, 18 July 2018 at 17:30:21 UTC, Jonathan M Davis
wrote:
On Tuesday, July 17, 2018 21:18:12 John Colvin via
Digitalmars-d wrote:
Just do what std.typecons.Proxy does and return float.nan for
the incomparable
On Wednesday, 18 July 2018 at 17:49:19 UTC, H. S. Teoh wrote:
On Wed, Jul 18, 2018 at 11:30:21AM -0600, Jonathan M Davis via
On the other hand, if opCmp is allowed to return a user-defined
type, it would solve the problem in a neat way: just define a
quaternary type that encapsulates the
On Wednesday, 18 July 2018 at 17:30:21 UTC, Jonathan M Davis
wrote:
On Tuesday, July 17, 2018 21:18:12 John Colvin via
Digitalmars-d wrote:
Just do what std.typecons.Proxy does and return float.nan for
the incomparable case.
Since when is that legal? I thought that it was required for
opCmp
On Wednesday, 18 July 2018 at 15:13:24 UTC, rikki cattermole
wrote:
On 19/07/2018 3:03 AM, Ivan Kazmenko wrote:
That's by DMD32 on Windows. (Sorry, my DMD64 broke after
upgrading Visual Studio to 2017, and I failed to fix it right
now. Anyway, it's not like x86_64 uses a different set of
On Wed, Jul 18, 2018 at 11:30:21AM -0600, Jonathan M Davis via Digitalmars-d
wrote:
> On Tuesday, July 17, 2018 21:18:12 John Colvin via Digitalmars-d wrote:
> > Just do what std.typecons.Proxy does and return float.nan for the
> > incomparable case.
>
> Since when is that legal? I thought that
On Tuesday, July 17, 2018 21:18:12 John Colvin via Digitalmars-d wrote:
> Just do what std.typecons.Proxy does and return float.nan for the
> incomparable case.
Since when is that legal? I thought that it was required for opCmp to return
int. Certainly, the spec implies that it has to be int. The
On 19/07/2018 3:03 AM, Ivan Kazmenko wrote:
That's by DMD32 on Windows. (Sorry, my DMD64 broke after upgrading
Visual Studio to 2017, and I failed to fix it right now. Anyway, it's
not like x86_64 uses a different set of general purpose floating-point
hardware, right?)
Boy do I ever have
On Wednesday, 18 July 2018 at 14:02:28 UTC, Dominikus Dittes
Scherkl wrote:
On Wednesday, 18 July 2018 at 13:12:05 UTC, Ivan Kazmenko wrote:
Leaving x uninitialized, or using floats, work about the same.
No, floats are a whole lot less slow.
Are they? Locally, I don't see much difference.
On Wednesday, 18 July 2018 at 13:12:05 UTC, Ivan Kazmenko wrote:
On Tuesday, 17 July 2018 at 21:18:12 UTC, John Colvin wrote:
Just do what std.typecons.Proxy does and return float.nan for
the incomparable case.
Isn't it slow though on current processors? I just threw
together a test
On Tuesday, 17 July 2018 at 21:18:12 UTC, John Colvin wrote:
Just do what std.typecons.Proxy does and return float.nan for
the incomparable case.
Isn't it slow though on current processors? I just threw
together a test program.
-
import std.datetime.stopwatch, std.math, std.stdio;
On Tuesday, 17 July 2018 at 21:18:12 UTC, John Colvin wrote:
On Tuesday, 17 July 2018 at 18:21:26 UTC, H. S. Teoh wrote:
But opCmp turns out to be a tarpit. Here's why:
According to the original claim, it should also return 0, for
"incomparable". However, this leads to problems:
On Tuesday, 17 July 2018 at 18:21:26 UTC, H. S. Teoh wrote:
As we know, when opCmp is defined for a user type, then
opEquals must also be defined in order for == to work, even
though in theory the compiler could translate x==y into
x.opCmp(y)==0.
In the past, it was argued that this was so
As we know, when opCmp is defined for a user type, then opEquals must
also be defined in order for == to work, even though in theory the
compiler could translate x==y into x.opCmp(y)==0.
In the past, it was argued that this was so that partial orders could be
made to work, i.e., it could be the
13 matches
Mail list logo
