Cleaner method to generate two Lists of the same length
Marc
Matthew Pocock
--
You received this message because you are subscribed to the Google Groups "scalacheck" group.
To post to this group, send email to scala...@googlegroups.com.
To unsubscribe from this group, send email to scalacheck+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scalacheck?hl=en.
--
Rickard Nilsson
On Thu, 26 May 2011 17:43:53 -0700 (PDT), Marc <mill...@gmail.com>
wrote:
> Dear all,
>
> I have been playing around with ScalaCheck for a bit now and am
> curious as to whether there is a cleaner means
> of coding the following: I have implemented a mathematical vector
> class and I wish to test the addition
> of two vectors of the same length. For this I require the generation
> of two vectors with equal lengths that can be added.
>
> Simplifying the problem, say we wish to test the following property.
> Given List v1 and List v2, we wish to verify
> that v1.length + v2.length == 2*v1.length.
>
> To do this, I implemented the following:
>
> Generator:
> def generateTwoEqualLengthLists(size:Int,g:Gen[Double]) = for{v1
> v1.length + v2.length == 2*v1.length}
> with explicit naming of the lists. When I use the generator above,
> the
> types do not match up
> and I receive the error
>
> found : (List[Double], List[Double]) => Boolean
> required: ((List[Double], List[Double])) => ?
>
> All my attempts at fixing this have failed. I am sure this is due to
> confusion on my part and any
> help/hints/paths would be greatly appreciated.
You can use a case-expression to match the pair of lists. Here is a
solution, with a generic generator:
import org.scalacheck._
def g[T](implicit a: Arbitrary[T]) = for {
v1 <- Arbitrary.arbitrary[List[T]]
v2 <- Gen.containerOfN[List,T](v1.length, Arbitrary.arbitrary[T])
} yield (v1,v2)
val propLengthTest = Prop.forAll(g[Double]) { case (v1,v2) =>
v1.length + v2.length == 2*v1.length
}
/ Rickard
> Thank you in advance!
>
> marc
>
Marc
You can use a case-expression to match the pair of lists. Here is a
solution, with a generic generator:import org.scalacheck._
def g[T](implicit a: Arbitrary[T]) = for {
v1 <- Arbitrary.arbitrary[List[T]]
v2 <- Gen.containerOfN[List,T](v1.length, Arbitrary.arbitrary[T])
} yield (v1,v2)val propLengthTest = Prop.forAll(g[Double]) { case (v1,v2) =>
v1.length + v2.length == 2*v1.length
}
Rickard Nilsson
wrote:
>> You can use a case-expression to match the pair of lists. Here is a
>> solution, with a generic generator:
>>
>> import org.scalacheck._
>>
>> def g[T](implicit a: Arbitrary[T]) = for {
>> v1 <- Arbitrary.arbitrary[List[T]]
>> v2 <- Gen.containerOfN[List,T](v1.length, Arbitrary.arbitrary[T])
>> } yield (v1,v2)
>>
>> val propLengthTest = Prop.forAll(g[Double]) { case (v1,v2) =>
>> v1.length + v2.length == 2*v1.length
>> }
>>
>
> Wow, thank you I was very close to this, but did not use the
> case-expression.
> So that I can learn a little more from this, would you please explain
> the semantic/type difference between
>
> forAll...{ (v1,v2) and forAll...{case (v1,v2)}
>
> and how the case-expression works in this instance.
This is really a Scala feature. Look at the following REPL session:
scala> val f = { (n: Int, m: Int) => "foo" }
f: (Int, Int) => java.lang.String = <function2>
scala> val g: ((Int,Int) => String) = { case (n: Int, m: Int) => "foo"
}
g: (Int, Int) => String = <function2>
scala> val h: (Tuple2[Int,Int] => String) = { case (n: Int, m: Int) =>
"foo" }
h: ((Int, Int)) => String = <function1>
The case-expression creates a partial function, but by using an
explicit type you can tell Scala to convert it into either a function
that takes several arguments, or a function that takes one
tuple-argument. Since your generator generates a Tuple2, Scala converts
the case-expression into a function that takes a Tuple2.
/ Rickard
Marc
Marc
M == vec1 //NEW PROPERTY TO TEST
1=1 1=1 1 12=2 2=2 2 23=3 3=3 3 31=1 3=3 1 1 <= lists of different sizes0=0 3=3 0 0 <= lists of different sizes
Rickard Nilsson
On Fri, 27 May 2011 07:28:56 -0700 (PDT), Marc <mill...@gmail.com>
wrote:
> Sorry for the spam, but I am now encountering some weird behavior
> when using this generator.
It's not spam, it's feedback. Keep it coming!
I think this is a consequence of ScalaCheck's "shrinking" feature. When
ScalaCheck finds a failing test case, it tries to shrink the input
argument, to find a minimal failing test case. It is a nice feature, but
it is easy to get caught like you did here. The problem is that
ScalaCheck doesn't know that the pair of lists should contain lists of
equal lengths, so when it tries to shrink the lists it might well end up
with one list of length 1 and one of length 3. The solution to this
problem is to add a precondition to your property. This makes ScalaCheck
ignore cases when the precondition isn't fulfilled. In your case it
would look something like this (you need tom import Prop._ to get the
implicit support for the ==> operator):
import Prop._
val propAdd = forAll(g[Double]) { case (v1,v2) =>
(v1.length == v2.length) ==> { // PRECONDITION
val vec1 = MathVector(v1.par)
val vec2 = MathVector(v2.par)
val vec1PlusVec2 = vec1+vec2;
val M = vec1PlusVec2 - vec2
v1.length == vec1.length && vec1.length == vec2.length &&
vec1PlusVec2.length == vec2.length && M == vec1
}
}
I think this would solve your problem. However, this is not the most
convenient thing to do, since the precondition essentially is specified
_both_ in the generator and in the property. It would be very nice to
only do it in one place. Then you would get sort of "implicit
preconditions" by using generators such as Gen.posNum. This has been
discussed before, see
http://groups.google.com/group/scalacheck/browse_thread/thread/396e5e81e5909884.
I think it would be possible to add some kind of "generator
invariants", that the shrinker respects. I will add a ticket for this
and start to think about how to implement it.
Of course, sometimes you do use general generators because it really
isn't worthwhile to create a custom generators. Then a precondition on
the property is the correct choice. But when the precondition gets
complex you probably need to define a custom generator because
ScalaCheck can't come up with valid inputs with its random approach. In
such cases it would be nice to only put the precondition on the
generator and not also on the property. Hmm, I don't now if this
paragraph is just a reiteration of what I said above, I just sort of
kept writing... Well, I hope you get what I mean.
/ Rickard