Investigate antisymmetry failure for UpperBounded for Duration

[travisbrown]

This turned up in #3350 on Scala 2.12, and doesn't look familiar to me. It's not related to that change, so I'm just restarting the job there, but wanted to capture the failure.

[info] Compiling 2 Scala sources to /home/travis/build/typelevel/cats/kernel-laws/jvm/target/scala-2.12/test-classes ...
[info] Done compiling.
[info] Tests: failing seed for upperBounded.antisymmetry is 8MP8QBDQNKwLLH9fN7tBvEZqp74Gi9P01N1JpHidFrI=
[info] - UpperBounded[Duration].upperBounded.antisymmetry *** FAILED ***
[info]   GeneratorDrivenPropertyCheckFailedException was thrown during property evaluation.
[info]    (LawTests.scala:227)
[info]     Falsified after 29 successful property evaluations.
[info]     Location: (LawTests.scala:227)
[info]     Occurred when passed generated values (
[info]       arg0 = 36 days,
[info]       arg1 = 864 hours,
[info]       arg2 = org.scalacheck.GenArities$$Lambda$524/1880085276@32700c2e
[info]     )
[info]     Label of failing property:
[info]       Expected: true
[info]   Received: false
[info] ScalaTest

[travisbrown]

Similar failure on bc77b90 for 2.13:

failing seed for order.antisymmetry is BIuiwWI2xJdRhpszwX4UH3ULEdGDr49xSwwkgj-w6bB=
[info] - Order[Duration].order.antisymmetry *** FAILED ***
[info]   GeneratorDrivenPropertyCheckFailedException was thrown during property evaluation.
[info]    (LawTests.scala:192)
[info]     Falsified after 89 successful property evaluations.
[info]     Location: (LawTests.scala:192)
[info]     Occurred when passed generated values (
[info]       arg0 = -156 days,
[info]       arg1 = -3744 hours,
[info]       arg2 = org.scalacheck.GenArities$$Lambda$510/1150077346@5b5bbfa8
[info]     )
[info]     Label of failing property:
[info]       Expected: true
[info]   Received: false
[info] ScalaTest

[barambani]

It seems that what fails is the antiSymmetryEq law in here. It's pretty systematic, it only takes more cases to trigger (increasing the min successful here and running just this check makes it happen all the times. I tried with 1M but also 100K should do).
I printed some inputs that make the law fail

x: -3912 hours, y: -163 days, f(x): 3848 hours, f(y): -8530416510259638 nanoseconds
x: -169 days, y: -4056 hours, f(x): -13914418 seconds, f(y): -16396260648399086 nanoseconds
x: 48 days, y: 1152 hours, f(x): -894 hours, f(y): -16701174608544 microseconds
x: 56 days, y: 1344 hours, f(x): -4827738 seconds, f(y): 265540 minutes
x: -4680 hours, y: -195 days, f(x): -147 days, f(y): -175780 minutes

and it seems related to the way cogenDuration works (here). I'm not sure about the logic behind those numbers. I guess they are there to give an extra variability to the Cogen's perturb. If I replace that bit with let's say

implicit val cogenDuration: Cogen[Duration] =
  Cogen(_.toNanos)

it doesn't fail, not even with 100M cases.
I'm sure that logic is there for a reason but I cannot figure out the details, so I was wondering if anyone knows more about it.

EDIT: mainly what I can't figure out is why different duration units need different perturbation values I guess.

UPDATE: it seems that the same problem affects Cogen[FiniteDuration]

[larsrh]

Now tracked in #3734