www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 10427] New: No opEquals method in std.random.MersenneTwisterEngine

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10427

           Summary: No opEquals method in std.random.MersenneTwisterEngine
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Phobos
        AssignedTo: nobody puremagic.com
        ReportedBy: joseph.wakeling webdrake.net



2013-06-20 13:38:23 PDT ---
MersenneTwisterEngine should have an .opEquals() method like Xorshift and the
Linear Congruential generator.

Because it's currently a value type the lack seems innocuous, but it will cause
issues if/when the design is converted to a reference type.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 20 2013
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10427


Jonathan M Davis <jmdavisProg gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg gmx.com



PDT ---
How is this a bug? It doesn't _need_ an opEquals, so it would be bad practice
to add one. If it's changed to a reference type, _then_ you need opEquals, and
you implement it. But until it's a reference type, opEquals is unnnecessary,
and not having it is most definitely not a bug.

If anything, the fact that XOrshiftEngine and LinearCongruentialEngine have
opEquals have opEquals is the bug. As far as I can tell, they don't need them.
Please _don't_ declare opEquals on types that don't need them. It _increases_
the chances of there being a bug, because the opEquals could be wrong. It could
also be less efficient than what the compiler would have done on its own.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 20 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10427




2013-06-20 14:30:40 PDT ---
It's a discrepancy I noticed, so I thought it should be on record.  The concern
was that when the RNGs _are_ converted to reference types, the lack of opEquals
in one out of three might be overlooked.

The unittests I've submitted earlier today should catch that if it happens,
though.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 20 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10427


Jonathan M Davis <jmdavisProg gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID



PDT ---
While I understand the concern about the possibility of introducing a bug, bug
reports are for actual bugs, not for potential bugs. And unit testing is
exactly how you prevent such regressions from creeping into the code.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 20 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10427




2013-06-20 16:40:50 PDT ---
Fair enough, sorry for the noise.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 20 2013